Talk:PyoLogo

From OLPC

Revision as of 19:35, 26 April 2007 by Arnans (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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
      • I wouldn't accept it :) --DanielAjoy 11:08, 8 February 2007 (EST)
  • 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)

As far as I can tell, Arnans is making steady progress in expanding the supported set of commands—as the page's history shows... so my guess is that at some point it will :) --Xavi 11:19, 8 February 2007 (EST)
- Color under is not the immediate command in the todo list, but yes it will eventually be there. I hope to make the code public very soon so that others can help. --18.85.44.39 10:40, 16 February 2007 (EST)

"Most other Logo interpreters"

"Not space delimited. 'Show 1+1' works in PyoLogo whereas most other Logo interpreters do not accept this."

"Most other Logo interpreters" is apparently a euphemism for "Microworlds"! In fact there are very many, probably most, Logo interpreters that don't require spaces, including the Terrapin products and also UCBLogo and its many offshoots. My guess is that Microworlds and its children are the only ones that do require spaces.

There is, therefore, a lot of literature about ways to handle the problem of ambiguity between monadic and dyadic minus. The short version is that the lexical analyzer should distinguish the special case of a minus sign with a space before it but no space after it, and should force that to be monadic minus; in other cases, if an expression comes before the minus sign it's dyadic. (Of course if an open parenthesis or the name of a procedure that takes inputs comes before the minus sign, it's unambiguously monadic.)

Note that tokenization is context-dependent. If you see a list such as

          [642-8311 555-2368]

it should be parsed as containing two words, not six. If a literal list turns out to be an input to RUN or similar, then it gets re-tokenized.

The UCBLogo reference manual (http://www.cs.berkeley.edu/usermanual) has a somewhat longer discussion of tokenization.

  • Thanks! I'm sure there is a lot to learn from UCBLogo and others. --Roger 15:35, 26 April 2007 (EDT)
Personal tools
  • Log in
  • Login with OpenID
About OLPC
About the laptop
About the tablet
Projects
OLPC wiki
Toolbox