Re: Logo

[Malonowa <malonowa@wanadoo.fr>]

Ian Bicking wrote:

> 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.

I think here that I'd personally like a fast, flicker-free raster graphics
interface it wouldn't be any use to me otherwise.

>
>
> > 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".
>

We'd want to make this work for Win3.1 as well as mac for those heterogenous
environments. Win3.1 doesn't support threading does it? We'd certainly wan't these
turtles to be event driven and callbacks is a good way of doing this.

> > The interpreter needs to be extensible in a similar way to Wish from TCL/TK.
>
> How do you mean?
>

Making it simple to add your own commands to the interpreter to produce your own
specialised one with fast code in C or indeed any language binding. The
interpreter supplies functions to call to register commands that become available
to the language.

> > 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.
>

I wouldn't want a full OO system either but there are things about OO that could
be useful.

> > 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.
>

Multiple turtles definitely. Threading?

> 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 wouldn't want to write every widget. Just the most needed ones right now. If the
interpreter is easily extended then users could add their own which could be
included in the main distro.

> 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.
>

GTK has a fairly decent text editing widget and there are already examples out
there of adding colour syntax highlighting. This implementation should be powerful
enough to write anything and writing it's own environment would be a good test for
that.

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

I've never written a program using threading so is it really essential? I've read
a lot of postings here and there on this subject. It seems to be the "in thing"
but I don't see many people really coming up with good arguments for it. My
argument against it is that it could just complicate matters unnecessarily.

> > 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.
>

Looks good.I think we need as much of the language implemented using C as possible
in order to improve the speed of the interpreter. But maybe that's only necessary
for ongoing optimization.

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

OK. I say this because UCBLogo can already deal with dynamically loaded external
modules on disc. In Oberon from what I remember, you can have module files that
contain code, implementation and interface. A bit like a Pascal Unit not
surprisingly since it's the same guy.

These modules have a name eg.mymodule

In the interface of mymodule you declare your procedures and variables

you would call them simply by mymodule.foo or mymodule.var

The module is then loaded and data accessed or foo executed.

So we could have external turtles or a library of external turtles could be a
nest. So a turtle becomes a file on it's own that you would hatch when you wanted
it or would be hatched automagically if it's not already there.

So, TELL BILLY [CLOSE] would be like BILLY.CLOSE in oberon.

> > 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.

yep.

I'm looking at the code for UCBLogo today so I'll get back to you when I'm done.
Maybe we could involve the original author in these discussions.

Roman.