"Ruud H.G. van Tol" schreef:
> Juerd:
>> autrijus:
>>> -&foo.($arg1, $arg2);
>>> +&foo. ($arg1, $arg2);
>> [...]
>> Please reconsider.
>
> Yes, please come up with a different character to
> bridge/cross/hide/cloak/skip/zap the succeeding "not allowed"
> whitespace.
>
> Maybe the "\"
On 4/6/06, Larry Wall wrote:
On Thu, Apr 06, 2006 at 10:18:48PM +0800, Audrey Tang wrote:
: TSa wrote:
: > And a self($_.bar) is pretty much useless. In other words
: > wrongly huffmanized.
:
: FWIW, I agree with both points.
I agree with those points too, but not necessarily the conclusion.
S
Larry Wall skribis 2006-04-06 9:01 (-0700):
> Okay, we could revert it, and .foo would remain term/operator sensitive,
> and retroactively eat preceding whitespace when an operator is expected.
Or change the definition so that something that looks like a method
call IS a method call, and that you
[EMAIL PROTECTED] wrote:
We can't. The problem is that:
foo .bar
has to mean:
foo($_.bar)
So the only way to allow whitespace in dot operations is to put it
after the dot.
Damian
I believe Larry's latest updates to Synopses allow for some syntactic
categories to be disabled in
On Thu, Apr 06, 2006 at 10:18:48PM +0800, Audrey Tang wrote:
: TSa wrote:
: > Note that a prominent, typical foo actually reads:
: >
: > self .bar;
: >
: > And a self($_.bar) is pretty much useless. In other words
: > wrongly huffmanized.
:
: FWIW, I agree with both points. Some more points:
TSa wrote:
> Note that a prominent, typical foo actually reads:
>
> self .bar;
>
> And a self($_.bar) is pretty much useless. In other words
> wrongly huffmanized.
FWIW, I agree with both points. Some more points:
* I think both "say(.meth)" or ".meth.say" are more succinct/readable
than "sa
HaloO,
Damian Conway wrote:
We can't. The problem is that:
foo .bar
has to mean:
foo($_.bar)
So the only way to allow whitespace in dot operations is to put it after
the dot.
The obvious alternative is to make 'foo .bar' simply mean
'call foo and dispatch .bar on the return value'
Juerd schreef:
> autrijus:
>> -&foo.($arg1, $arg2);
>> +&foo. ($arg1, $arg2);
> [...]
> Please reconsider.
Yes, please come up with a different character to
bridge/cross/hide/cloak/skip/zap the succeeding "not allowed"
whitespace.
Maybe the "\", making "\" mean "s:s/\s+//".
--
Gr
Damian Conway skribis 2006-04-06 20:41 (+1000):
> >Please reconsider.
> We can't. The problem is that:
> foo .bar
> has to mean:
> foo($_.bar)
> So the only way to allow whitespace in dot operations is to put it after
> the dot.
Given the consequences of this constraint, I think that perh
Juerd wrote:
+C<.()> operator, which allows you to insert optional whitespace after the dot:
-&foo.($arg1, $arg2);
+&foo. ($arg1, $arg2);
Please reconsider.
We can't. The problem is that:
foo .bar
has to mean:
foo($_.bar)
So the only way to allow whitespace in dot
[EMAIL PROTECTED] skribis 2006-04-05 22:30 (-0700):
> Whitespace is not allowed before the parens, but there is a corresponding
> -C<.()> operator, which allows you to insert optional whitespace before the
> dot:
> +C<.()> operator, which allows you to insert optional whitespace after the
> dot:
HaloO,
[EMAIL PROTECTED] wrote:
* S02: fix the three places where the old form:
$x .(...)
needs to be replaced to the new form:
$x. (...)
-&foo.($arg1, $arg2);
+&foo. ($arg1, $arg2);
What is the reason for this change? I find the
old definition of whitespace before
12 matches
Mail list logo
