Re: Logo

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

Malonowa <malonowa@wanadoo.fr> wrote:
> > GTK would be my personal preference.  In particular, the Canvas sounds
> > like it will make turtle graphics easy to mix with widgets, as well as
> > leaving the potential for some of the more multimedia aspects as in a
> > program like MicroWorlds.
> 
> Just a pixmap for double buffering would probably be best. Then we can use
> imlib to handle lots of graphics formats and special effects. I'm thinking
> about writing little games and the like here. I'll have to read exactly what
> the GTK canvas will do.

I know things like Gnumeric use it to have an underlying 
spreadsheet widget upon which you can place annotations -- like 
making arrows and stuff.  It seems like exactly the sort of 
functionality that would be nice for Logo, with all the line-drawing, 
superimposing of pictures, and all that being done for us.  Heck, 
even printable.  Even if we don't use the power of it for a long time, 
it seems like the Right Thing as well as the easy thing.

> Then that creates a problem. What do you do when you want multiple windows
> and canvases? I'm assuming that we'd need multiple turtles here. The best
> thing is probably to modify berkley logo so that it can deal with all of
> these things and run serious programs then write the kids interface using
> the logo itself.

I don't know what's involved in putting multiple turtles into 
UCBLogo.  It's one of the things that makes me wonder about 
taking things from MSWLogo... I believe it has multiple turtles.

Other implementations of multiple turtles that I've seen is a simple 
step-wise threading.  One primitive for one turtle, one primitive for 
the next.  Which makes it easier to think about it will work together 
for the new programmer, but isn't what you want for the threading in 
an interface.

The other way might be to think about turtles in terms of 
messaging (i.e., callbacks), which would fit nicely with the way 
widgets work.  For most of the interface you can do things like say 
"You turtle... do this", but there are the times when you want to 
say "You turtle... do this while I go and do something else".  

> The interpreter needs to be extensible in a similar way to Wish from TCL/TK.

How do you mean?

> I think if someone's never programmed before then Logo would be a good start
> - especially if it was powerful enough to give them something decent to show
> for it. I'm keen on coming up with something a bit like Delphi but
> interpreted Logo. I've also said before that the maybe a pseudo oop Turtle
> concept would be much easier to understand than c++ or object pascal etc.
> When I first started to program many moons ago it was BASIC on 8 bit
> machines. Then I came across a logo interpreter called Honeylogo. I wrote an
> adventure game in it. Why? Just for kicks... There's something very charming
> about logo and it's turtle(s) - don't quite know what the appeal is but I'm
> certainly not alone in feeling that way.

I wouldn't want to put a full OO system onto Logo... I think it can 
be a bit crufty.  But treating it like a message-passing system 
seems simpler, works with turtles, and doesn't require any big 
changes to the language.

> Back to logo,  can we make some firm decisions now as to how we'd deal with
> widgets and windows in logo? Then we could get something going. Personally,
> I like the idea of multiple turtles a bit like objects. What do you think of
> this.

I think we first need to figure out about threading, multiple turtles, 
and that stuff.

We may just want to make the base widgets available, sans-
turtles, to the Logo environment.  This is quite neutral to any 
particular higher-level representation.  I don't think we want to 
necessarily include every widget, as I've gotten the impression that 
other language bindings for GTK find it difficult to keep up with the 
maintenance.  Logo doesn't have to have a complete graphical 
environment, just a decent one.

I don't think we can make the entire environment inside Logo.  In 
particular, I don't think we'd manage to make a very good editor -- 
though maybe there's a nice text editting widget in GTK now?  
Probably not good enough for our purposes.  Anyway, pieces like 
that could quite possibly be controlled from Logo even if they are 
otherwise black box.

It's just the threading that worries me.  It's a can of worms, but I 
think it might be essential...?

> I like the idea of having different types of turtles such as a window
> turtle, graphics turtle, sound turtle etc. Then being able to create them
> with names like "Billy" or whatever. So if "Billy" was a window turtle you
> could TELL BILLY TO CLOSE or whatever syntax we'd use. Or if billy was a
> graphics turtle, tell billy to fd 100. Or set billy as the default graphics
> turtle and just fd 100.Get the idea? So billy inherits all his properties
> and methods from window or graphics turtle. But it makes more sense than
> talking about objects in the same way as c or Pascal. So each widget would
> be a turtle with a name. People new to programming could really identify
> with all that.

I think the message idea is good.  Maybe like 
TELL "BILLY [CLOSE] or
TELL "BILLY [REPEAT 90 [RT 4 FD 1]]

I don't think we need new syntax.  Heck, even TELL could be a 
simple Logo procedure:

to tell :turtlename :message
  localmake "oldturtlename currentturtle
  maketurtle :turtlename
  run :message
  maketurtle :oldturtlename
end

(where CURRENTTURTLE returns the current turtle name, and 
MAKETURTLE changes the turtle you are controlling)

Turtles could be variables, like :BILLY instead of "BILLY.  I don't 
know which is better.  Variables are more powerful, names are 
probably a bit easier.  MSWLogo uses lots of names, but I think it 
goes too far.

> Maybe if the turtles were defined in a similar way to Oberon modules? That
> seems fairly easy to understand and implement.

How do you mean?

> This is the biggest hurdle, after that something can be coded. It should be
> a fairly simple job with GTK given that we have the interpreter already. It
> would just need a bit of modification.
> 
> I wouldn't want to lock the language into being centred around a canvas and
> a turtle though. It would inhibit real program development and I'd like to
> write some real programs with it.  The input window with turtle canvas
> should just be an interface written with the logo to introduce the language
> to kids.

The Canvas would only be for turtle graphics and a certain 
graphical metaphor.  Turtle graphics aren't essential to Logo and 
could certainly be implemented on the Logo level (performance 
allowing).  On the language level Logo remains quite pure, 
UCBLogo more than most.  I think we can, and should, keep it that 
way as we add graphics.



--
Ian Bicking <bickiia@earlham.edu>