Talk:PyoLogo

Some questions:

• Are the threads native threads, or cooperative/green threads? Native threads give you access to traditional C APIs (though often not widgets), green threads make high numbers of turtles possible.
  • PyoLogo's threads are green threads. I'm using the threading module. Can Python do native threads? My understanding is that a normal Python core only allows green threads. --Roger
    • No, quite the opposite. If you are using the threading module you are using native threads. There's no support for green threads in Python, unless you are using the Stackless interpreter, or perhaps something like Greenlets.

• Could make be a special form, to allow make :counter :counter + 1 ? This seems to be what children initially guess anyway, even if the strict/normalized interpretation seems simpler.
  • I had chosen the set method to avoid making changes to make. This gives a new choice while maintaining compatibility. I agree that make "i :i + 1 is confusing but I have a feeling that many Logo programmers would not easily accept make :i :i + 1 --Roger

• Are there first-class objects? The one example I see uses named turtles. I really like first-class objects (not purely named objects, which always felt like a limitation of the interpreter, not the language).
  • Sounds like a good idea. How do you think the syntax of a first class object could be in Logo? --Roger
    • No special syntax. A variable can of course hold both a list and a word -- and depending on the implementation numbers might also be separate objects. You just let variables hold other values. You don't need a syntax to build objects, you can just rely on constructor functions to return objects (e.g., newturtle).

• Have you looked at the OO as implemented in PyLogo? It's not really complete, but it maps very closely to Python's notion of objects. There's a description here.
  • Thanks. I'm sure there is something neat about using Python's style objects. I also like the distinction between ask and tell. --Roger.

• I'd strongly recommend a test strategy early on, especially for the core language (the graphics are harder to test). PyLogo includes a doctest subclass that runs Python-style doctests but using the Logo interpreter. You might be able to adapt that to the Pyologo interpreter.
  • yes. this is very important. I haven't looked at how you did it yet but I'm sure this will be useful. --Roger.

• How is the interpreter constructed? I'm curious how it compared to PyLogo, of course. PyLogo lacks UI, but the interpreter is in reasonable shape. (I have played around a little with using PLY here -- but I didn't get very far on that before my attention was taken away.) It doesn't allow for green threads, which is a problem. One of the things I was thinking about in a rewrite is mapping Logo source directly to Python objects with small changes, like subclassing list to keep track of original source location for tracebacks.
  • I'm using PLY. Although Logo cannot be fully described with a context free grammar, PLY is very easy to use and modify. I was able to get things going rather well with a few hacks. --Roger
    • When I was playing with using PLY, I just parsed the basic syntax, I didn't try to change it into a fully parsed form (ala S-Expressions). Then it's a fairly simple syntax to parse.

• You might want to look at Genshi, a templating language in Python. It compiles the templating language to the Python AST. The implementation is surprisingly simple. The module that does this is genshi.template.eval. But if you use the Python calling conventions and execution model, you can't get green threads.
  • Thanks. I'll take a look. --Roger.

-- Ian Bicking 19:20, 11 January 2007 (EST)

---

Will PyoLogo be able to support colorunder in the future?

--DanielAjoy 11:07, 8 February 2007 (EST)