Path: news.media.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!sgiblab!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!yoyo.aarnet.edu.au!ntx.City.UniSA.edu.au!magill.magill.unisa.edu.au!kerrb
From: kerrb@magill.unisa.edu.au
Newsgroups: comp.lang.logo
Subject: Re: bug in Goldenberg?
Message-ID: <1994Jan1.112348.95@magill.unisa.edu.au>
Date: 1 Jan 94 11:23:48 +1030
References: <1993Dec24.201055.93@magill.unisa.edu.au> <2fg4jv$oi8@agate.berkeley.edu>
Organization: University of South Australia - Magill
Lines: 84

In article <2fg4jv$oi8@agate.berkeley.edu>, bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
> kerrb@magill.unisa.edu.au writes:
>>to scramble
>>output (se wordsource run pick [ [scramble] [] ] )
>>end
> 
> Two different people just sent me mail pointing out the bug in this.
> I don't know why they mailed me instead of posting, but anyway, if
> you say RUN [] then it doesn't output anything, so you can't use the
> result as input to SE.  The fix is to make it
> 
> 	output (se wordsource run pick [ [scramble] [[]] ] )
> 
> (adding an extra pair of brackets, so the second option now says
> RUN [[]] which outputs an empty sentence).

Thankyou.
In what sense can this example be applied to the general principles we were
discussing which I think was::

clearly understanding the rules of logo and how they work
VERSUS
an ad hoc understanding...

If the dichotomy is phrased in this way then everyone is going to say, yes, I'd
prefer not to be lumped with the ad-hoc crew. But what if the dichotomy of
learning styles was phrased more descriptively and fairly like this:

A LEARNING STYLE THAT IS DOMINANT IN THE COMPUTING CULTURE
DEscriptors or metaphors --
abstract, formal, hierarchical, planners, rule driven, rational, algebraic

A LEARNING STYLE THAT IS MARGINALISED IN THE COMPUTING CULTURE
Descriptors or metaphors --
ad hoc (sic), intuitive, playful, negotiated, social, tinkering, bricoleur,
improviser, transparent


1) the error message was not very helpful,
 se didn't report anything to ( in scramble

run wasn't running but there is no reference to this in the error.

To improve these sorts of error messages would be a fairly major way to make
(logo) programming more accessible to those who prefer the tinkerer / ad hoc /
bricoleur learning styles. 
ie. the bug messages are at the interactive / negotiated part of the learning
spiral. 

2) How consistent are various logo implementations using run as an example?

 To quote Goldenberg and Feurzeig:

> REPEAT and IF are a lot like RUN ....
 (stuff not quoted)
> An unfortunate idiosyncrasy of many implementations of Logo is that RUN
> expects its input to be a list .....
> many Logos design it always to expect lists - a bit rigid for some tastes
> but common nevertheless.
(from page 76)

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 (?)

Conclusion:

So in this case having a clear understanding of the rules of logo is not the
main thing in fixing the bug. Because the rules of logo are not clear (ie. they
are ad hoc) in this instance. If logo was designed with more helpful bug
messages this would benefit all but especially those with a learning style that
could be described as ad hoc. 

This original bug in Goldenberg is the sort of thing that causes teachers to
put the text to one side and say -- "I won't bother with that anymore" (and
perhaps never return to it).

In my case I was lucky. I had access to comp.lang.logo which is part of an
interactive, negotiated learning style.  :-)

Bill Kerr
 Paralowie R12 School
 South Australia