In article <[EMAIL PROTECTED]>, Darren Duncan
<[EMAIL PROTECTED]> wrote:
> At 3:20 PM -0500 10/6/07, brian d foy wrote:
> >For comparisons, how are we going to use Inf and NaN? Are those going
> >to be special flyweight objects, so:
> >
> >$x = 1 / 0;
> >
> >$x == Inf;# is it the sa
In article <[EMAIL PROTECTED]>, Moritz Lenz
<[EMAIL PROTECTED]> wrote:
> brian d foy wrote:
> > * If I can match $x to NaN (or its stand-in), what happens when $x is
> > undef?
>
> undef is a property of the container variable (that it holds no value),
> whereas NaN is a property of the content
On 10/6/07, brian d foy wrote:
That looks like it might mean that these are corresponding forms:
8 => 377:8<377>:8(377)
Now, if I can do that, what happens to the pair form in a hash composer
when I want the key of '8' and the value of :10<377>?
What happened to the suggestion of us
On 10/7/07, Mark J. Reed <[EMAIL PROTECTED]> wrote:
> I would argue for disallowing the all-jammed-together case, lest we
> run into longest-match arguments where "foobar:baz" is "foobar: baz"
> but "foo:barbaz" is "foo :barbaz". Yuck.
Uh, that doesn't make sense. Longest match arguments are lef
Visually, I interpret ":a" as a token unto itself, though that's
probably Ruby's fault. That interpretation would man that the
dual-whitespace version would have to be an indirect object.
I would argue for disallowing the all-jammed-together case, lest we
run into longest-match arguments where "f
If I've got this right:
mangle $foo :a;# mangle($foo, a => 1);
mangle $foo: a;# $foo.mangle(a());
So these --
mangle $foo:a;
mangle $foo : a;
are ambiguous and, as far as I can tell from the synopses, undefined. So
what's the rule: that indirect-object colon needs whitespace after but
