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 $.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($.from) ... }
to start parsing from the beginning of the key. (Optional arg to
:pos and :continue just added to S05, by the way.)
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 $.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 05:22:25PM +0100, [EMAIL PROTECTED] wrote:
: Why don't we just have 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 $.beg works fine for that,
and $ itself works fine for retraversing the key if you need to.
In fact, that's true in either direction, so you can negatively traverse
$ in reverse within a lookbehind:
token macro_only_after_foo ($isparsed) {
< $ >> <$isparsed>
}
Larry
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 $ and you > : may again match the actual key that matched with the 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 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 $.beg, or whatever the name of the method is. Hmm, > that looks like it's unspecced. Why don't we just have work as an assertation, instead of having this strange "as if" thing? -=- James Mastros, theorbtwo
Re: S05: Interpolated hashes?
Thanks, Scott & Larry. IMHO, the explanation about and $ 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 $.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 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 $ and you : may again match the actual key that matched with the 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 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 $.beg, or whatever the name of the method is. Hmm, that looks like it's unspecced. Larry
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 > > 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.) > > > And under "Extensible metasyntax (<...>)" it's said that > > 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 assertion. > That is, $ 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. > > > 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 $ and you may again match the actual key that matched with the assertion. In my example, $ will contain the text "food" . Also, by using the 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. 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/ / # require des() if m:c/ / # desire I assume that is somehow magically anchored to the spot where the key actually matched. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
