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 name? Is it
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. This is a problem
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.pod was
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, accessing the
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
(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 not clear
On 10/10/05, Austin Hastings [EMAIL PROTECTED] wrote:
So to pass a hash that has one element requires using the chash/c
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 say
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 arg list
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 to be
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
[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
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
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 named
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, though. Maybe
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 get those
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
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
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 = 23);
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
it assigns a
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 thing: shuck the array
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
shouldn't be
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
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. Please
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 infix and
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 this operator to
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 be
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 variable participate in
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 * Unary * makes a
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
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 = ( a = 1 ) ;
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 ) ;
foo( @z ) # $a = [ 'a', 1 ]
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(
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 proposed
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 space), so
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 like to
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 parens aren't call-parens
36 matches
Mail list logo
