Re: Now, to try again...
[email protected] (Dan Sugalski) Sun, 17 Dec 2000 15:41:24 -0500
| Newsgroups | perl.perl6.internals.api.parser |
|---|---|
| Message-ID | <[email protected]> |
At 02:24 PM 12/17/00 -0500, Sam Tregar wrote: >On Sun, 17 Dec 2000, David Grove wrote: > > > That sounds too complex for what seems like a more simple solution. When > > you say "turn simple 'languages' into perl", that's what Dan's told me is > > my source filter. Actually, it's a bit more than a source filter. The goal > > would be to turn the creole language into perl, but not necessarily by > > filtering it, at least not solely. It can also map creole lexemes to perl > > lexemes (within the context of a more complex more-than-filter filter). > >I imagine that Larry will weigh in on this subject, but I'd like to >comment anyway. How useful is a "little language" so similar to Perl 6 >that you can use Perl 6's parser to parse it? Anything substantially >different is going to require its own parser. > >It comes down to what is meant by "little language". When I hear that >term I immediately think Scheme and TCL. For my part, at least, I've been thinking of something either LISP-ish or very simple parameter setting/checking (like stuff in, say, your average .rc file with a little control flow thrown in) when it's brought up. Occasionally things FORTHish, but only when I really desperately need sleep. :) It is sort of a language design issue, but in many ways it depends on what sort of facilities we can provide with reasonable cost. > > Must a creole parser/lexer be invented that outputs a source tree, or > > could it be as simple as translating to a common form (Perl 6 language > > spec) and having only that common form be turned into our source tree? > >I imagine this could be left up to the "creole" parser. It could call the >Perl 6 parser any time it wants, but I don't see why it should have to! >Ultimately any parser that interfaces with the Perl parser API will have >to produce Perl 6 bytecode. If it needs help getting there, that's ok. Nope, not bytecode--a syntax tree. (Though it could go the whole bytecode route if it wants, I suppose) Going full bytecode's not necessary. > > the former would be faster but would almost certainly be a programming > > nightmare... at least it would complicate things beyond common sense. > >What? I don't think anyone expects writing a new frontend for Perl 6 to >be an easy job but "a programming nightmare"? "Beyond common sense"? I'm >not suggesting they program it in StoryServer! Gah! That's an evil thought. (Keep it up and you'll get tasked with the JCL filter... :) Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai [email protected] have teddy bears and even teddy bears get drunk