Re: Logo

[Malonowa <malonowa@wanadoo.fr>]

Ian Bicking wrote:

>
>
> I don't really know how it works.  For now it probably doesn't matter
> -- whether we use the Canvas or raw Xlib or whatever, it won't effect
> the overall design.
>

Imlib would do what we want I think with some nice little extras.

> For us, callbacks would probably be the easiest way to deal with it.
> But that's not the way children will usually think about multiple
> turtles, particularly the graphical turtles.  These should run in
> parallel.  If things are done by callbacks, you have to make sure
> that none of the callbacks are long-running.  Breaking things up
> into short-running pieces is not easy programming.
>
> This doesn't need OS support.  The CoCo III certainly didn't have
> threading, but it's Logo had multiple turtles.  Just a matter of
> simple, cooperative multitasking.  It can be a fair amount more
> predictable than preemptive multitasking, too.
>
> The problem is, doing this requires a lot of support from the
> interpreter.  UCBLogo is uniturtle, so it could be hard.
>

I've been thinking about dealing with widgets without using turtles. Using turtles only
for nice graphics.

>
>
> I know nothing about shared libraries and that stuff.  With a
> recompile, I think this is already fairly simple from UCBLogo.
> Doing it without a recompile is a bit harder.
>

I wasn't thinking about shared libraries. In TCL you recompile.

>
>
> Have we agreed on GTK?  It would be my preference, but we
> haven't really said it for sure.
>

Yes - definitely. I like GTK although I haven't used it a lot. It seems rich enough in
features without licensing problems. It being LGPL. So anything produced could be used
by anyone for anything as long as they don't try to steal the logo interpreter as their
own. It means I can use it in the commercial stuff I do and the users can have a freely
distributable logo along with it.

> Writing its own environment sounds good.  I think there's a good
> path from using the console that UCBLogo already has, to having a
> full environment, so we don't need to achieve any huge leaps to
> manage a good environment.
>

Especially if the widget stuff wasn't too tied to turtles - more flexible and powerful
like guile. If the widget set was GTK but maybe a bit simpler. A bit like a guile
binding but I've not looked at guile or scheme yet.;(

>
>
> Threading under any other name is just as... well, annoying, most
> likely.  Anyway, whether we use OS-level threads or not (I too don't
> relish the idea), I think some sort of mechanism like this is
> necessary if kids are to do simple multiturtle stuff like:
>
> hatch "runner [runawayfrom "chaser]
> hatch "chaser [chase "runner]
>
> runawayfrom :turtle
>   while "true [
>     make "myx xcor
>     make "myy ycor
>     make "otherx ask :turtle [xcor]
>     make "othery ask :turtle [ycor]
>     heading atan2 (:myx - :otherx) (:myy - :othery)
>       ;I think Logo has something easier than atan2 for this
>     fd 10
>   ]
> end
>
> to chase :turtle
>   while near :turtle > 10 [
>     ; all that heading stuff
>     fd 15
>   ]
>   kill :turtle
> end
>
> Or something like that -- basically, both turtles are running around
> at the same time.  How do we manage that?
>

I think I'd approach that as if I was writing an arcade game. On every free event,
action the turtles from a list. I expect the user should be able to tell a turtle how
often it is actioned in centiseconds or something. Then you'd have to decide the order
of the list but that could be up to the programmer. That could probably be an
interesting teaching point actually, do you action the chaser first or the runner? It
could teach how important sequencing is in programming.

> > 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.
>
> I was thinking about something like this for defining responses to
> events.  Each turtle could have its own set of procedures.  If you
> want a turtle to respond to a CLICK event, you simply define a
> CLICK procedure for that turtle.  If a procedure wasn't defined for
> that turtle, then it looked at the normal procedures (where CLICK
> might be defined to do nothing -- though for efficiency it would
> probably be better to set the widget not to respond to the event
> unless a turtle-specific procedure had been defined).
>
> There's no reason that any procedure couldn't be redefined for each
> specific turtle.  All this would require is for the interpreter to be
> aware of the current turtle when it looked up functions.
>
> You could define these turtle-specific procedures by, perhaps,
> control-clicking on a turtle (which might be a button, the classi
> turtle, or whatever) which would open up the text editor on its
> personal procedures.  And of course a primitive for turtles which
> aren't visible or for whom control-click has been overridden.
>

I suppose this is getting quite oop really and I wonder if we tried whether we'd just be
producing a poor object oriented logo. Perhaps that's just not necessary. If the widget
stuff is in logo and not done as turtles then there's no reason why the environment
could provide this sort of metaphor or abstraction and not the language.

That is to say a turtle library ontop of a more powerful widget library. Would we need a
turtle.click of would TurtleClick not do. The environment could write that function. The
logo language would deal with the turtle name and what functions it has for which events
etc. Then the job isn't so hard.

Does the interpreter really need to know about turtles? Should this just be a logo
library? The interpreter would need to know about widget functions certainly. That would
be quite flexible and powerful. But turtles?

I'm worried about spoiling the language itself.

Roman.