eval should throw an exception on compile error

I was just playing around with eval, trying to figure out if you can define an operator overload at runtime (seems you can't, good) and noticed this in the spec... [1] "Returns whatever $code returns, or fails." How does one get the compile error from an eval? What's the equivalent to $@? I

Base conversion: not enough rope

S02:3185-3280 does a nice job of explaining what can and cannot be done with the radix syntax (i.e. :2<1010> etc). I'm left with two questions, however: * If :2<1010> is the way to way to "interpret" a string as a number in base two, giving the number 10 -- what's the way to go in the other direct

Re: rakudo :sigspace interpretation, [ |a] vs [a| ]

Carl (>>), Patrik (>): >> The fact that /[ |a]/ is a legal special case >> meaning /[a]/ helps confuse things a bit further. > > Where is this special case specified? // Carl

Re: rakudo :sigspace interpretation, [ |a] vs [a| ]

A side note: > The fact that /[ |a]/ is a legal special case > meaning /[a]/ helps confuse things a bit further. Where is this special case specified? 2011/5/6 Carl Mäsak : > Patrik (>): >>> I find nothing in the spec that addresses this case specifically. >> >> From the spec: >> >> The new :s (

Re: rakudo :sigspace interpretation, [ |a] vs [a| ]

On 05/06/2011 02:10 PM, Carl Mäsak wrote: > Patrik (>): >> Your link seems to specifiy how empty patterns are illegal. However, >> reading the :sigspace definition, I assume that rule {[ |a]+} is >> eqivalent to token {[<.ws>|a]+}, which not contains any empty pattern. > > I find nothing in the sp

Re: rakudo :sigspace interpretation, [ |a] vs [a| ]

> The rule about empty (sub-)regexes being illegal is applied before the > rule about everywhitespace being replaced by <.ws>. Where is that specified? 2011/5/6 Carl Mäsak : > Patrik (>): >>> I find nothing in the spec that addresses this case specifically. >> >> From the spec: >> >> The new :s (

Re: rakudo :sigspace interpretation, [ |a] vs [a| ]

Patrik (>): >> I find nothing in the spec that addresses this case specifically. > > From the spec: > > The new :s (:sigspace) modifier causes whitespace sequences to be > considered "significant"; they are replaced by a whitespace matching > rule, <.ws> > > I can't find any exception to this rule.

Re: rakudo :sigspace interpretation, [ |a] vs [a| ]

> I find nothing in the spec that addresses this case specifically. >From the spec: The new :s (:sigspace) modifier causes whitespace sequences to be considered "significant"; they are replaced by a whitespace matching rule, <.ws> I can't find any exception to this rule. Therefore, as I read it,

Re: rakudo :sigspace interpretation, [ |a] vs [a| ]

Patrik (>): > Your link seems to specifiy how empty patterns are illegal. However, > reading the :sigspace definition, I assume that rule {[ |a]+} is > eqivalent to token {[<.ws>|a]+}, which not contains any empty pattern. I find nothing in the spec that addresses this case specifically. (Though I

Re: rakudo :sigspace interpretation, [ |a] vs [a| ]

Your link seems to specifiy how empty patterns are illegal. However, reading the :sigspace definition, I assume that rule {[ |a]+} is eqivalent to token {[<.ws>|a]+}, which not contains any empty pattern. /Patrik Hägglund 2011/5/6 Carl Mäsak : > Patrik (>): >> The following program works as I exp

Re: rakudo :sigspace interpretation, [ |a] vs [a| ]

Patrik (>): > The following program works as I expect: > > grammar g { >  rule TOP {[a| ]+} >  rule ws {+} > } > g.parse('a a'); > say "'$/'"; > > gives me 'a a', > > but changing [a| ] into [ |a] gives me > > 'a' > > I suspect this is a problem in the rakudo implementation. Yes, but perhaps not a

rakudo :sigspace interpretation, [ |a] vs [a| ]

The following program works as I expect: grammar g {  rule TOP {[a| ]+}  rule ws {+} } g.parse('a a'); say "'$/'"; gives me 'a a', but changing [a| ] into [ |a] gives me 'a' I suspect this is a problem in the rakudo implementation. /Patrik Hägglund