Hi! I would like to know if there are already some concrete plans what the C core needs to be able to do. Will there be anything like the old builtin module? Will dicts and the other types still be done in C or some mix of C and Python etc. Also will the Psyco part be optional to ease the initial porting to new platforms? Florian
Florian Schulze wrote:
Hi!
I would like to know if there are already some concrete plans what the C core needs to be able to do. Will there be anything like the old builtin module? Will dicts and the other types still be done in C or some mix of C and Python etc.
I guess we will borrow most core objects in the first place, just to get started. A first idea is to re-implement almost everything in Python and to let Psyco generate code for that. At least, it will be a good case study to do this for the implementation of the bytecode interpreter. One good reason for that is, as soon as we have the bytecode interpreter running, we can use any python for cross-compiling. We can also re-implement dicts and lists using Python. This can be done by emulating the basic data structures by some primitive array-like objects that represent a piece of memory. The simplicity of these obejcts might be used by psyco to deduce the possible data types which can appear in them, and produce simple, efficient code. But maybe there are better ways. We have to play a lot before this can be decided.
Also will the Psyco part be optional to ease the initial porting to new platforms?
I believe, no. Instead, I think to supply a generic virtual machine which is easy to produce code for, tpgether with a very fast interpreter. That engine would run on any machine and would be enough to do the full bootstrap, when the specific machine is defined, later. Note that psyco is most probably becoming Python code as well. :-) :-)) ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Has anyone thought about features that Python does not have that should be in Minimal? My first candidate would be (ducks) macros, since that could drastically simplify constructing core Python features. I have some thoughts on pythonic ways to do that which I need to write up. Basically, if we use the parser module rather than a C parser, it gets to be fairly easy. So, what would a pythonic macro look like? The nearest match presently is a metaclass, but that only gets the class definition *after* compilation, which means that although we can modify the code at that point (even to the extent of retreiving the source, changing it and recompiling), it had to compile in the first place, so we can't add syntax. Therefore a Pythonic macro should be: A class which adds it's grammar (probably fairly constrained; limited to new keywords, perhaps) to the parser at parse time, by setting or appending to a magic attribute (__grammar__ perhaps). Then the macro provides code which is called with the parse trees resulting from that grammar, modifies them, and returns the parse tree that will actually be compiled. If you want to evaluate some bits at compile time, do that explicitly in the macro (opposite way around to lisp, where you have complicated rules). It may be necessary to provide a quote: keyword and quote() (or noeval()? should the names be different?) builtin that quote a block or an expression to prevent compile-time evaluation by macros. Advantages: It looks like a metaclass. It can be inherited from to use the macro in new classes (hence __grammar__ should be appended to rather than just set). If the kinds of grammar rules that can be added are constrained just right, editors won't mess up the indentation and code using macros will still look like Python. If, however, we can use unconstrained grammar mods in the core, then we can do things like build dictionaries inline. Hmm, must go now, I was dreaming up an example, but I've got to go sell a house (Hooray :-) Comments? Andrew
Has anyone thought about features that Python does not have that should be in Minimal? My first candidate would be (ducks) macros,
as a final user visible feature, I hope not. As an implementation then invisible tool maybe/why not.
since that could drastically simplify constructing core Python features. I have some thoughts on pythonic ways to do that which I need to write up.
there is really no pythonic way to do macros. You can check this python-dev thread http://aspn.activestate.com/ASPN/Mail/Message/1076771 My personal opinion is that entering the realm of language (re)design vs. simply implementation is a risky move...
--On Sunday, January 12, 2003 02:50:59 +0100 Samuele Pedroni <pedronis@bluewin.ch> wrote:
Has anyone thought about features that Python does not have that should be in Minimal? My first candidate would be (ducks) macros,
as a final user visible feature, I hope not. As an implementation then invisible tool maybe/why not.
That's more or less how macros are used most places that have them. For instance, only three files in the non-compiled-in (i.e. non-core) parts of xemacs have any macros defined in them (and two of those are compatibility things for other versions of emacs, never even defined if running on an xemacs), but most packages use at least some of the macros defined in the core. From the outside, those macros just look like parts of the exported language. The one remaining user of defmacro is advice.el, which defines the generic before/after/around advice mechanism, which could also be regarded as part of the core, and probably will be in some future version.
since that could drastically simplify constructing core Python features. I have some thoughts on pythonic ways to do that which I need to write up.
there is really no pythonic way to do macros. You can check this python-dev thread
http://aspn.activestate.com/ASPN/Mail/Message/1076771
My personal opinion is that entering the realm of language (re)design vs. simply implementation is a risky move...
I have several things in mind for macros: 1) pyrex-like cdef as a means to implement interfaces to C modules, but instead of outputting C and compiling, having psyco's code generator build it. 2) More efficient struct and sstruct like modules to tie in with 1) 3) Means to (as another poster has suggested) build dictionaries, sets and list comprehensions including their syntax. 4) Advice, like the elisp version I mentioned above. This is probably the only one of these where I'd like to see a change in the language officially exported, and I'm not that fussed about it, frankly. 5) Possibly a hook to do templating language things without preprocessing and without horrible performance problems. In lisp dialects macros are mostly ways to build core syntax, and ways for the gurus to do scary things without killing performance, that usually result (so far as most users are concerned) in a special-purpose sublanguage. I think the latter already applies to python metaclasses, and would apply to macros too. My suggestion is really just a hook in a place where it doesn't already exist, on the before side of class definition where metaclasses come after. In the context of Minimal Python, macros provide a clean and consistent mechanism to reduce the C code by providing the hooks to build parts of the language in python. These don't already exist, and I'd prefer to see something generic than random hackery. Presuming that the parser will move to python, it would be a fairly natural use of python's dynamicism to allow define-time additions to the parser. Andrew
On the topic of macros et al: I think that delivering minimal python will be quite hard. If the mandate is to create a new implementation of Python, then I think that the syntax of current Python should be seen as a "minimal" requirement from a syntactic POV. New syntactic elements can clearly be defined as well, although naturally care should be taken to ensure that existing code still works. (so making 'spam' a reserved word probably wouldn't work). On the other hand, I'm going to lose interest in this project pretty fast if it turns into an _unsubstantiated_ argument about language design. If a new language construct is proposed as a fairly direct and well-supported way to get the implementation done better, faster, cheaper, then by all means. --david
From: "David Ascher" <DavidA@ActiveState.com>
On the topic of macros et al:
I think that delivering minimal python will be quite hard. If the mandate is to create a new implementation of Python, then I think that the syntax of current Python should be seen as a "minimal" requirement from a syntactic POV. New syntactic elements can clearly be defined as well, although naturally care should be taken to ensure that existing code still works. (so making 'spam' a reserved word probably wouldn't work).
On the other hand, I'm going to lose interest in this project pretty fast if it turns into an _unsubstantiated_ argument about language design. If a new language construct is proposed as a fairly direct and well-supported way to get the implementation done better, faster, cheaper, then by all means.
maybe I was not completely clear but that was my point too. I believe that an open parser architecture can do the trick (i.e. supporting necessary additional constructs) without the struggle of a debate on syntax/semantics of macros in python. I sense that toying with new language features at large risks to be rather non-constructive.
--On Saturday, January 11, 2003 21:03:55 -0800 David Ascher <DavidA@ActiveState.com> wrote:
On the topic of macros et al:
...
On the other hand, I'm going to lose interest in this project pretty fast if it turns into an _unsubstantiated_ argument about language design. If a new language construct is proposed as a fairly direct and well-supported way to get the implementation done better, faster, cheaper, then by all means.
Which is why I suggested it. I'm no expert on language design, but I can see that a standardised way to extend a language that starts out less than complete (as a Python core with major chunks removed will) is better than an ad-hoc mess. Someone else suggested a sufficiently extensible parser, if I follow their intent, and I agree entirely. In a sense, a macro system is just one possible interface to such an extensible parser. Another suggestion was to allow an in-python way to interface with c system calls and library functions. Scoped macros implementing a python derivative similar to pyrex have potential here, in the same way pyrex does for extending CPython. In lisp, I always felt macros were best provided by the language designer or library designers, as part of the language or library. Applications that made use of custom macros were generally hard to read, but if what they were doing was compiler-like (my case was symbolic math) usually made sense once understood. I suspect the same would be true of python. In other words, I think a macro system is a good way to get syntactical extensibility so that Minimal Python can acheive it's goals. I think users should be discouraged from writing them, because of the potential nightmares unusual macros cause, but certain standard packages could provide some macros at little cost to the pythonicality of the results. I think it would be pretty cool if 'from pyrex import *' led to following code having pyrex semantics; this would, I think, make it easier to get Minimal Python completed. I also think that if metaclasses can be pythonic, there's a pythonic way to do macros too, but if consensus is against that, then let them simply be an implementation detail of Minimal Python. Andrew
From: "Andrew McGregor" <andrew@indranet.co.nz>
Someone else suggested a sufficiently extensible parser, if I follow their intent, and I agree entirely. In a sense, a macro system is just one possible interface to such an extensible parser.
the problem is that getting that one interface right for user consumption is darn hard and citing Guido about macros in the thread I have referred to (that I hope you have read): "I've considered it, and rejected it. That doesn't mean you shouldn't bring it up, but I expect it would turn Python into an entirely different language."
I also think that if metaclasses can be pythonic, there's a pythonic way to do macros too, but if consensus is against that, then let them simply be an implementation detail of Minimal Python.
The issue is that using macros as a tool risks to trigger a debate on how to get them right and while in Lisp adding some form of macros is a no-brainer, this is not case for Python. So if they do not show to be inavoidable better leave the idea alone. An extensible parser with only a programmable interface can do the trick if necessary. If you want a debate about the pythonicity of macros and possible implementations of them IMO comp.lang.python is probably a better place. Honestly I don't hold my position because I dislike macros, I like macros in Common Lisp, I have thought about adding macros to Python and have partecipated to some debates about the issue. regards
[David Ascher Sat, Jan 11, 2003 at 09:03:55PM -0800]
On the topic of macros et al:
I think that delivering minimal python will be quite hard. If the mandate is to create a new implementation of Python, then I think that the syntax of current Python should be seen as a "minimal" requirement from a syntactic POV. New syntactic elements can clearly be defined as well, although naturally care should be taken to ensure that existing code still works. (so making 'spam' a reserved word probably wouldn't work).
On the other hand, I'm going to lose interest in this project pretty fast if it turns into an _unsubstantiated_ argument about language design. If a new language construct is proposed as a fairly direct and well-supported way to get the implementation done better, faster, cheaper, then by all means.
To me http://www.python.org/dev/culture.html has become kind of a mantra. IMO especially 'readability counts' constrains Macro ideas alot. Anyway, i am all for sticking to the language definition. Though I guess it will get easier to try out new syntax/semantic ideas. I think that the decisions from the python developers have generally been very wise and publically extending the language should really be accepted by the usual authorities. Of course, there might be some special rules or constructs in the bootstrapping process if that really helps. But even then, i think that these will be restrictions rather than extensions. Let's not give up the common coding style and readability. What might seem a gain in the short term might not play out well in the end. IOW I trust e.g. Guido more than my own judgement on these matters. regards, holger
holger krekel wrote:
[David Ascher Sat, Jan 11, 2003 at 09:03:55PM -0800]
On the topic of macros et al:
I think that delivering minimal python will be quite hard. If the mandate is to create a new implementation of Python, then I think that the syntax of current Python should be seen as a "minimal" requirement from a syntactic POV. New syntactic elements can clearly be defined as well, although naturally care should be taken to ensure that existing code still works. (so making 'spam' a reserved word probably wouldn't work).
On the other hand, I'm going to lose interest in this project pretty fast if it turns into an _unsubstantiated_ argument about language design. If a new language construct is proposed as a fairly direct and well-supported way to get the implementation done better, faster, cheaper, then by all means.
To me http://www.python.org/dev/culture.html has become kind of a mantra. IMO especially 'readability counts' constrains Macro ideas alot.
Anyway, i am all for sticking to the language definition. Though I guess it will get easier to try out new syntax/semantic ideas.
I think that the decisions from the python developers have generally been very wise and publically extending the language should really be accepted by the usual authorities. Of course, there might be some special rules or constructs in the bootstrapping process if that really helps. But even then, i think that these will be restrictions rather than extensions. Let's not give up the common coding style and readability. What might seem a gain in the short term might not play out well in the end.
IOW I trust e.g. Guido more than my own judgement on these matters.
You are absolutely right! We are not here for language design. That's already done by Guido, and he is right about it. We just want to try a different implementation. This is a high risk to be just a waste and something that the core group cannot afford to try, due to lack of time. What we effectively are doing is a prototype of a new implementation based upon new techniques. This is explorative programming, pioneer work, an experiment. We will see if it succeeds. It will help Python either way. ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
--On Sunday, January 12, 2003 16:37:32 +0100 Christian Tismer <tismer@tismer.com> wrote:
holger krekel wrote:
[David Ascher Sat, Jan 11, 2003 at 09:03:55PM -0800]
On the topic of macros et al:
I think that delivering minimal python will be quite hard. If the mandate is to create a new implementation of Python, then I think that the syntax of current Python should be seen as a "minimal" requirement from a syntactic POV. New syntactic elements can clearly be defined as well, although naturally care should be taken to ensure that existing code still works. (so making 'spam' a reserved word probably wouldn't work).
On the other hand, I'm going to lose interest in this project pretty fast if it turns into an _unsubstantiated_ argument about language design. If a new language construct is proposed as a fairly direct and well-supported way to get the implementation done better, faster, cheaper, then by all means.
To me http://www.python.org/dev/culture.html has become kind of a mantra. IMO especially 'readability counts' constrains Macro ideas alot.
Anyway, i am all for sticking to the language definition. Though I guess it will get easier to try out new syntax/semantic ideas.
I think that the decisions from the python developers have generally been very wise and publically extending the language should really be accepted by the usual authorities. Of course, there might be some special rules or constructs in the bootstrapping process if that really helps. But even then, i think that these will be restrictions rather than extensions. Let's not give up the common coding style and readability. What might seem a gain in the short term might not play out well in the end.
IOW I trust e.g. Guido more than my own judgement on these matters.
You are absolutely right!
We are not here for language design. That's already done by Guido, and he is right about it. We just want to try a different implementation. This is a high risk to be just a waste and something that the core group cannot afford to try, due to lack of time.
What we effectively are doing is a prototype of a new implementation based upon new techniques. This is explorative programming, pioneer work, an experiment. We will see if it succeeds. It will help Python either way.
ciao - chris
Fair enough. I simply thought that macros were an *old* technique that could be useful, even if only as part of the implementation, but the consensus is otherwise. I don't quite understand, but I'll shut up now :-) I guess the operative part of the culture document is #5, 'Flat is better than nested'. Please don't continue the thread, I'm convinced. Andrew
Andrew McGregor wrote: ...
Fair enough. I simply thought that macros were an *old* technique that could be useful, even if only as part of the implementation, but the consensus is otherwise. I don't quite understand, but I'll shut up now :-)
You are not meant to shut up! :) I'm just saying that I'm -1 on adding macros to Python, and even more to use TiPy as a vehicle for that. It is better to leave general design questions out of this young project. But if we do need something macro-like to quickly build up the new system, this might be a different issue. I'm open to anything that makes the implementation easier, faster, better maintainable, and I do appreciate your input.
I guess the operative part of the culture document is #5, 'Flat is better than nested'.
Please don't continue the thread, I'm convinced.
I don't continue the thread. But please don't feel stopped! cheers - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
David Ascher wrote:
On the topic of macros et al:
No macros!
I think that delivering minimal python will be quite hard. If the mandate is to create a new implementation of Python, then I think that the syntax of current Python should be seen as a "minimal" requirement from a syntactic POV. New syntactic elements can clearly be defined as well, although naturally care should be taken to ensure that existing code still works. (so making 'spam' a reserved word probably wouldn't work).
The last thing Minimal Python is targetted to is changing the language! We might decide to just implement a subset of the language, but we should really avoid to change anything, unless we have to. Changing the internals so radically as we are planning to do creates a lot of problems. I don't want to add language changes as yet another problem. With the new flexibility, which a re-implementation of Python in Python hopefully rpovides, it will be much easier to experiment with new language features than today. But before doing that, if at all, we need to get the basic stuff running. Especially for macros, I don't see any necessity right now. If we need to implement a template system for parameterizing often repeated python code, we have the simple approach to generate Python source from formatted template strings. If that is used extensively and turns out to be insufficient, we can think of something better. But nothing should be added before trying it without.
On the other hand, I'm going to lose interest in this project pretty fast if it turns into an _unsubstantiated_ argument about language design. If a new language construct is proposed as a fairly direct and well-supported way to get the implementation done better, faster, cheaper, then by all means.
I don't see any reason to add anything now. The purpose of MiniPy is to remove as much as possible, especially from the C code. Things can then be re-implemented in Python, they can be thought over and get a different design to try out. I also see no problem with the Python language as it is now. Most of it is available as Python code in the compiler module. Just a few internal things like the token parser and some others are only available as C code. We can either keep then as they are, or re-code them in Python. It is even thinkable to make certain existing language features pluggable an configurable. But again, thats future matters. Right now we need to get all available Pyhton code to run. That means to implement the minimum core that's needed, and don't mess with the language. ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Has anyone thought about features that Python does not have that should be in Minimal? My first candidate would be (ducks) macros,
as a final user visible feature, I hope not. As an implementation then invisible tool maybe/why not. IMHO the user visible language part should be 100% Python compatible. At least this should be the goal. But, in the build process of the Minimal Python core we could (and should?) use feature to simplify the implementation. Like generating source/classes from a formal description (eg. XML).
Marc "Premature optimization is the root of all evil." -- Donald E. Knuth
Marc Recht wrote:
Has anyone thought about features that Python does not have that should be in Minimal? My first candidate would be (ducks) macros,
as a final user visible feature, I hope not. As an implementation then invisible tool maybe/why not.
IMHO the user visible language part should be 100% Python compatible. At least this should be the goal. But, in the build process of the Minimal Python core we could (and should?) use feature to simplify the implementation. Like generating source/classes from a formal description (eg. XML).
I have the same goal. I also don't hesitate to use some abbreviative tools for repeated code, maybe. But only if it helps to simplify, not to change the language. Furthermore, thinking of macros again, they make less sense for me every time I think it over. Our final target is an intelligent code generator which generates optimized code from well-written Python. How could a macro system help here? We would instead loose structure and make optimization harder, since the macro generated code needs to be analysed and optimized, later. That is bullshit, IMHO. Abstractions, like metaclases, which specialize themselves into other concrete classes make more sense to me. This allows to optimize without loosing structural information. XML on the other hand, as an intermediate language or for pickling makes sense to me. At least it is easier to parse than Python. (But we *have* the parser...) -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
I have the same goal. I also don't hesitate to use some abbreviative tools for repeated code, maybe. But only if it helps to simplify, not to change the language. I was only thinking about the actual build process, not about the language itself.
Furthermore, thinking of macros again, they make [...] I 100% agree with you. Changing the language isn't a good idea.
XML on the other hand, as an intermediate language or for pickling makes sense to me. At least it is easier to parse than Python. (But we *have* the parser...) I thought about using XML as a formal description for generating stuff. For example CastorXML (a java xml databinding framework, http://castor.exolab.org) uses XML Schemata to generate simple data classes with XML marshaling/unmarshaling functionality.. Though I'm not sure at which part of the MiniPy build process generating code could be useful, I think it should be kept in mind.
"Premature optimization is the root of all evil." -- Donald E. Knuth
Marc Recht wrote:
I have the same goal. I also don't hesitate to use some abbreviative tools for repeated code, maybe. But only if it helps to simplify, not to change the language.
I was only thinking about the actual build process, not about the language itself.
Agreed! [XML]
I thought about using XML as a formal description for generating stuff. For example CastorXML (a java xml databinding framework, http://castor.exolab.org) uses XML Schemata to generate simple data classes with XML marshaling/unmarshaling functionality.. Though I'm not sure at which part of the MiniPy build process generating code could be useful, I think it should be kept in mind.
Will be kept in mind. Canning data structures into XML schemata can be very helpful. I had to do this in a large project, and it gave me lots of insights!
"Premature optimization is the root of all evil." -- Donald E. Knu th
Can you please make that sentence not wrap any longer? :-)
On Sun, Jan 12, 2003 at 02:32:54PM +1300, Andrew McGregor wrote:
Therefore a Pythonic macro should be:
A class which adds it's grammar
... Then the macro provides code which is called with the parse trees resulting from that grammar, modifies them, and returns the parse tree that will actually be compiled. If you want to evaluate some bits at compile time, do that explicitly in the macro (opposite way around to lisp, where you have complicated rules).
I want that! Here is an interpreted language that does that : http://pliant.cx/ Fully GPL. Source available. Worth a look. -- Nicolas Chauvat http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France)
On Mon, Jan 13, 2003 at 10:55:05AM +0100, Nicolas Chauvat wrote:
On Sun, Jan 12, 2003 at 02:32:54PM +1300, Andrew McGregor wrote:
Therefore a Pythonic macro should be:
A class which adds it's grammar
... Then the macro provides code which is called with the parse trees resulting from that grammar, modifies them, and returns the parse tree that will actually be compiled. If you want to evaluate some bits at compile time, do that explicitly in the macro (opposite way around to lisp, where you have complicated rules).
I want that!
Here is an interpreted language that does that : http://pliant.cx/
Fully GPL. Source available. Worth a look.
Note: I perfectly understand the goal of Minimal Python: do *not* change the language or parts of it (yet), just experiment with a minimal intepreter. That said, since Holger asked for desciptions of links here it goes: Both www.mozart-oz.org and pliant.cx (and others) are interesting for they rely on a minimal intepreter that lets one define part of the language itself (and basic ones like loop structure, for example). It can also be remarked that a good part of theoritically elegant languages (who said lisp?) rely on minimal interpreters. Having Python move forward in that direction may guarantee a nicer future for the language and should be easier to do thanks to the support of its large community. [back-to-lurking] -- Nicolas Chauvat http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France)
Christian Tismer wrote:
I believe, no. Instead, I think to supply a generic virtual machine which is easy to produce code for, tpgether with a very fast interpreter. That engine would run on any machine and would be enough to do the full bootstrap, when the specific machine is defined, later.
Is anyone on this list familiar with the current state of Parrot? All I know is: http://cvs.perl.org/cvsweb/parrot/ChangeLog?rev=1.4&content-type=text/x-cvsweb-markup Additionally, is anyone here familiar with some of the work that's been done on AOS, related to SmallScript, a version of SmallTalk (see e.g. http://www.smallscript.org/SmallScriptWebsite.asp#AOS). I have the impression that those folks have done some interesting work, although their non-open-source nature makes it hard to evaluate. --david
From: "David Ascher" <DavidA@ActiveState.com>
Is anyone on this list familiar with the current state of Parrot?
All I know is:
http://cvs.perl.org/cvsweb/parrot/ChangeLog?rev=1.4&content-type=text/x-cvsweb- markup http://www.amk.ca/conceit/parrot.html Right now they are sketching object support design: http://archive.develooper.com/perl6-internals%40perl.org/msg14408.html They have also started some collaboration with the DotGNU project. regards.
participants (9)
-
Andrew McGregor -
Christian Tismer -
Christian Tismer -
David Ascher -
Florian Schulze -
holger krekel -
Marc Recht -
Nicolas Chauvat -
Samuele Pedroni