Talk:PyoLogo: Difference between revisions
Jump to navigation
Jump to search
Ian Bicking (talk | contribs) No edit summary |
No edit summary |
||
Line 2: | Line 2: | ||
* 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. |
* 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 |
|||
* Could <tt>make</tt> be a special form, to allow <tt>make :counter :counter + 1</tt> ? This seems to be what children initially guess anyway, even if the strict/normalized interpretation seems simpler. |
* Could <tt>make</tt> be a special form, to allow <tt>make :counter :counter + 1</tt> ? This seems to be what children initially guess anyway, even if the strict/normalized interpretation seems simpler. |
||
** I had chosen the <tt>set</tt> method to avoid making changes to <tt>make</tt>. This gives a new choice while maintaining compatibility. I agree that <tt>make "i :i + 1</tt> is confusing but I have a feeling that many Logo programmers would not easily accept <tt>make :i :i + 1</tt> --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). |
* 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 |
|||
* 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 [http://pylogo.org/PyLogo.html#using-objects here]. |
* 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 [http://pylogo.org/PyLogo.html#using-objects here]. |
||
** Thanks. I'm sure there is something neat about using Python's style objects. I also like the distinction between <tt>ask</tt> and <tt>tell</tt>. --Roger. |
|||
* I'd strongly recommend a test strategy early on, especially for the core language (the graphics are harder to test). PyLogo includes a [http://svn.colorstudy.com/PyLogo/trunk/pylogo/logodoctest.py doctest subclass] that runs Python-style [http://python.org/doc/current/lib/module-doctest.html doctests] but using the Logo interpreter. You might be able to adapt that to the Pyologo interpreter. |
* I'd strongly recommend a test strategy early on, especially for the core language (the graphics are harder to test). PyLogo includes a [http://svn.colorstudy.com/PyLogo/trunk/pylogo/logodoctest.py doctest subclass] that runs Python-style [http://python.org/doc/current/lib/module-doctest.html 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 [http://www.dabeaz.com/ply/ PLY] [http://svn.colorstudy.com/PyLogo/branches/PyLogo2 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 <tt>list</tt> to keep track of original source location for tracebacks. |
* 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 [http://www.dabeaz.com/ply/ PLY] [http://svn.colorstudy.com/PyLogo/branches/PyLogo2 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 <tt>list</tt> 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 |
|||
* You might want to look at [http://genshi.edgewall.org/ Genshi], a templating language in Python. It compiles the templating language to the Python [http://python.org/doc/current/lib/module-compiler.ast.html AST]. The implementation is surprisingly simple. The module that does this is [http://genshi.edgewall.org/browser/trunk/genshi/template/eval.py genshi.template.eval]. But if you use the Python calling conventions and execution model, you can't get green threads. |
* You might want to look at [http://genshi.edgewall.org/ Genshi], a templating language in Python. It compiles the templating language to the Python [http://python.org/doc/current/lib/module-compiler.ast.html AST]. The implementation is surprisingly simple. The module that does this is [http://genshi.edgewall.org/browser/trunk/genshi/template/eval.py 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. |
|||
-- [[User:Ian Bicking|Ian Bicking]] 19:20, 11 January 2007 (EST) |
-- [[User:Ian Bicking|Ian Bicking]] 19:20, 11 January 2007 (EST) |
Revision as of 16:54, 15 January 2007
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
- 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
- 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
- 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)