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

Re: Now, to try again...

Thread Previous | Thread Next
Dan Sugalski
December 17, 2000 12:59
Re: Now, to try again...
Message ID:
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... :)


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai                         have teddy bears and even
                                      teddy bears get drunk

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