> "a" == autrijus <[EMAIL PROTECTED]> writes:
a> +In numeric context (i.e. when casted into C or C), a Hash object
s/casted/cast/.
i caught this one the other day. looks like the lesson didn't take so we
will have to punish you. you must rewrite pugs in python! MUAHAHAHAHAH!!!
a> +beco
Author: autrijus
Date: Thu Apr 6 01:12:52 2006
New Revision: 8593
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S13.pod
Log:
* S02/S13: s/casted/cast/, as suggested by Uri.
Modified: doc/trunk/design/syn/S02.pod
===
> +If this MMD dispatch succeeds, the result becomes the result of the
> +of the reduce.
"MMD dispatch" ~~ "RAS syndrome"
Also note the two "of the"s.
> +Otherwise, if the MMD dispatch fails, then if there is one argument,
> +while the single argument form can MMD dispatch based on the type of
D
Author: autrijus
Date: Thu Apr 6 01:29:34 2006
New Revision: 8594
Modified:
doc/trunk/design/syn/S03.pod
Log:
* More grammar nits, from Daniel Hulme
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/
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
[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:
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
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 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
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'
Subversion logging messages like the one below seem to be flooding this
list right now. May I ask if that's what this list is for?
Best wishes,
Rutger
[EMAIL PROTECTED] wrote:
Author: autrijus
Date: Wed Apr 5 19:08:28 2006
New Revision: 8569
Modified:
doc/trunk/design/syn/S02.pod
doc/t
On Wed, Apr 05, 2006 at 07:24:30PM -0700, Rutger Vos wrote:
> Subversion logging messages like the one below seem to be flooding this
> list right now. May I ask if that's what this list is for?
Well, it gets the people interested in the language design first cut at
the changes being made to the
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
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:
[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
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
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
"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 "\"
All~
I just noticed something claiming that C<$a. foo()> is actually
C<$a.foo()> (a method call on C<$a>) and that C<$a .foo()> is actually
C<$a $_.foo()> (likely a syntax error).
When did this change? Why did this change?
Also, I liked it better when C<$a .foo()> was a method call on C<$a>.
T
On Thu, Apr 06, 2006 at 01:58:55PM -0400, Matt Fowles wrote:
: All~
:
: I just noticed something claiming that C<$a. foo()> is actually
: C<$a.foo()> (a method call on C<$a>) and that C<$a .foo()> is actually
: C<$a $_.foo()> (likely a syntax error).
:
: When did this change? Why did this change
Larry~
On 4/6/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 06, 2006 at 01:58:55PM -0400, Matt Fowles wrote:
> : All~
> :
> : I just noticed something claiming that C<$a. foo()> is actually
> : C<$a.foo()> (a method call on C<$a>) and that C<$a .foo()> is actually
> : C<$a $_.foo()> (lik
On Thu, Apr 06, 2006 at 02:35:53PM -0400, Matt Fowles wrote:
: That makes a good deal of sense. I don't know what I would like more,
: so I guess that I will wait till a more firm consensus is reached.
The current consensus on #perl6 is that, in postfix position only (that
is, with no leading whi
On Thu, Apr 06, 2006 at 12:10:18PM -0700, Larry Wall wrote:
> The current consensus on #perl6 is that, in postfix position only (that
> is, with no leading whitespace), m:p/\.+ \s / lets you embed
> arbitrary whitespace, comments, pod, etc, within the postfix operator.
>
> This allows both the sho
On Thu, Apr 06, 2006 at 03:38:59PM -0400, John Macdonald wrote:
> On Thu, Apr 06, 2006 at 12:10:18PM -0700, Larry Wall wrote:
> > The current consensus on #perl6 is that, in postfix position only (that
> > is, with no leading whitespace), m:p/\.+ \s / lets you embed
> > arbitrary whitespace, commen
On 3/27/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 27, 2006 at 02:54:05PM -0600, Jonathan Scott Duff wrote:
> : On Mon, Mar 27, 2006 at 10:46:02PM +0200, Yuval Kogman wrote:
> : > On Mon, Mar 27, 2006 at 14:35:52 -0600, Jonathan Scott Duff wrote:
> : > > I think that if C is the new C,
On 3/27/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> The p5-to-p6 translator will turn
>
> local $x;
>
> into
>
> temp undefine $x;
Are you sure that that's not:
undefine temp $x;
It seems to me that the other way would undefine $x and then temporize it.
Luke
Can you do this? (Forgive synatical errors; I'm a bit behind on this.)
class Foo { has Code:( Str, Str --> Num ) &.somecode }
my Foo $blah .= new :somecode{ $^x cmp $^y }
my Int $x = 2;
my Num $y = Inf;
$blah.somecode( $x, $y );
Does construction of $blah fail because { $^x cmp $^y } d
On Thu, Apr 06, 2006 at 02:49:33PM -0500, Patrick R. Michaud wrote:
> On Thu, Apr 06, 2006 at 03:38:59PM -0400, John Macdonald wrote:
> > On Thu, Apr 06, 2006 at 12:10:18PM -0700, Larry Wall wrote:
> > > The current consensus on #perl6 is that, in postfix position only (that
> > > is, with no leadi
28 matches
Mail list logo
