On Tue, 5 Aug 2003, Stephen Thorne wrote:
Thus the code generator is best suited to be in a language that can be run from within the parrot machine, otherwise statements like 'eval()' would not be possible without binding parrot to a non-portable C library.
I would instead suggest that we pick a suitable 'dynamic' language to write the code generator in, so it can be self-hosting.
Sure. That's why I said stick to C or parrot. I'm not sure I understand why C wouldn't be portable... (I don't know c at all but I thought that was the point)?? I'd much rather use parrot. Where "parrot" means something else compiled down to parrot, and "something else" means python. :)
The original thought was to use the new perl 6 grammar engine/code to do this, but I think it'll be a while before that's ready to go.
Rather than invent an entirely new language for this (which is somewhat problematic) why not go for something already reasonably well-known? YACC and BNF grammars seem like a good place to start, especially as most of the languages have some form of grammar defined for them.
It's only a first step, as then everyone beats the heck out of the resulting token stream, but it's a place to start. 80-90% of the result will end up being generically parseable as well--"x + y" will generate the same code for all languages if x and y are PMCs, for example, so I'd bet we could have a lot of standard products designed.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
