S05: Interpolated hashes?
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. 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
Re: S05: Interpolated hashes?
On Mon, Apr 24, 2006 at 04:50:43PM +0300, Markus Laire wrote: 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 [EMAIL PROTECTED]
Re: S05: Interpolated hashes?
On Mon, Apr 24, 2006 at 09:49:36AM -0500, Jonathan Scott Duff wrote: : 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
Re: S05: Interpolated hashes?
Thanks, Scott Larry. 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 [EMAIL PROTECTED] 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
Re: S05: Interpolated hashes?
On Mon, Apr 24, 2006 at 08:00:55AM -0700, Larry Wall wrote: On Mon, Apr 24, 2006 at 09:49:36AM -0500, Jonathan Scott Duff wrote: : 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. Why don't we just have KEY work as an assertation, instead of having this strange as if thing? -=- James Mastros, theorbtwo
Re: S05: Interpolated hashes?
On Mon, Apr 24, 2006 at 05:22:25PM +0100, [EMAIL PROTECTED] wrote:
: 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
Re: S05: Interpolated hashes?
On 4/24/06, Larry Wall [EMAIL PROTECTED] 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.
BEGIN
.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
Re: S05: Interpolated hashes?
On Mon, Apr 24, 2006 at 08:00:55AM -0700, Larry Wall 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.
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
