Hi, Günther said I could post this message he sent to me regarding his PEG parser code : :-)
> Hey Eric, > > sounds very good to me. :-) It's really great to hear you're working on a > workspace. I need to try this when I have time. :-) > > I commited the code in branches/guenther/ObjMeta or so. > > Here's some facts you should know however: > * Although aimed at it, this is not an OMeta implementation. At the moment > it's just a PEG implementation (which an OMeta implementation may hopefully > build on). > * I'm not completely sure whether I took the right approach to implement > OMeta with this. In some of the OMeta resources I found, there was much talk > of "bootstrapping", but I must admin I haven't looked enough to find out what > exactly was meant with this yet. > * It was probably back in late 2009 when I last hacked on it, so it may not > work out-of-the box but require some adjustments for newer Pragmatic > Smalltalk versions. > * Specifically, there is a TODO in the code where mutually recursively > depending class definitions were not possible in Pragmatic Smalltalk. (I > believe this would require a two-pass compilation, adding classes in the > first phase, methods in the second phase.) This may works with a fresh > LanguageKit or SmalltalkKit now, but I'm not up to date... > * A parsing expression in this implementation is a class instance. I was > tempted to use closures instead, but went for the class-based solution in > order to retain the possibility to move it to Objective-C if needed. > * As input, this doesn't work on strings, but on "lists" instead. The "list" > interface is informally described in the head comment. This is needed for > OMeta as well. > * I have a bad feeling that the list interface may be tricky to implement in > a clean way in Objective-C: It's tempting to make NSString implement it, but > then the things returned by #at: are atomic data types, not objects like in > Pragmatic Smalltalk. :-( > * The file consists of three main sections: The actual program, the TestCase > class, tests. (I couldn't figure out how to split this apart into different > files -- If you know, it'd be really cool if you could just write a short > howto or something similar on that topic.) The unit tests have about the same > size as the production code, both are around 350 lines. > > I believe that it's probably easiest to read the code in this order: > * The informal description of list in the header > * Its two implementations. > * The "operators" I overloaded for the tests (Starts with the comment "Just > for convenience, a few helpers.") > * The test cases. > > These are some of the file's more important classes: > * OMDictionary: A functional dictionary. > * OMParsingExpression: A Parsing Expression. #parseList: parses a "list" and > returns a parse result (OMParseMatch or OMParseFailure) > * OMParseMatch: Has a primary value (the parsing result, an AST for example), > and a dictionary which maps variable names to parts of the primary result > (IIRC). > * "Skeletons" are just closures receiving a dictionary and returning a parse > result (like the primary value for example) > > I hope you can use some of this. It should actually not be hard to write a > Smalltalk parser with it, you could probably just copy most of it from the > FONC project, if the license is compatible. > > Have fun, :-) > G?nther > _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
