develooper Front page | perl.perl6.internals.api.parser | Postings from December 2000

Re: Now, to try again...

Thread Previous | Thread Next
David Grove
December 17, 2000 10:21
Re: Now, to try again...
Message ID:

Andy Dougherty <> 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
 > > 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
 > hold up the entire process.  It would be quite ironic if perl6 never
 > off the ground because we can't figure out how to make 'use Java;'

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

 > "Little languages", on the other hand, are a somewhat different matter.
 > They will presumably be not-so-complex and hence won't require such
 > 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
 > how
 > > this multiple-input-style thingy is going to work? Can work? Should
 > 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
 > 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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About