Larry Wall writes:
> On Mon, Feb 02, 2004 at 02:09:33AM -0700, Luke Palmer wrote:
> : method if_statement::code($rc) { # $rc is the regcounter
> : self.item[0].code($rc.next('condition'))
> : ~ "unless $rc{condition}, $rc{Lfalse}\n"
> : ~ self.item[1].code($rc.next)
> : ~ "$rc{Lfalse}:\n"
> : }
>
> What do you want Perl 6 to do for you here?
Beats me. I was just throwing it out there. Maybe it would spark an
idea somewhere.
> : We've already gone over this, but it'd be good to have the ability for
> : parsers to (somehow) "feed" into one another, so that you can do
> : comments without putting a <comment> in between every grammar rule (or
> : mangling things to do that somehow), or search and replace, which has
> : the disadvantage of being unable to disable comments during parts of the
> : parse. $Parse::RecDescent::skip works well, but I don't think it's
> : general enough.
>
> Agreed. I do think you want the comments in the grammar, if for no
> other reason than it provides a hook to do something with the comment
> if you retarget the grammar from normal compilation to, say, code
> translation. I don't think it's out of the realm of possibility for
> Perl 6 to support strings with embedded objects as funny characters.
> In the limit, a string could be composed of nothing but a stream of
> objects. (As a hack, one can embed illegal Unicode characters (above
> U+10FFFF) that map an integer to an array of objects, but maybe we can
> do better from a GC perspective.)
For implementation we'd surely be better off using some kind of list of
linked objects and strings. The pattern engine that I'm about to
propose to p6i wouldn't have a problem with that, efficiency wise.
But, after all, this is perl6-I<language>, so no more internals talk :-).
And exactly (or fuzzily) how might this be done, syntax wise?
"foo $bar baz"
Stringifies $bar and concatenates it into the string. C<~> does the
same thing. Perhaps Object.aschar or something.
But then there's how you extract such things. C<substr $s, $n, 1> might
return an object, but C<substr $s, $n, 2> would always return a string.
That's almost, but not quite, completely unexpected.
Maybe it'd be better to generalize into the realm of tokens. A token
could consist of a string, which is matched against with the normal
regex stuff. Or it could consist of an object, which would match the
<SomeClass> rule and fail on most else (extensibly, though).
Objects underlying a string containing their stringified representations
still sounds pretty good, though. Especially if we use eg. U+110000 as
the "object character", so objects that don't want to be matched like
ordinary text can treat themselves as embedded objects.
Luke
