LOGO-L> predicate writing
>My question over 20 years later is what is the consensus of the LOGO
>community? Do people wish these things had been designed differently? But it
>is too late to change? Are there other issues? The syntax?
I don't know if there's a consensus. But my own feeling is that there are
important issues, and that the ones you listed aren't my ones.
>1. That every procedure doesn't output implicitly. The worst consequence
>(beside confusions like Simone's) is that "run" might or might not output
>depending upon what procedure it was running. It also makes it more
>difficult to write a LOGO interpreter in LOGO.
It's true that this makes the implementor's life a lot harder, especially
if you want both tail call elimination and correct error messages -- it's
really hard to get "X didn't output to Y" right if there are tail calls
involved. On the other hand, my Scheme students often get confused by
procedures that combine output with effect, because an "extra" value
is printed, especially if the value tries to be something useful. For
> (begin (print 3) (print 4))
"Huh? What's that extra 4 doing there?" It's the value that (print 4)
returned, after printing 4.
>2. The emphasis on "sentence" rather than "list" and "append". It smacks of
>trying to be a little bit intelligent - i.e. dumb.
Oh, no, SENTENCE is my favorite Logo feature. It makes so many things so easy.
It would be bad if we didn't *also* have FPUT, but I use SENTENCE much more
often than FPUT or LIST. (Logo doesn't have APPEND because SENTENCE is a more
general version of APPEND; that is, if given legal APPEND arguments, SENTENCE
will append them.)
>3. There was something about how numbers and types worked but I'm not that
>up-to-date on LOGO anymore and can't remember the issue now.
Do you mean that you don't have to declare types of variables? That's true
in all versions of Lisp.
Here's my list of design issues:
1. No first class procedures -- no LAMBDA. This is a clear weakness of Logo.
We can usually work around it because in a dynamically scoped language you
can use the text of a procedure as equivalent to the procedure itself, but
the notation gets messy.
2. Dynamic vs. lexical scope. I still think Logo made the right choice
here, for its purposes, but we still have arguments about it.
3. Separate procedure namespace. This is related to #1, but a little
different. Basically, we pay a heavy syntactic price for being able to
use LIST and WORD as formal parameters, namely all those colons. I'm not
sure what's the right thing.
4. Tokenization. I hate having to say "2 + 3" instead of "2+3" in current
LCSI products. It's really annoying. But the available alternatives aren't
perfect either. Berkeley Logo really tries hard to "do the right thing"
about this, but the rules are awfully complicated if you really try to
5. Special forms. We were just discussing this -- someone wanted to
duplicate in MSWLogo the behavior of PC Logo's ERASE, EDIT, etc., and you
can't, because we don't provide special forms. There are arguments on
both sides of this one; having special forms means that absolute beginners
don't get caught on missing quotation marks, but also that you can't
easily extend the power of the language in workspace management by using
lists of procedure names as a kind of package facility, as in EDIT :MYPROCS.