On Thu, 7 Aug 2003, Dan Sugalski wrote: > > haskell_parser -> ast -> pirate -> parrot_code --> imcc -> pbc > > ^ > > | > > parrot_code__templates > > > > > >So the haskell parser only has to generate a pirate ast structure. > >Either that's a very basic string (I like your XML idea) *or*, in > >the future, the parser calls pirate tree-building-methods directly. > > I'd much rather go for the AST directly for a number of reasons. Not > the least of which is a deep personal loathing for XML, but putting > that aside it seems sub-optimal to have a binary structure which we > then serialize to text and then deserialize all as part of a single > parse and compile stage. XML has the added disadvantage of needing a > good XML parser, which probably means expat or something like it. > (Yeah, I know, we could restrict ourselves to a subset of XML so we > don't have to have a full parser, but that'll never last--someone'll > expand it to a full parser at some point)
Klaas-Jan and I spiked out a prototype last night that took s-expressions. We got this working: (while (const 1) (pass)) Where While was a class that could be subclassed for PythonWhile (python has an extra "else" clause in there) I think everyone agrees that long term, there's no point in passing around xml or s-expressions because it'll be dog slow, but for now, for prototyping, passing the flattened AST in as an s-expression on STDIN means that anyone can write to it and we don't have to worry about a tree-building interface until after the code is working. > Going for a full-fledged AST builder/flattener meets some of the > long-term goals as well, as it's been planned to be the stage between > the parser and IMCC for ages (pretty much since IMCC first appeared) > so it'd be worthwhile. I agree. The main reason to hold off *FOR NOW* is bindings. If everyone wrote their parsers in C, then we could just use that. But I don't feel like learning C, so... Right now the code is in python. I suspect eventually this will be written in perl6 or someting. > We should consider AST transforms as well, since a number of > optimizations are best performed on the AST, and many languages will > want to get hold of the AST before it goes any further and process it > in some way. (This would be how Lisp macros would act, for example) Absolutely. I suspect that for python, I'll be turning list comprehensions into the corresponding "foreach" nodes before serializing the tree. > > > 1.) Instead of forcing the compiler writer to generate code, the > >> compiler writer would only have to transform the parse tree into a > >> structure that is name-consistant with the GCG's standard, and then > >> use any of a number of existing libraries to dump the tree as > >> YAML/XML. > > > >I like it! :) > > This'd be a cool thing to be sure, and useful as a human-readable > form. (Though I'd prefer the AST that's frozen into the bytecode be > in a form that's more efficient to deserialize) I'd best go and > update the license terms then, to make sure there aren't any > problems. (Old issues raised by GCC an age ago) I'm not sure I follow this. Sincerely, Michal J Wallace Sabren Enterprises, Inc. ------------------------------------- contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --------------------------------------
