[OLPC library] Curly Logo / OLPC

[Ian Bicking]

David Jones wrote:
> On 28 Nov 2007, at 21:01, Samuel Härgestam wrote:
> 
>> Hello all,
>>
>> This might be a good time to inform/remind potentially interested  
>> parties about the Logo tutorial I wrote for OLPC about a year ago  
>> (http://www.israelsson.org/~lethe/logobook/0.5.2/ ). At that time,  
>> I thought the version of Logo to be shipped with OLPC would be  
>> Arnan (Roger) Sipitakiat's version, but that doesn't seem very  
>> likely anymore. In any case, I'd prefer to use a javascript  
>> interpreter, as it could be integrated directly into the tutorial.  
>> I was getting worried I would have to write one myself, but David's  
>> seems to fit the bill perfectly.
>>
>> David, do you have a spec for the dialect of Logo you're using, so  
>> that we could sync?
> 
> No, not yet, but I am keen to develop a spec.  I'm also keen to  
> develop a tutorial, but as you've already done that, it wouldn't make  
> sense for me to duplicate your work.

When I was writing PyLogo I mostly started with UCBLogo's spec and 
manual.  I diverged from UCBLogo, because I just find 'make :var value' 
too... sensible.  And sensible things shouldn't be weird 
meta-operations, which essentially is what that is in UCBLogo.  So 'make 
:var value', 'make "var value' and 'make var value' are all equivalent.

This ends up requiring several special forms: make, localmake, local, 
and for.  Another option is having variables be functions, and each 
function be paired with a setter.  "fd var" and "makevar 10".  I think 
this is what pyologo does.  I don't have any opinion on it, really.

Another issue is how to handle OO.  Integration with the underlying 
Javascript makes OO compelling, even if you only do it in a half-hearted 
way.  Though the prototype programming of Javascript is also a nice 
match for Logo.  If you get rid of the notion that . is a valid name 
character (as is traditional in Logo, but not elsewhere) then you could 
just use normal attributes.  If you mix the function and object 
namespace, you can use "obj.method argument" and ":obj.attribute"... but 
that feels a bit awkward to me.

If I was going to design a new Logo language, I'd probably diverge from 
tradition in ways to make it more like traditional languages, in just a 
couple ways.  First, *something* with OO.  What exactly, I'm not sure. 
Second, well, that make special-form stuff.  Third, something like a 
string.  I find the whole "word thing weird and awkward.  I'm not sure 
introducing a concept of symbol is worth it though.  Anyway, [a b c] can 
still parse to ['a', 'b', 'c'], while 'a b c' is a single string.  (For 
a language that is supposed to be easy to type, isn't " hard to type for 
every variable assignment?)  Making Logo just a little more like Python 
might be a good bridge to other environments.

Anyway, here's the summary of what I did with PyLogo: 
http://pylogo.org/PyLogo.html#differences-from-ucblogo

If you are interested in seeing the wider variety of what dialects do, 
Elica might be a good example of OO.  NetLogo is a bit weird to me; I 
feel like they've made too many compromises with the language.

Integration with Javascript would be great.  I'd love if you could not 
just do graphics, but also interactive applications.  Given a pretty 
dumb server (e.g., something DAV-like), or something like Google Gears, 
you could really create a pretty substantial application entirely in 
Javascript, or with good enough integration, in Logo in Javascript in HTML.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org