HaloO,
Luke Palmer wrote:
The whole point was to deautomatize it! However, here's an
interesting solution: pairs are scanned for *syntactically* *on the
top level* of a function call (allowing named() or however we spell it
as a fallback when we want to be dynamic). However, :foo(bar) and foo
On Thu, Aug 25, 2005 at 20:23:55 +1000, Stuart Cook wrote:
> Here's a suggestion:
> Within argument lists, both of them are special syntactic forms for
> named arguments:
>
> foo(a => 'b', :c); # both named args
> my $pair = :a;
> foo($pair); # not a named-arg call
> ...or else find new
Here's a suggestion:
Outside of argument lists, both a=>'b' and :a('b') (and friends) are
equivalent, and denote an ordinary pair value.
Within argument lists, both of them are special syntactic forms for
named arguments:
foo(a => 'b', :c); # both named args
If you want to pass pair values i
On 8/24/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Larry wrote:
>
> > Plus I still think it's a really bad idea to allow intermixing of
> > positionals and named. We could allow named at the beginning or end
> > but still keep a constraint that all positionals must occur together
> > in one z
On Wed, Aug 24, 2005 at 10:12:39AM -0700, Chip Salzenberg wrote:
> On Wed, Aug 24, 2005 at 08:38:39AM -0400, John Macdonald wrote:
> > When calling a function, I would like to be able to have a
> > mixture of named and positional arguments. The named argument
> > acts as a tab into the argument lis
I've been trying to thing about how to make this read right without too
much line noise. I think Lukes keyword approach ("named") is on the
right track.
If we want named params at both start and end, then its bound to be a
bit confusing. But perhaps we can say that they're always at the end --
On Wed, Aug 24, 2005 at 08:38:39AM -0400, John Macdonald wrote:
> When calling a function, I would like to be able to have a
> mixture of named and positional arguments. The named argument
> acts as a tab into the argument list and subsequent unnamed
> arguments continue on.
I see a main point of
On Wed, 24 Aug 2005, Damian Conway wrote:
> Larry wrote:
>
> > Plus I still think it's a really bad idea to allow intermixing of
> > positionals and named. We could allow named at the beginning or end
> > but still keep a constraint that all positionals must occur together
> > in one zone.
>
> If
I don't think this example reads very clearly. Visually you have to parse
until you see the next => and then back track one word to figure out the key.
> move( from=> $x, $y, delta=> $up, $right );
Personally I'd write that as either
move(from => [$x, $y], delta => [$up, $right]);
OR as
On Wed, Aug 24, 2005 at 04:27:03PM +1000, Damian Conway wrote:
> Larry wrote:
>
> >Plus I still think it's a really bad idea to allow intermixing of
> >positionals and named. We could allow named at the beginning or end
> >but still keep a constraint that all positionals must occur together
> >in
Larry mused:
On the other hand, I'm not all that attached to colon itself.
I *am*!!!
If, as proposed elsewhere, we get rid of the %Foo:: notation in favor of
some Foo<> variant, then trailing :: becomes available (ignoring ??/::
for the moment), and
new Dog:: tail => 'long'
almost mak
Larry wrote:
Plus I still think it's a really bad idea to allow intermixing of
positionals and named. We could allow named at the beginning or end
but still keep a constraint that all positionals must occur together
in one zone.
If losing the magic from =>'d pairs isn't buying us named args w
On Mon, Aug 22, 2005 at 09:54:36 -0700, Larry Wall wrote:
> That's not a problem as long as you keep your positionals together.
Oh, I assumed the it's
/(* *)|(* *)/,
not
/* * */
> : If there is some really odd code signature which takes in a mess, I
> : may want to intermix pos
On Mon, Aug 22, 2005 at 10:51:25AM -0600, Eric wrote:
: Just my two cents then back to lurking. The idea of having named parameters
: with different names than the variables ++. Otherwise your public API is
: dependent on private variables which is a Bad Thing and the only thing that
: realy bug
On Fri, Aug 19, 2005 at 06:42:04PM +0300, Yuval Kogman wrote:
: On Fri, Aug 19, 2005 at 08:27:38 -0700, Larry Wall wrote:
:
: > Plus I still think it's a really bad idea to allow intermixing of
: > positionals and named. We could allow named at the beginning or end
: > but still keep a constraint
Just my two cents then back to lurking. The idea of having named parameters
with different names than the variables ++. Otherwise your public API is
dependent on private variables which is a Bad Thing and the only thing that
realy bugged me about current named parameters in P6.
BTW why is it th
On Fri, Aug 19, 2005 at 06:42:04PM +0300, Yuval Kogman wrote:
> If there is some really odd code signature which takes in a mess, I
> may want to intermix positionals and named's in order to increase
> readability.
AFAIR, named parameter syntax will work for positionals as well[*].
So even if you
On Fri, Aug 19, 2005 at 08:39:24AM -0700, Larry Wall wrote:
: Actually, that's an argument that : is in a different class than the regex
: quantifiers, and required named should be
:
: sub bar (+$:key)
:
: as I speculated earlier. Maybe we just force that to bind to $key instead
: of $:key.
On Fri, Aug 19, 2005 at 06:30:41PM +0300, Yuval Kogman wrote:
: On Fri, Aug 19, 2005 at 10:31:34 +, Luke Palmer wrote:
:
: In short, "me too".
:
: Now some comments:
:
: > foo($a, $b, $c)
: >
: > You *know* that you're passing three positionals.
:
: This is very very important for leas
On Fri, Aug 19, 2005 at 08:27:38 -0700, Larry Wall wrote:
> Plus I still think it's a really bad idea to allow intermixing of
> positionals and named. We could allow named at the beginning or end
> but still keep a constraint that all positionals must occur together
> in one zone.
This is someth
Hmm, if we take + away from named, it can become the "required" marker,
so
sub foo ($a,$b,?$c)
is really short for
sub foo (+$a,+$b,?$c)
and required named parameters then become
sub bar (+:$key)
And, of course, that means that
sub baz (+?$key)
is a required optional paramet
On Fri, Aug 19, 2005 at 10:31:34 +, Luke Palmer wrote:
In short, "me too".
Now some comments:
> foo($a, $b, $c)
>
> You *know* that you're passing three positionals.
This is very very important for least surprise and all that.
> It's much less work for the runtime. You don't have to
On Fri, Aug 19, 2005 at 10:31:34AM +, Luke Palmer wrote:
: I propose that we move the magic out of the Pair type, and into a
: syntactic form.
That's kinda the direction we were already moving with the *%foo proposal,
so I think I like it, but I'll need to steep my brain in a bit more caffeine
We've seen many problems come up with the current special treatment of
pairs. Here's what I can think of:
* Pairs are restricted to a particular position in the argument list, which
leads to confusion (why isn't this being passed named?) and poor
end-weight in something like this:
f
24 matches
Mail list logo
