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
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 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
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 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 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 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
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 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
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
"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
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
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
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
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/
> +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: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
===
> "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
28 matches
Mail list logo
