Hi,
TSa wrote:
> Ingo Blechschmidt wrote:
>> Exactly. I'd like to add that, under the proposal, you always know
>> what things are passed how, only by looking for a "*".
>>
>> foo $var;# always positionally, even if $var isa Pair
>> foo *$pair; # always named
>
> But where is the na
HaloO,
Ingo Blechschmidt wrote:
Exactly. I'd like to add that, under the proposal, you always know what
things are passed how, only by looking for a "*".
foo $var;# always positionally, even if $var isa Pair
foo *$pair; # always named
But where is the name? Is it 'pair'? Like in
HaloO,
Larry Wall wrote:
It still has to figure out how to reconcile the named arguments
with the positional parameters, of course, unless someone has
made sufficient representation to the compiler that all calls to
a particular short name have particular named parameters that are
guaranteed to
Hi,
Stuart Cook wrote:
> On 11/10/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
>> A rule that says
>> "splatting
>> a list coerces all pairs into named args" works just fine. The
>> corresponding rule, "acc
On 11/10/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> Luke's Tuple proposal, aka Luke's Grand Unified Object Model, is way not
> what we need for this. As far as I can see, LGUOM is an expression of
> "Haskell envy" of brobdingnagian proportion.
The reason I refrained from linking to theory.po
Ingo Blechschmidt wrote:
>Juerd wrote:
>
>
>>Ingo Blechschmidt skribis 2005-10-10 20:08 (+0200):
>>
>>
>>>Named arguments can -- under the proposal -- only ever exist in
>>>calls.
>>>
>>>
>>Which leaves us with no basic datastructure that can hold both
>>positional and named arguments.
Hi,
Juerd wrote:
> Ingo Blechschmidt skribis 2005-10-10 20:08 (+0200):
>> Named arguments can -- under the proposal -- only ever exist in
>> calls.
>
> Which leaves us with no basic datastructure that can hold both
> positional and named arguments. This is a problem because in a call,
> they can
> "J" == Juerd <[EMAIL PROTECTED]> writes:
J> Ingo Blechschmidt skribis 2005-10-10 19:59 (+0200):
>> my @args = ( (a => 1), b => 2 ); # is sugar for
>> my @args = ( (a => 1), (b => 2) );
J> Please, no. Please let the pair constructor be =>, not (=>). There is
J> really no need for
Hi,
Juerd wrote:
> Ingo Blechschmidt skribis 2005-10-10 19:59 (+0200):
>> my @args = ( (a => 1), b => 2 ); # is sugar for
>> my @args = ( (a => 1), (b => 2) );
>
> Please, no. Please let the pair constructor be =>, not (=>). There is
> really no need for this operator to consist of both
Ingo Blechschmidt skribis 2005-10-10 19:59 (+0200):
> my @args = ( (a => 1), b => 2 ); # is sugar for
> my @args = ( (a => 1), (b => 2) );
Please, no. Please let the pair constructor be =>, not (=>). There is
really no need for this operator to consist of both infix and circumfix
parts. P
Ingo Blechschmidt skribis 2005-10-10 20:08 (+0200):
> Named arguments can -- under the proposal -- only ever exist in calls.
Which leaves us with no basic datastructure that can hold both
positional and named arguments. This is a problem because in a call,
they can be combined.
An array could hol
Hi,
Juerd wrote:
> Ingo Blechschmidt skribis 2005-10-10 19:36 (+0200):
>> my @array = (42, "hi", (a => 23));
>
> It is worth pointing out that the inner parens here are merely for
> grouping: this information is lost afterwards, hence this:
>
>> foo [EMAIL PROTECTED]; # same as
>
> sho
Hi,
Dave Whipp wrote:
> Austin Hastings wrote:
>> How about "perl should DWIM"? In this case, I'm with Juerd: splat
>> should pretend that my array is a series of args.
>>
>> So if I say:
>>
>> foo [EMAIL PROTECTED];
>>
>> or if I say:
>>
>> foo([EMAIL PROTECTED]);
>>
>> I still mean the same
Hi,
Mark Reed wrote:
> On 2005-10-10 13:36, "Ingo Blechschmidt" <[EMAIL PROTECTED]> wrote:
>> Under the proposal, a Pair object doesn't have any special
>> magic
>
> Right. So under this proposal, the "key => value" syntax is
> overloaded: in some contexts it creates a Pair object, and in others
Ingo Blechschmidt skribis 2005-10-10 19:36 (+0200):
> my @array = (42, "hi", (a => 23));
It is worth pointing out that the inner parens here are merely for
grouping: this information is lost afterwards, hence this:
> foo [EMAIL PROTECTED]; # same as
shouldn't be
> foo 42, "hi", (a
On 2005-10-10 13:36, "Ingo Blechschmidt" <[EMAIL PROTECTED]> wrote:
> Under the proposal, a Pair object doesn't have any special
> magic
Right. So under this proposal, the "key => value" syntax is overloaded: in
some contexts it creates a Pair object, and in others it assigns a value to
a named
Austin Hastings wrote:
How about "perl should DWIM"? In this case, I'm with Juerd: splat should
pretend that my array is a series of args.
So if I say:
foo [EMAIL PROTECTED];
or if I say:
foo([EMAIL PROTECTED]);
I still mean the same thing: shuck the array and get those args out
here, even
Hi,
Austin Hastings wrote:
> How about "perl should DWIM"? In this case, I'm with Juerd: splat
> should pretend that my array is a series of args.
Yep.
> So if I say:
>
> foo [EMAIL PROTECTED];
>
> or if I say:
>
> foo([EMAIL PROTECTED]);
>
> I still mean the same thing: shuck the array and
Miroslav Silovic wrote:
> [EMAIL PROTECTED] wrote:
>
>> * expands its RHS and evaluate it as if it was written literally.
>>
>> I'd like @_ or @?ARGS or something like that to be a *-able array that
>> will be guaranteed to be compatible with the current sub's signature.
>>
> This sounds nice, tho
Stuart Cook wrote:
>On 10/10/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
>
>
>The overrides have nothing to do with it. That a=>1 will *always* be a
>positional, because by the time it reaches the argument list, it's a value
>(not a syntactic form). The only way to use a pair-value as a n
Interestingly, I had already written almost exactly the same thing
into my version of S06, but I've been holding off on checking it in
while I mull over Luke's theory theory. Regardless of the actual
syntax we end up with, I think everyone can assume that the compiler
will be able to determine at
[EMAIL PROTECTED] wrote:
Stuart Cook skribis 2005-10-10 22:58 (+1100):
@args = (a => 1, get_overrides());
foo([EMAIL PROTECTED]);
Not if you want that a=>1 to be a named argument.
Under the proposal, the only ways to pass a named argument are:
1) By using a literal pair in the synt
Juerd skribis 2005-10-10 15:20 (+0200):
> only pairs on the topmost level of arguments (not in any parens) are
s/not in any parens/not in any grouping parens/, to exclude .()
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/g
Miroslav Silovic skribis 2005-10-10 15:04 (+0200):
> >>Under the proposal, the only ways to pass a named argument are:
> >>1) By using a literal pair in the syntactic top-level of the arg list
> >>2) By splatting a pair, hash, or arg-list-object
> >I find this counterintuitive, and also want arrays
Stuart Cook skribis 2005-10-10 22:58 (+1100):
> > @args = (a => 1, get_overrides());
> > foo([EMAIL PROTECTED]);
> Not if you want that a=>1 to be a named argument.
> Under the proposal, the only ways to pass a named argument are:
> 1) By using a literal pair in the syntactic top-level of the a
On 10/10/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> So to pass a hash that has one element requires using the hash
> keyword?
I don't see a hash in your example, so I'm not sure what you're
referring to here.
> Specifically, if I say:
>
> @args = (a => 1, get_overrides());
>
> Then can I
(It seems you're confused about my position because I was sloppy
presenting it. My apologies; hopefully this will clear a few things
up.)
On 10/10/05, Uri Guttman <[EMAIL PROTECTED]> wrote:
> Stuart Cook <[EMAIL PROTECTED]> writes:
>
> > The think I don't like about `foo( *$bar )` is that it's no
Stuart Cook wrote:
>On 10/10/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
>
>
>>What about whitespace?
>>
>> foo (a => 42); # Note space
>>
>>Is that the first case (subcall with named arg) or the second case (sub
>>with positional pair)?
>>
>>
>
>Sub with positional pair, since the paren
> "SC" == Stuart Cook <[EMAIL PROTECTED]> writes:
SC> The think I don't like about `foo( *$bar )` is that it's not clear
SC> whether you're splatting a pair, or a hash, or an array, or a complete
SC> argument-list object. This is probably fine for quick-'n'-dirty code,
SC> but I'd lik
On 10/10/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> What about whitespace?
>
> foo (a => 42); # Note space
>
> Is that the first case (subcall with named arg) or the second case (sub
> with positional pair)?
Sub with positional pair, since the parens aren't call-parens (because
of the spac
Ingo Blechschmidt wrote:
>Hi,
>
>while fixing bugs for the imminent Pugs 6.2.10 release, we ran into
>several issues with magical pairs (pairs which unexpectedly participate
>in named binding) again. Based on Luke's "Demagicalizing pairs" thread
>[1], #perl6 refined the exact semantics [2].
>
>The
The think I don't like about `foo( *$bar )` is that it's not clear
whether you're splatting a pair, or a hash, or an array, or a complete
argument-list object. This is probably fine for quick-'n'-dirty code,
but I'd like to encourage a more explicit style:
my %hash = (a=>'b', c=>'d');
foo( *%
> "LP" == Luke Palmer <[EMAIL PROTECTED]> writes:
LP> On 10/9/05, Uri Guttman <[EMAIL PROTECTED]> wrote:
>> > "IB" == Ingo Blechschmidt <[EMAIL PROTECTED]> writes:
IB> sub foo ($a) {...}
>>
>> works for me. but what about lists and arrays?
>>
>> my @z = ( 'a', 1 ) ;
>> fo
On 10/9/05, Uri Guttman <[EMAIL PROTECTED]> wrote:
> > "IB" == Ingo Blechschmidt <[EMAIL PROTECTED]> writes:
> IB> sub foo ($a) {...}
>
> works for me. but what about lists and arrays?
>
> my @z = ( 'a', 1 ) ;
> foo( @z ) # $a = [ 'a', 1 ] ??
Yep.
> my @z
On Sun, Oct 09, 2005 at 20:22:59 +0200, Ingo Blechschmidt wrote:
> Opinions?
Yes!
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: *shu*rik*en*sh*u*rik*en*s*hur*i*ke*n*: neeyah
pgpPtAVtx26AP.pgp
Description: PGP signature
Hi,
Uri Guttman wrote:
>> "IB" == Ingo Blechschmidt <[EMAIL PROTECTED]> writes:
> IB> * "(key => $value)" (with the parens) is always a positionally
> passed
> IB> Pair object. "key => $value" (without the parens) is a named
> IB> parameter:
>
> IB> sub foo ($a) {...}
>
>
> "IB" == Ingo Blechschmidt <[EMAIL PROTECTED]> writes:
IB> * "(key => $value)" (with the parens) is always a positionally passed
IB> Pair object. "key => $value" (without the parens) is a named
IB> parameter:
IB> sub foo ($a) {...}
IB> * Unary "*" makes a normal pair va
37 matches
Mail list logo
