S05: Interpolated hashes?
Markus Laire
Under "Variable (non-)interpolation" it's said that
<quote>
An interpolated hash matches the longest possible key of the hash as a
literal, or fails if no key matches. (A "" key will match anywhere,
provided no longer key matches.)
</quote>
And under "Extensible metasyntax (<...>)" it's said that
<quote>
With both bare hash and hash in angles, the key is counted as
"matched" immediately; that is, the current match position is set to
after the key token before calling any subrule in the value. That
subrule may, however, magically access the key anyway as if the
subrule had started before the key and matched with <KEY> assertion.
That is, $<KEY> will contain the keyword or token that this subrule
was looked up under, and that value will be returned by the current
match object even if you do nothing special with it within the match.
</quote>
I don't quite understand how these relate to each other. First text is
clear enough, but second seems to be something totally different.
Could someone give an example of what difference there's between
"interpolated hash matches the longest possible key of the hash as a
literal, or fails if no key matches." and "the key is counted as
"matched" immediately; that is, the current match position is set to
after the key token before calling any subrule in the value. ..."
I don't quite understand if the key is matched in the second version
or if it's just counted as "matched", whatever that means, and why the
description is so dis-similar to the first quote.
--
Markus Laire
Jonathan Scott Duff
> In Synopsis 5 (version 22),
>
> Under "Variable (non-)interpolation" it's said that
> <quote>
> An interpolated hash matches the longest possible key of the hash as a
> literal, or fails if no key matches. (A "" key will match anywhere,
> provided no longer key matches.)
> </quote>
>
> And under "Extensible metasyntax (<...>)" it's said that
> <quote>
> With both bare hash and hash in angles, the key is counted as
> "matched" immediately; that is, the current match position is set to
> after the key token before calling any subrule in the value. That
> subrule may, however, magically access the key anyway as if the
> subrule had started before the key and matched with <KEY> assertion.
> That is, $<KEY> will contain the keyword or token that this subrule
> was looked up under, and that value will be returned by the current
> match object even if you do nothing special with it within the match.
> </quote>
>
> I don't quite understand how these relate to each other. First text is
> clear enough, but second seems to be something totally different.
Indeed, they are saying different things about what happens when you
match a hash against a string.
> Could someone give an example of what difference there's between
> "interpolated hash matches the longest possible key of the hash as a
> literal, or fails if no key matches." and "the key is counted as
> "matched" immediately; that is, the current match position is set to
> after the key token before calling any subrule in the value. ..."
>
> I don't quite understand if the key is matched in the second version
> or if it's just counted as "matched", whatever that means, and why the
> description is so dis-similar to the first quote.
What those two passages are saying is that when you match with a hash,
the longest key that matches will trigger the value portion of the
hash to execute (what "execute" means depends on the nature of the
value. See S05 for more details) Given, for example, the following:
my %hash = (
'foo' => ...,
'food' => ...,
);
"I need some food for breakfast" ~~ /%hash/;
That first passage says that "food" must match since it's the longest
key that matches, so whatever the ... for the "food" key is will
execute. The second passage says that the "match cursor" is
placed just after the key that matched. So any subsequent matches to
that string that do not reset the cursor will start just after the
word "food".
But what if your subrule needs to know exactly which key matched or
needs to match the key again for some reason? The second passage says
that you may access they actual text that matched with $<KEY> and you
may again match the actual key that matched with the <KEY> assertion. In
my example, $<KEY> will contain the text "food" . Also, by using the
<KEY> assertion, you can start matching at the beginning of the key
(rather than just after it) and again match the same key of the hash
that caused the match to succeed in the first place.
<speculation>
Why would you need to match the key again? Maybe your subrule needs to
know what came before the key in order to perform some action:
req() if m:c/ <after need .*?> <KEY> / # require
des() if m:c/ <after want .*?> <KEY> / # desire
I assume that <KEY> is somehow magically anchored to the spot where
the key actually matched.
</speculation>
-Scott
--
Jonathan Scott Duff
du...@pobox.com
Larry Wall
: But what if your subrule needs to know exactly which key matched or
: needs to match the key again for some reason? The second passage says
: that you may access they actual text that matched with $<KEY> and you
: may again match the actual key that matched with the <KEY> assertion.
Close, but that last bit isn't quite true. If you read the passage
again carefully, you'll note the magic words "as if". There is no
actual <KEY> assertion, only the remaining smile, like a Cheshire cat.
If you want to reset to before the key for some reason, you can always
set .pos to $<KEY>.beg, or whatever the name of the method is. Hmm,
that looks like it's unspecced.
Larry
Markus Laire
IMHO, the explanation about <KEY> and $<KEY> could be moved to where
the bare hash behaviour is explained as hash-in-angles-section already
says "A leading % matches like a bare hash except ..."
On 4/24/06, Larry Wall <la...@wall.org> wrote:
> If you want to reset to before the key for some reason, you can always
> set .pos to $<KEY>.beg, or whatever the name of the method is. Hmm,
> that looks like it's unspecced.
This seems interesting. From day-to-day it becames harder to fully
understand this perl6 thing, but I like it :)
--
Markus Laire
ja...@mastros.biz
strange "as if" thing?
-=- James Mastros,
theorbtwo
Larry Wall
: Why don't we just have <KEY> work as an assertation, instead of having this
: strange "as if" thing?
'Cause the point of most parsing is to rapidly move on, not to rehash the
ground you already covered. And if you really do need to reparse, you
need to set the position *anyway*, so $<KEY>.beg works fine for that,
and $<KEY> itself works fine for retraversing the key if you need to.
In fact, that's true in either direction, so you can negatively traverse
$<KEY> in reverse within a lookbehind:
token macro_only_after_foo ($isparsed) {
<<after foo <ws> $<KEY> >> <$isparsed>
}
Larry
Jerry Gay
> set .pos to $<KEY>.beg, or whatever the name of the method is. Hmm,
> that looks like it's unspecced.
>
.beg looks over-huffmanized to me. .begin is more natural to
english-speaking programmers, who have been using begin and end for
decades. if .beg will be used as .end's pair, i suggest this be kept
consistent, and BEGIN{} blocks be renamed as well.
BEGging the compiler to execute a block first is a mnemonic device,
but it doesn't work with the first example.
END
~jerry
Larry Wall
: set .pos to $<KEY>.beg, or whatever the name of the method is. Hmm,
: that looks like it's unspecced.
I'm wrong, it's already specced as .from and .to methods. So you can write
mytoken => rule { :pos($<KEY>.from) ... }
to start parsing from the beginning of the key. (Optional arg to
:pos and :continue just added to S05, by the way.)
Larry