Re^2: Tales from writing a RPN evaluator in Perl 5, Perl 6 and Haskell

You are right. My intent was to use /^-?\d+$/ but somehow I "forgot" to insert the anchors. :-( Curiously, when emulating the regex in hand-rolled Haskell code, I somehow "remembered" to insert the anchors. :-) I've updated the Perl code in the root node by inserting the anchors. The Haskell isStrDigit function already checks for all digits (equivalent to using the anchors) and so does not require update. Thanks ambrus.

Comment on Re^2: Tales from writing a RPN evaluator in Perl 5, Perl 6 and Haskell

Replies are listed 'Best First'.
Re^3: Tales from writing a RPN evaluator in Perl 5, Perl 6 and Haskell by TimToady (Parson) on Jan 05, 2006 at 17:21 UTC
This sort of mistake is one of the reasons we're thinking about distinguishing two different levels of pattern match in Perl 6, which we're currently calling "token" matching and "rule" matching, for lack of better names. Rule matching does scanning while token matching doesn't. When a token is matched from within a rule it has to match at the current location, and it's the embedding of the token within the rule match that allows other stuff to match after the token. By itself, a token must match an entire string (maybe with surrounding whitespace). So eventually we should have a way to just ask if the string matches a "num" or "int" pattern of some sort by pretending the token matcher is a subroutine or method of some sort. Perhaps somewhere in the relationship between tokens and rules we also can manage whitespace without scattering modifiers everywhere.	[reply]

Replies are listed 'Best First'.

Re^3: Tales from writing a RPN evaluator in Perl 5, Perl 6 and Haskell
by TimToady (Parson) on Jan 05, 2006 at 17:21 UTC

This sort of mistake is one of the reasons we're thinking about distinguishing two different levels of pattern match in Perl 6, which we're currently calling "token" matching and "rule" matching, for lack of better names. Rule matching does scanning while token matching doesn't. When a token is matched from within a rule it has to match at the current location, and it's the embedding of the token within the rule match that allows other stuff to match after the token. By itself, a token must match an entire string (maybe with surrounding whitespace). So eventually we should have a way to just ask if the string matches a "num" or "int" pattern of some sort by pretending the token matcher is a subroutine or method of some sort. Perhaps somewhere in the relationship between tokens and rules we also can manage whitespace without scattering modifiers everywhere.

[reply]