> > same or greater ease than pod for build and configuration.
> >
> > >
> [...]
> > >
> >
> > That is an excellent description of why THIS IS COMPLETE
> > MADNESS.
Maybe I'm reading too much into the comment, but I thought the big deal was
that the example given was not only verbose, but w
> > And how about:
> >
> > int length = 256 ;
> >
> > and, if that's legal, what does:
> >
> > print "I wonder what this is : " . length ;
> >
> > do?
> I imagine the first order of business for the C JIT team would be
> some conversion operators. Numeric types stringify int
> > s/x/5/; # this is still going to replace
> > # all the eckses in $_ with fives.
> Why? This is an arbitrary decision if you've declared variables to
be
> barewords.
I think it's a sane decision -- IMHO barewords shouldn't be allowed to
> > (Or, was it already intended that the implementation of 'use
> > invocant' might be some sort of compile-time macro?)
> No. I think a macro facility for Perl should be more general than just
> whacking some code in at the start of every subroutine.
Yes. I didn't phrase my comments well
Damian Conway:
> My forthcoming proposal will be that invocants still be passed as $_[0]
> by default, but that there be a pragma allowing $_[0] to be automagically
> shifted somewhere else during dispatch. For example:
>
>
> sub method { print "I was called through: $_[0]";
>
Karl Glazebrook wrote:
> But what is $x[3] ?
> It could be a scalar.
> BUT it could be a reference to a list.
> It could be a reference to a 2D PDL image.
... but references are scalar. So, $x[3] *is* a scalar.
That scalar could be a reference to a list. It could be a reference to a 2D
