Re: Logo

["Ian Bicking" <bickiia@earlham.edu>]

I think I was a bit scattered in my last description of the 
Scheme/translation thing.  Here's what I was thinking of doing:

Logo is a dialect of Lisp.  It doesn't look like most of them, but if 
you get past the outer-most syntax it's fairly similar.

Instead of implementing Logo entirely, it might be possible to 
translate the Logo syntax to a Lisp (my prefered dialect being 
Scheme).  This has the advantage of letting someone else do the 
work for you.  A good version of Lisp will do good garbage 
collection, have a bunch of optimizations for speed, allow 
debugging, and allow various extensions (like a GTK interface).

The disadvantage is that while Scheme is like Logo, there are 
some significant differences.  The biggest is dynamic scoping in 
Logo versus lexical scoping in Scheme.

Dynamic scoping means that a procedure inherrits the variable 
bindings from its calling procedure.  An example makes much 
more sense:

TO HELLO :NAME
  SALUTATION
END

TO SALUTATION
  PRINT (SE [How are you, ] :NAME "?)
END

SALUTATION uses the variable :NAME, even though it isn't defined 
in SALUTATION -- it's defined in HELLO.  If you called 
SALUTATION at the prompt you'd get an error because of the 
undefined :NAME reference.  This is unlike how normal 
programming langues work.

In fact, a number of Lisps did this around the time that Logo was 
invented.  Now, while Tcl uses it, and Perl allows it (and Common 
Lisp allows it like it allows everything), it's very uncommon.  It 
dooms a language to being interpretted, while also making it 
unclear just how and where a variable is created.  But it is easy to 
implement, and does make debugging a bit easier.  In a way.

There are some subtleties in getting rid of it, which I won't get into 
right now.  But it threatens to change Logo too much to try to 
change this.

That's just one issue of the translation, but I still think it has the 
potential to be both easier and more powerful than implementing a 
Logo all of its own.

I hope that explains what I was thinking about a bit more.

I see the core ideas in Logo being a simplified syntax, simple data 
(most everything being words and lists), interactive environment, 
and some nice libraries (turtle graphics being the most notable).

I wrote some about my past attempt, then debated the validity of it 
some with Brian Harvey (the author of UCBLogo), on the LOGO-L 
list.  You can read some of it, starting with this thread (the archives 
seem to be missing some mail):  
http://archives.gsn.org/logo-l/1298/msg00001.html

And a debate on dynamic scoping:
http://archives.gsn.org/logo-l/1298/msg00090.html

There was a debate on "What really is Logo?" at the same time, 
which probably would also make for interesting reading.  I should 
probably reread it myself.

> I'd be grateful if you'd explain the terminology here at idiot
> level - I did a course writing a basic Oberon compiler a long time
> ago. My memory needs refreshing.  I didn't know that there was an
> Object Logo. 

I don't think anyone knew there was an Object Logo.  The company 
that makes it is now defunct, I believe.  They made 
MacCommonLisp (or something like that).  They must have used 
their experience there to make the Logo, with similar dynamic 
compilation and other neat stuff.  But it looked like there stuff was 
probably tied to 68k rather heavily, among other problems.

I couldn't find much of any useful information on it, but Brian Harvey 
refered to it in passing.

> > The other significant change I made was that variables were really
> > variables, so that :VAR isn't equivalent to THING "VAR.  And some
> > other things here and there...
 
> variables in logo would definitely need a lot of work. If we were
> to implement multiple turtles then we'd have to implement dynamic
> structures and pointers so I think the way the language deals with
> data would have to be added to considerably. 

I don't think Pointers would be necessary.  They are kind of 
confusing, but they also don't fit with Logo.  Generally everything in 
Logo *is* a pointer.  So when you pass a list to a procedure, you 
are passing a pointer to the list, not copying a new list.  You can 
go pretty far without pointers.  

Lists are the most common data structure, and *can* do most 
things.  But I don't know if I like having only lists -- it makes data 
seem more homogeneous that it really is.

> I'll have to go and read about guile and scheme so I can
> appreciate what you're saying. Where this subject's concerned
> you're much cleverer than I at this stage. 

I think if you want to think about what a Logo *can* be, learning a 
Lisp-like language would be a good idea, if only to appreciate the 
philosophy behind them.  Right now the only ones anyone seems 
to be actively using are Common Lisp and Scheme, though I 
believe Dylan has some interesting ideas as well as some interest 
in pedagogy.

Then there's Boxer, which intrigues me.  Now that I have a Mac 
available to me at home I should try to play with it more.

> > I've only used Starlogo a little bit.  Admittedly, it was too unfamiliar
> > and I didn't put enough effort into really figuring out how it all
> > worked.  I should probably try using it some more.  The multi-turtle
> > thing seemed to be its raison d'etre, so I didn't notice if there was
> > an object-oriented underlayer.
 
> The multi-turtles are objects essentially, they can inherhit from
> eachother - I believe. I think the multi-turtle idea's interesting
> but I wouldn't model a new logo on Starlogo - I think the
> extensions are there for a very specific reason - decentralized
> systems. 

StarLogo doesn't seem to be trying to be a general-purpose Logo.  
I'd rather keep Turtles out of the core language anyway, and have 
them as something implemented at the Logo level.  Or at least at 
the highest level possible.

If you had access to the GTK primitives from Logo (the Canvas 
being the most important) then implementing turtles in Logo 
wouldn't be too hard.  Unless there were speed problems...

> Turtle patches are groups of turtles. So you can perform actions on families of objects. In
> starlogo the patches are defined by colour I think.
> 
> Example: Taken from Starlogo site.
>                      if xcor > 12 [sprout [setcolor blue]]
>                      (Each patch to the right of xcor = 12 creates a new turtle that sets its
>                      color to blue.)
> 
> I think patches in Starlogo are aware of each other as well.
> 
> I can see the use for artificial life simulations here but in applications programming ? What do
> you make of patches?
> 
> I like the idea of being able to group a whole series of objects together and manipulating a group
> though.

It seems like patches could just be lists of turtles, unless there's 
something else to them.  You might not be able to write things out 
quite as compactly as in StarLogo, but like you said, they aren't 
the sort of thing you'd use all the time.  Things like FOREACH 
make lists fairly powerful.

> > > I think logo is potentially a very impressive and powerful language with some more modern
> > > extensions to it and it's pretty easy to understand. I would really love to have a good
> > > development environment based around this for real applications. I think that there could be
> > > many teachers who may have a basic knowledge of the language who may get into a bit of
> > > programming - and students as well. We mustn't overlook what students can do to educate
> > > eachother. Anyway, why should languages like TCL and PERL have all the fame when Turtles are
> > > much more charismatic!
> >
> > Yes, I do think Logo has a lot of potential.  Lisp without the
> > parenthesis :-)  If you look at Tcl, it's almost exactly like Logo
> > except with strings instead of lists... but that's incidental.
> >
> > But it is a niche language.  The realm of education is an important
> > one, but sometimes I wonder if it's bad to make distinctions such
> > that you get software only useful in an educational context.  KidPix
> > is cute, but the Gimp is so much better... I'd hate to just make a
> > KidLanguage.  Just a concern.
> 
> I might say here that how niche is a language which doesn't exist yet but people create them -
> Python, Perl, Eiffel.....
> 
> This is a very interesting point. I've administered a company using educational software! It's how
> you apply it I think. But educational software doesn't have to lack power.
> 
> Gimp could be kidpix. All you'd have to do was add a few more configuration options for different
> levels of ability.

I'd like for Logo to be like that -- something that was powerful, but 
could pretend to be simple to make it easier to learn.  Can you 
have it both ways, though?  The Gimp can be powerful because it 
is useful to people who can improve it, so they keep improving it.  
Will even a very good Logo be useful to people who can make it 
better?  Will it be able to keep up with everything else?

That's where I'd like to attach the Logo to outside efforts if possible. 
One way is the form of using another language as a base, as with 
Scheme.  Another way is to integrate outside code, like using imlib 
to load and display graphics instead of implementing our own code.

Then it could still be powerful, even if only a small number of people 
actually use that power.

> Logo could be a very powerful language. My idea is that you would
> introduce more and more of it at different levels of ability and if
> students don't know that something exists it's not going to baffle
> them - and if they do find out and work it out then all the
> better. 
[...]
> I think that what I'm try to say here is that in an educational context it's not the Logo language
> that's the issue it's the user interface that changes and the problems we expect the student to
> solve.

I agree that the same language can be many different things to 
different people.  Some of this is simply because it is a language -- 
it has the flexibility to be what you make of it.  Unlike an 
application, which usually is what somebody else thought you'd 
want to make of it.

But it also requires a great deal of effort to develop the language.  
There's lots of neat ideas for languages, and lots of 
implementations of languages, but only a few survive in any 
practical sense.  I'm not worried so much about the *potential* for 
Logo to be many things to many people, but about the practicallity 
of actually making that happen.

> I thought of this a few days ago. If only I could've done these things a few years earlier!
> 
> Turtles would be good for creating interfaces. I can easily visualize a turtle wandering around a
> window hatching little button and entry box turtles. It's like packing widgets but without the
> heavy terminology.
> 
> So you could have interface turtles, media turtles, printing turtles etc. Then you just have to
> hatch them and tell them what to do.
> You could knock out a multimedia presentation like this pretty quickly and add some conditonal flow
> where necessary. Or indeed create a program that creates a multimedia presentation.

The turtle metaphore is an interesting one.  It gives the notion of 
identity, responsiveness, activity -- since a turtle is alive, and a 
"widget" doesn't give that feeling at all, being not only dead, but 
usually the product of imaginary factories.  




--
Ian Bicking <bickiia@earlham.edu>