Path: news.media.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!agate!anarres.CS.Berkeley.EDU!bh
From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
Newsgroups: comp.lang.logo
Subject: Re: bug in Goldenberg?
Date: 1 Jan 1994 02:24:14 GMT
Organization: University of California, Berkeley
Lines: 49
Message-ID: <2g2mse$m76@agate.berkeley.edu>
References: <1993Dec24.201055.93@magill.unisa.edu.au> <2fg4jv$oi8@agate.berkeley.edu> <1994Jan1.112348.95@magill.unisa.edu.au>
NNTP-Posting-Host: anarres.cs.berkeley.edu

kerrb@magill.unisa.edu.au writes:
>I suppose this is why the bug appeared in the text in the first place. They
>forgot to include the extra [] because it is not actually required on some
>implementations of logo (?)

The problem with that example wasn't that RUN requires a list.  It was
given a list, namely the empty list.  The problem is that running an
empty list doesn't produce a value.

To make that clearer, consider the following examples:

1)	PRINT SENTENCE "FOO RUN ["BAZ]

2)	PRINT SENTENCE "FOO RUN [PRINT "BAZ]

The first example, a correct Logo instruction, will print the
sentence FOO BAZ.  The second example is in error, because when
RUN runs its input, that input is an instruction -- it has an
effect -- namely, it prints BAZ -- and does not have a value.
Whereas the input to RUN in the first example is an expression,
which does have a value, and so RUN can return that value.

The error message you should see in this situation is
	RUN DIDN'T OUTPUT TO SENTENCE.
The same message is what you should have gotten in the original
example from Goldenberg and Feurzeig.

Saying RUN [] is like typing an entirely empty line in response to
the Logo prompt.  It's an empty instruction, doing nothing, and in
particular not returning a value.  Saying RUN [[]] is like saying
RUN ["BAZ].  That *does* produce a value.

I know the above isn't really responsive to the question about styles
of work.  So let me try to do that.  I have two answers, in opposite
directions:

1.  I acknowledge that my own preferred style of work is the formal
one, and that not everyone is or should be like me, and that I may
be a bad guide for someone who prefers the other style.  That's one
reason I'm not an elementary school teacher, since formal methods are
particularly unlikely to appeal to preformal kids!

2.  Whatever your preferred style of work, the ideal is to be able to
work in *both* styles.  In particular, when something goes wrong,
that's when you especially need the formal understanding!  When things
are going okay, you can concentrate on the bricolage part.  I think
it *is* true that my formal understanding helped me understand this
error, even though I didn't notice it the first time I read the code,
and even if some versions of Logo use different rules.