On Sat, Sep 18, 2004 at 12:29:52AM -0500, Dan Hursh wrote:
> Jonathan Scott Duff wrote:
> >I think you meant something akin to C< /(.) { use PIR; print P0;}/ > and
> >C< /(.) { use Forth; P0 print}/ > :-) As long as we're special-casing
> >things and "hand parsing" we might as well use a small subset of Perl)
>
> Is perl actually going to allow arbitrary languages in the closures for
> REs? For languages that don't have a clean notion of closures or a
> friend idea of how to use curly brases, this sounds like quite a feature
> to implement even with a full perl6 compiler to start with.
I'm by no means an expert, but I'd say that the inner languages don't
need to have any idea of closure or of curly braces; those are Perl's
responsibility. Perl will package up the stuff between the curlies and
ship it off to another compiler. All that compiler needs to do is return
something that Perl can wrap up in a closure of its own (or, of course,
it could return an actual closure) Yes, there is always the possibiilty
Perl can't tell where the closing curly is, especially if the inner
language doesn't play well, but it can make a good guess and provide
mechanisms for the programmer to give hints.
You can s/Perl/the rules parser/ above for bootstrapping I think.
> Why not say the closures in perl's RE are always in perl (ignoring
> macros) and that you have to have eval functions/macros for the other
> languages like :
>
> rx{ <<foo>> { PIR :P0($<<foo>>) { print P0 } }
> rx{ <foo> { PIR<< print P0 >>} }
> rx{ <foo> { PIR <<EOPIR
> print P0
> EOPIR
> }
> }
>
> I guess saying PIR in every rule might get repetitive. It would be easy
> to special case in the bootstrap parser and would work in a way that
> would seem to make regular perl REs easier to manage.
That's kind of where I started with the { use PIR; ... } stuff up above.
You need some sort of quoting mechanism to delineate the other language
and you need some way to tell perl what the other language is, so why
not just use perl (or a small subset for bootstrapping) as the inner
language since it already has these things.
But the problems are the same no matter the syntax :)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
