Front page | perl.perl6.internals.api.parser |
Postings from December 2000
Re: Now, to try again...
From: Dan Sugalski
December 17, 2000 12:59
Re: Now, to try again...
Message ID: firstname.lastname@example.org
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
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
email@example.com have teddy bears and even
teddy bears get drunk