[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

Why must implementing Python be hard unlike Scheme?

seberino

2/19/2008 6:15:00 AM

I'm learning Scheme and I am amazed how easy it is to start building a
half baked Scheme implementation that somewhat works.

After knowing Python for *years* I have no idea how to actually
implement the darn thing.

Does this have to be true? Beneath the more complex syntax are there
a few core design principles/objects/relationships to help in grokking
the whole thing? Got any related links?

Certainly, "(almost) everything is an object" is a good start. Are
there any other axiom like statements one can hang their hat on when
trying to wrap their brain around Python's architecture?

Chris
16 Answers

George Sakkis

2/19/2008 6:51:00 AM

0

On Feb 19, 1:15 am, "seber...@spawar.navy.mil"
<seber...@spawar.navy.mil> wrote:

> I'm learning Scheme and I am amazed how easy it is to start building a
> half baked Scheme implementation that somewhat works.
>
> After knowing Python for *years* I have no idea how to actually
> implement the darn thing.

From http://swiss.csail.mit.edu/projec..., "(Scheme) was
designed to have an exceptionally clear and simple semantics and few
different ways to form expressions". Apparently it did very well in
this department, but for most other programming languages minimality
is not the top priority. Python is not an exception.

> Does this have to be true? Beneath the more complex syntax are there
> a few core design principles/objects/relationships to help in grokking
> the whole thing? Got any related links?

http://codespeak.net/pypy/dist/pypy/doc/getting-started.html#wh...

George

seberino

2/19/2008 7:07:00 PM

0

http://codespeak.net/pypy/dist/pypy/doc/getting-started.htm......
>
> George


I'm very excited about PyPy. It would still be nice to see a
nice succinct list of major design principles of Python
implementations somewhere.

chris

Michele Simionato

2/20/2008 5:10:00 AM

0

On Feb 19, 7:15 am, "seber...@spawar.navy.mil"
<seber...@spawar.navy.mil> wrote:
> I'm learning Scheme and I am amazed how easy it is to start building a
> half baked Scheme implementation that somewhat works.

This was true for R5RS Scheme, not anymore.

Michele Simionato

Kay Schluehr

2/20/2008 5:50:00 AM

0

On 19 Feb., 07:15, "seber...@spawar.navy.mil"
<seber...@spawar.navy.mil> wrote:

> Certainly, "(almost) everything is an object" is a good start. Are
> there any other axiom like statements one can hang their hat on when
> trying to wrap their brain around Python's architecture?
>
> Chris

It's a natural way to start a new Python building a toy VM. Building a
Python VM in a high level language is certainly not harder than
creating a Scheme interpreter. When you are learning Scheme right now
you can use it as an implementation language.

seberino

2/20/2008 6:23:00 AM

0

On Feb 19, 9:49 pm, Kay Schluehr <kay.schlu...@gmx.net> wrote:
> Building a
> Python VM in a high level language is certainly not harder than
> creating a Scheme interpreter.

Does VM = interpreter?
Are you saying implementing a toy Python interpreter is not any harder
than implementing a toy Scheme interpreter?

I don't understand why you think that.
The Python grammar is much more complicated. Python ASTs are much
more complicated. Parsing Python files with the whitespace is harder.
Please prove me wrong. I hope you are right.

Chris

Paul Rubin

2/20/2008 8:29:00 AM

0

"seberino@spawar.navy.mil" <seberino@spawar.navy.mil> writes:
> Does VM = interpreter?

I think it means the bytecode interpreter.

Jason

2/20/2008 3:14:00 PM

0

On Feb 19, 11:22 pm, "seber...@spawar.navy.mil"
<seber...@spawar.navy.mil> wrote:
> On Feb 19, 9:49 pm, Kay Schluehr <kay.schlu...@gmx.net> wrote:
>
> > Building a
> > Python VM in a high level language is certainly not harder than
> > creating a Scheme interpreter.
>
> Does VM = interpreter?
> Are you saying implementing a toy Python interpreter is not any harder
> than implementing a toy Scheme interpreter?
>
> I don't understand why you think that.
> The Python grammar is much more complicated. Python ASTs are much
> more complicated. Parsing Python files with the whitespace is harder.
> Please prove me wrong. I hope you are right.
>
> Chris

If you create a byte-code interpreter, you don't need to worry about
the AST or whitespace. Python code compiles down into a byte-code
that runs on a simple virtual machine. Values are put in a stack,
then popped off the stack to perform operations. Jython compiles
Python into the Java byte-code machine, while IronPython
generates .NET / CLR byte codes.

The dis module allows you to "disassemble" the byte-code instructions,
at least for CPython. Take a look at "http://docs.pytho...
module-dis.html". (There's a link at the bottom to a page that
describes what the byte-codes in CPython are.)

You also don't have to jump directly to doing everything yourself.
Python has modules that will already lex (module tokenize) and parse
(module parser) the language, so you can use of the modules to focus
on implementing the other module.

Python is somewhat more difficult to parse because it isn't a
functional language. While functional languages are easier to
implement, they aren't as easy for the beginner or average programmer
to use. I know how to work within the MFC and wxWidget/wxPython
frameworks, but darned if I know how Scheme could be used to implement
a COM object.

Take a look at Shalabh Chaturvedi's "Python Types and Objects" [1].
This describes how Python's type and object objects work. Since this
is the top of Python's new-style classes, getting this right is
imperative.

I hope this gives you some idea on how to proceed. Python's grammar
really isn't that difficult. Python uses a LL parser [2], while many
languages uses LALR parsers [3]. The parts of the BNF are described
in detail in Python's "Python Reference Manual" [4].

I hope that the resources help.

--Jason

[1] Python Types and Objects:
http://www.cafepy.com/article/python_types_and_objects/python_types_and_ob...
[2] LL Parsers: http://en.wikipedia.org/wiki...
[3] LALR Parsers: http://en.wikipedia.org/wiki/L...
[4] Python Reference Manual: http://docs.python.org/re...

eduardo.padoan@gmail.com

2/20/2008 7:22:00 PM

0

On Feb 19, 2008 3:15 AM, seberino@spawar.navy.mil
<seberino@spawar.navy.mil> wrote:
> Does this have to be true? Beneath the more complex syntax are there
> a few core design principles/objects/relationships to help in grokking
> the whole thing? Got any related links?

Take a look at a simpler implementation, like "tinypy":
http://www.philhassey.com/blog/2008/02/19/tinypy-64k-nearing-10-and-it-really-does-f...

--
http://www.advogato.org/person...
Bookmarks: http://del.icio....

John Nagle

2/21/2008 5:29:00 PM

0

seberino@spawar.navy.mil wrote:
> I'm learning Scheme and I am amazed how easy it is to start building a
> half baked Scheme implementation that somewhat works.
>
> After knowing Python for *years* I have no idea how to actually
> implement the darn thing.

Why? It's not very difficult. Get a parser for LALR(1) grammars,
like YACC or Bison, write a tokenizer that understands Python indentation,
hook up a dictionary, and parse the thing into a tree. This is all
covered in Compilers 101. Get the Dragon Book if you don't know this stuff.

Once you have a tree, figure out some way to encode the tree into a linear
form, and write an execution engine that reads byte codes and has the
big switch to call the function for each byte code.

The run-time data implementation is all dictionaries. In Python,
everything is a variable-sized hash. You don't even have to allocate
storage during compile time. The run-time environment is a tree of hashes.

The resulting implementation will be slow, but then, so is CPython.
Too much time goes into hash lookups.

John Nagle

Paul Boddie

2/21/2008 5:36:00 PM

0

On 21 Feb, 18:28, John Nagle <na...@animats.com> wrote:
>
> Why? It's not very difficult. Get a parser for LALR(1) grammars,
> like YACC or Bison, write a tokenizer that understands Python indentation,
> hook up a dictionary, and parse the thing into a tree. This is all
> covered in Compilers 101. Get the Dragon Book if you don't know this stuff.

Or, if time is precious and you don't really care what parses your
programs (or even compiles them), just skip over this and use the
standard library compiler package:

http://docs.python.org/lib/com...

Paul