clemrutter@[EMAIL PROTECTED]
says:
> So can we as a group get
>together to make up a definitive definition, and put together may be 5
>one line tests that can be used to illustrate this?
This pops up from time to time so I have a standard response ready:
--------------------
At one of the Logo conferences several years ago I ran a session in
which the possibility of a standard was discussed. Many of the Logo
implementors were there, as well as many users. We ended up with
the conclusion that no standard was possible, because there were too
many serious disagreements about syntax, and also because the set of
primitive procedures was constantly in flux.
The main syntactic disagreement was about special forms. In LCSI Logo
and products derived from it, TO is the only exception to the rule that
inputs are evaluated before a procedure is invoked. For example, to
edit a procedure named FOO you must say
EDIT "FOO
so that the word FOO, the procedure's name, is the value of the input
to EDIT. By contrast, in MIT-derived dialects (such as Terrapin), several
primitive procedures are treated as exceptions, so you must say
EDIT FOO
to edit the procedure named FOO.
The advantage of the latter (special form) syntax is that it's more
obvious to a beginner, especially a young one.
The advantage of the former (evaluated) syntax is that it's a more
general mechanism. For example, suppose I have a bunch of procedures
that I want to consider as a unit. I can say
TO MYPROCS
OUTPUT [PROC1 PROC2 PROC3]
END
and then use the instruction
EDIT MYPROCS
to edit those three procedures. In Terrapin syntax it would instead
edit the procedure MYPROCS itself, which isn't what I want this time.
Also, in the long run (some of us think) it's easier to understand;
in MIT-derived dialects you still have to say
MAKE "VAR value
to assign a value to the variable VAR, so you have to explain to
students why you need quotes in that case but not for EDIT!
(Current Terrapin Logo accepts
EDIT (MYPROCS)
to mean that MYPROCS should be invoked to produce a list of procedures
to edit. This gives Terrapin the power of the LCSI notation, at the
cost of adding another special meaning, this time for parentheses, but
it's not do***ented in their manual.)
Some really recent versions have even more different notations, moving
away from the whole idea of variables, so instead of using MAKE to set
the value and using :VAR to retrieve it, you have procedures SETVAR
and VAR for those purposes, and there are no variables at all.
As for the semantics, what are the essential features of Logo? There
have been versions without turtle graphics, such as the "Music Logo"
that Terrapin sold for the Apple II in which graphics primitives were
replaced with sound generation primitives. At MIT there is a project
in which a small computer is mounted in a Lego brick; it has a different
primitive set from the typical keyboard-and-screen computer. At the
meeting all we agreed on was that anything called Logo should have
the word and list processing primitives (FIRST, BUTFIRST, LAST, BUTLAST,
WORD, SENTENCE, etc.).
--------------------
Interestingly, list processing didn't make it into Clem's list!
As you can see the above was written in the early days of Lego-Logo work.
But since then, many new incompatibilities have come up:
1. The LCSI "page" metaphor (replacing workspaces).
2. Massively parallel versions (StarLogo, NetLogo, StarLogo TNG).
3. Click-and-drag instead of text notation (Scratch).
4. More-or-less object-oriented versions in which procedures belong to
specific objects instead of being part of the global workspace.
Some versions include more than one of the above.
This sort of difference is much more problematic than feature sets (things
like graphics, lists, 3D, etc.), or even than small syntactic differences,
about which you might hope to twist implementors' arms (e.g., twist LCSI's
arms not to require spaces around arithmetic operators). When a version
has
a whole different organizing metaphor from that of traditional Logo,
you'll
have trouble even loading in your test suite, never mind getting it to
run.
At one point it was politically im****tant to draw a sharp line and say
that
if it doesn't do list processing then it isn't Logo, to distinguish Logo
from mere turtle graphics packages (some of which still exist and I think
some of which even still have "Logo" in their names). The point is still
intellectually im****tant, but I'm not sure whether it's still of practical
political im****tance.
I think, Pavel, that if you do get commercial Logo developers in the the
Atlas project, you'll see that it suddenly gets a lot harder. Most of the
current crop of free versions are either direct code descendents of
UCBLogo
or at least had UCBLogo as a syntactic starting point, and have different
syntax only because a designer had a good reason for making a different
choice. In the commercial world, there's much more ancient Logo history
still being felt, and therefore more syntactic variety, not necessarily
for
reasons other than chance.
P.S. Object Logo was lexically scoped. Was it a Logo?
P.P.S. On the other hand, don't let me discourage anyone who wants to
write
a UCBLogo test suite. That'd be great! :-)
|
