Re: Now, to try again...
[email protected] ("David Grove") Sun, 17 Dec 2000 12:17:43
| Newsgroups | perl.perl6.internals.api.parser |
|---|---|
| Message-ID | <[email protected]> |
Andy Dougherty <[email protected]> wrote: > On Sat, 16 Dec 2000, David Grove wrote: > > > Because what is the parser/lexer/tokenizer parsing? Perl? Pythonic? > > Javanese? All of them? Thinking of just the parser as a single entity > > seems to me to be headed into trouble unless we can define in advance > what > > type of role these dialects will play in the language, and at what point > > they merge into a single entity and how. > > Now matter how we slice it, it's going to be very hard for the first > person to twist perl6 to parse something that is both complex and very > different from Perl6. And I'm unconvinced that this difficulty ought to > hold up the entire process. It would be quite ironic if perl6 never gets > off the ground because we can't figure out how to make 'use Java;' easy. I'm not sure that it would hold up anything, as it's (in my theory) a separate process. It can develop independently from the main perl parser/lexer, as long as the way of interfacing with the latter is predefined. > "Little languages", on the other hand, are a somewhat different matter. > They will presumably be not-so-complex and hence won't require such deep > hooks, and some redundancy there won't be such a big problem. I'm not sure how this is incongruent with your first paragraph. Could you elaborate a bit? > > Or, perhaps a more direct question. Has anyone given any thought about > how > > this multiple-input-style thingy is going to work? Can work? Should work? > > That's a good question. > > Another route to keep in mind is spending effort working on and with > things such as perl-byacc (and maybe even the yet-to-be-written perl-lex) > that help turn simple "languages" into perl. 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). Either way, if a creole is used, wouldn't what parses it come before any perl-language parsing if a scanner detects that it's going to be used? I mean, it's a bit convoluted, but I'm seeing two initial processes before the perl parser/lexer: 1. scan for creole pragmata 2. if they exist, preprocess 3. perl parser/lexer... etc 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? The latter may make parsing slower and but would be programmer friendly, the former would be faster but would almost certainly be a programming nightmare... at least it would complicate things beyond common sense. p