Jonathan Scott Duff wrote:
> On Thu, Dec 12, 2002 at 09:43:26AM -0600, Adam D. Lopresto wrote:
>
> > So basically we can leave off the parentheses in the usual cases,
> > but they're still required when you're doing something unusual or
> > that would otherwise be hard to read.
>
> Which is simp
One possibility for R-to-L pipelines that would also solve the
namespace issues associated with reserving lots of keywords like "map"
and "grep" and "part" would be to have a quite literal inverse-C<.>
grammar. So instead of saying
$a.foo(args)
you could _always_ say an equivalent
fo
On Thu, Dec 12, 2002 at 09:43:26AM -0600, Adam D. Lopresto wrote:
> So basically we can leave off the parentheses in the usual
> cases, but they're still required when you're doing something unusual
> or that would otherwise be hard to read.
Which is simpler? "You don't need parentheses except in
> It seems to me that the simplest disambiguating rule is to require the
> parentheses on methods.
The way I see it, any sort of matching of what [multi-]?method is to be called,
is automatically doomed to failure. But I don't think that means we need to
require parentheses, except to override th
On Tue, 10 Dec 2002 13:02:18 -0800, Brent Dax wrote:
> Peter Haworth:
> # @b = @a.grep { /\S/ }, $c;
> #
> # how does the compiler know whether $c is an argument to grep,
> # or another element to be assigned to @b?
>
> The same way it does when it sees a normal sub?
>
> I know, late binding
Michael Lazzaro asked:
> foo $a, $b, $c, $d; # how many args?
Damian Conway wrote:
> Yep. Can't be known unless predeclared and hence compile-time discernible.
> And methods can't be discerned in the presence of run-time dispatch.
Is that not the purpose of an interface? That is, to specify at
Simon Cozens <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
>> About this point was when my brain when "a ha!". But I'm not yet
>> convinced that generating all possible parses is (a) of sane time
>> complexity, and (b) a little *too* DWIM for its own good.
>
> As
> Date: Thu, 12 Dec 2002 02:19:18 -0500
> From: Dan Sugalski <[EMAIL PROTECTED]>
>
> Since that may be either:
>
>$foo = bar($x, $y), foo()
>
> in which case it's in scalar context, or
>
>$foo = bar($x, $y, foo())
>
> in which case it's in list context (sort of)
>
> The fun thing is that
At 3:24 AM + 12/12/02, Simon Cozens wrote:
[EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
> Can we dictate that parentheses are optional in this case, and demand
parentheses in all others?
You see, the problem is that if we don't know what method we're going
to call until way after we'
On Wed, Dec 11, 2002 at 07:08:58PM -0800, Brent Dax wrote:
> But when you know the type beforehand, there shouldn't *be* any
> ambiguity. You can see the methods in that class, and you know how many
> arguments the biggest implementation of a multimethod[1] takes. Just
> assume that that's the on
> As I said, I wasn't sure whether or not I was being serious at this point.
>
> > > > method bar($x, $y) {
> > > > method bar($z) { # note 1
> > > Oh, bringing in multimethods Just Isn't Fair.
> >
> > Those are multimethods? Migod, I feel like a person who's just
> > discovered for t
[EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
> About this point was when my brain when "a ha!". But I'm not yet
> convinced that generating all possible parses is (a) of sane time
> complexity, and (b) a little *too* DWIM for its own good.
As I said, I wasn't sure whether or not I was being
Simon Cozens wrote:
> [EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
> > That works, with one big proviso. You have to have predeclared all
> > possible methods in the class to which the object belongs, AND each
> > method in that class (and all defined subclasses) has to have a unique
> > sign
Uri Guttman:
# BD> Fine. In Perl 5 we have a restriction on when you can
# and can't use
# BD> parens on a subroutine--you can omit them when the sub
# is predeclared,
# BD> and Perl will assume that no magic is going on. I see
# nothing wrong
# BD> with this rule.
#
# but you are con
[EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
> That works, with one big proviso. You have to have predeclared all
> possible methods in the class to which the object belongs, AND each
> method in that class (and all defined subclasses) has to have a unique
> signature.
No! No, no, no! You're
> [EMAIL PROTECTED] (Damian Conway) writes:
> > But in Perl 6, the consistency between a method's parameter list and its
> > argument list *is* checked at run-time, so passing the wrong number of
> > arguments is (quite literally) fatal.
> But wait! If we can check how many parameters to pass, we k
> "BD" == Brent Dax <[EMAIL PROTECTED]> writes:
BD> Fine. In Perl 5 we have a restriction on when you can and can't use
BD> parens on a subroutine--you can omit them when the sub is predeclared,
BD> and Perl will assume that no magic is going on. I see nothing wrong
BD> with this rul
[EMAIL PROTECTED] (Damian Conway) writes:
> But in Perl 6, the consistency between a method's parameter list and its
> argument list *is* checked at run-time, so passing the wrong number of
> arguments is (quite literally) fatal.
But wait! If we can check how many parameters to pass, we know how
m
Simon Cozens:
# Are you taking full account of what sort of magic may be
# performed between the two statements? :)
#
# Urgh:
# my Foo $foo;
# my Bar $bar;
# $foo := $bar; # Compile-time error?
Eww, gross.
# Also, Foo might change its nature, be replaced, import new
# m
Simon Cozens wrote:
I was explaining why I think we ought to keep the parens. And that is
because, without them, we can't tell how many arguments to pass to
the method.
Not if it is specified that a block comes after the final
argument.
The only way that this could be specified is with a sig
[EMAIL PROTECTED] (Brent Dax) writes:
> # my Foo $foo;
> #
> # # and later in the same lexical scope...
> #
> # $foo.bar();
> Your point being...? Shouldn't it only dispatch to methods defined in
> Foo?
Are you taking full account of what sort of magic may be performed between
the
[EMAIL PROTECTED] (Iain 'Spoon' Truskett) writes:
> So why does Ruby have so little trouble with it?
Because the Ruby designer(s) don't have fifteen years of Perl experience
muddling up their heads. :)
But seriously, Ruby does something a little tricky here that Perl 6
should probably *not* foll
Damian Conway:
# that determine which method is called. Even if you write:
#
# my Foo $foo;
#
# # and later in the same lexical scope...
#
# $foo.bar();
#
# there's no way at compile time of knowing what class of
# object $foo contains. It could be a Foo object, or it could
[EMAIL PROTECTED] (Damian Conway) writes:
> You underestimate your ability to communicate, Simon. I understood
> exactly what you wanted: pass a closure to a method without needing
> to wrap the closure in parens.
Fair enough.
> I was explaining why I think we ought to keep the parens. And that
* Damian Conway ([EMAIL PROTECTED]) [12 Dec 2002 10:32]:
[...]
> You underestimate your ability to communicate, Simon. I understood
> exactly what you wanted: pass a closure to a method without needing to
> wrap the closure in parens.
Simon appears to want to have closures as params just like Rub
Simon Cozens wrote:
*Why* do methods need their parens?
Because calls to them are not resolved until run-time and because methods
can be overloaded by signature, so we can't tell at parse time what the
parameter list of the called method will be (i.e. where it will end),
so we can't determine h
Michael Lazzaro asked:
All subroutines with multiple signatures would have this problem, right,
even normal non-method subs?
foo $a, $b, $c, $d; # how many args?
Yep. Can't be known unless predeclared and hence compile-time discernible.
And methods can't be discerned in the presence of r
At 10:41 AM -0800 12/11/02, Michael Lazzaro wrote:
How much overhead do we expect (runtime) multimethods to have? I
would guess it to be nontrivial, e.g. substantially worse than
normal methods...
I'd expect a non-trivial overhead to start, declining with time, only
paid when calling methods
On Tuesday, December 10, 2002, at 02:50 PM, Damian Conway wrote:
Simon Cozens asked:
*Why* do methods need their parens?
*All* of them might be valid interpretations, and *none* of them might
be known to be valid (or even knowable) at the point where the code is
parsed. Throw multimethods i
On Wed 11 Dec, Simon Cozens quoted:
> No proper program contains an indication which as an operator-applied
> occurrence identifies an operator-defining occurrence which as an
> indication- applied occurrence identifies an indication-defining occurrence
> different from the one identified by the g
[EMAIL PROTECTED] (Damian Conway) writes:
> > *Why* do methods need their parens?
>
> Because calls to them are not resolved until run-time and because methods
> can be overloaded by signature, so we can't tell at parse time what the
> parameter list of the called method will be (i.e. where it wil
Ken Fox <[EMAIL PROTECTED]> writes:
> Damian Conway wrote:
>> For that reason, even if we can solve this puzzle, it might be far kinder
>> just to enforce parens.
>
> I might be weird, but when I use parens to clarify code in Perl, I
> like to use the Lisp convention:
>
>(method $object args)
On Tue, Dec 10, 2002 at 01:17:22PM -0800, Brent Dax wrote:
> Jonathan Scott Duff:
> # > Where we can see *at runtime* that $quux is too many
> # arguments, we can
> # > just append it to the end of bar()'s return value. (This
> # would only
> # > happen when there were no parentheses.)
> #
>
Damian Conway wrote:
For that reason, even if we can solve this puzzle, it might be far kinder
just to enforce parens.
I might be weird, but when I use parens to clarify code in Perl, I
like to use the Lisp convention:
(method $object args)
Hopefully that will still work even if Perl 6 requi
Simon Cozens asked:
*Why* do methods need their parens?
Because calls to them are not resolved until run-time and because methods
can be overloaded by signature, so we can't tell at parse time what the
parameter list of the called method will be (i.e. where it will end),
so we can't determine
Jonathan Scott Duff:
# > Where we can see *at runtime* that $quux is too many
# arguments, we can
# > just append it to the end of bar()'s return value. (This
# would only
# > happen when there were no parentheses.)
#
# Seems to me that you just gave a really good argument for
# requiring th
On Tue, Dec 10, 2002 at 01:02:18PM -0800, Brent Dax wrote:
> Peter Haworth:
> # @b = @a.grep { /\S/ }, $c;
> #
> # how does the compiler know whether $c is an argument to grep,
> # or another element to be assigned to @b?
>
> The same way it does when it sees a normal sub?
>
> I know, late bi
Peter Haworth:
# @b = @a.grep { /\S/ }, $c;
#
# how does the compiler know whether $c is an argument to grep,
# or another element to be assigned to @b?
The same way it does when it sees a normal sub?
I know, late binding and all that. But when you think about it, a lot
can be done to simula
On 10 Dec 2002 17:25:34 +, Simon Cozens wrote:
> [EMAIL PROTECTED] (Peter Haworth) writes:
> > Fair enough; that simplifies things somewhat. However, you can't tell
> > how many arguments they take. How do you parse this without the
> > programmer specifying a great deal more than they're used
[EMAIL PROTECTED] (Peter Haworth) writes:
> Fair enough; that simplifies things somewhat. However, you can't tell how
> many arguments they take. How do you parse this without the programmer
> specifying a great deal more than they're used to in Perl 5?
>
> $foo.bar $baz,$qux
I see no block her
On 10 Dec 2002 15:34:11 +, Simon Cozens wrote:
> [EMAIL PROTECTED] (Peter Haworth) writes:
> > To know whether the method takes a block, you need to know how it's been
> > declared. In other words, the type of @a needs to be known to find
> > grep's declaration.
>
> Well, that's what always hap
[EMAIL PROTECTED] (Peter Haworth) writes:
> To know whether the method takes a block, you need to know how it's been
> declared. In other words, the type of @a needs to be known to find grep's
> declaration.
Well, that's what always happens on a method call.
> In turn, grep must specify its retur
On 10 Dec 2002 11:41:23 +, Simon Cozens wrote:
> [EMAIL PROTECTED] (Damian Conway) writes:
> > I don't think the method-call syntax allows it. I think methods
> > need their parens. So we need:
> >
> > (@foo, @bar) := @a
> > . grep( { $_ > 0} )
> > . sort( { $^b <=> $^b } )
[EMAIL PROTECTED] (Damian Conway) writes:
> I don't think the method-call syntax allows it. I think methods
> need their parens. So we need:
>
> (@foo, @bar) := @a
> . grep( { $_ > 0} )
> . sort( { $^b <=> $^b } )
> . part( [/foo/, /bar/] );
*Why* do methods need their
Michael Lazzaro asked:
(@foo, @bar) := @a
. grep { $_ > 0}
. sort { $^b <=> $^b }
. part [/foo/, /bar/];
Hmm. Does operator precedence allow that?
I don't think the method-call syntax allows it. I think methods
need their parens. So we need:
(@foo, @bar) := @a
. grep(
Adam D. Lopresto wrote:
Looks to me like with a few appropriate methods, you have left-to-right
ordering for free.
(@foo, @bar) := @a
. grep { $_ > 0}
. sort { $^b <=> $^b }
. part [/foo/, /bar/];
Yes indeed.
Of course, that means that grep and sort and part are all methods of
Dave Whipp wrote:
I like the intent, but I'm not sure about the syntax -- nor the
statement about precidence: seems to me that the pipe operator
needs a very low precidence, not very high.
An existing convention for low precidence versions of operators
is to use an alphabetic name (e.g. || vs
> From: "Me" <[EMAIL PROTECTED]>
> Date: Mon, 9 Dec 2002 17:12:13 -0600
>
> First, I don't think it's necessary to allow
> a variable (or variables) to be anywhere other
> than the front of a chain.
>
> @var = [var|code] >> code >> code;
Agreed.
> Second, it would be nice to allow a pipeline
> suggest using >> instead of -> for now,
> as a placeholder.
I like it as the real thing too. It stands
out better in a line, among other advantages.
>@source >> @out;# 'map' or 'assignment'-like
>@source >> grep { /foo/ } >> @out; # object-method-like
Yes, several
On Monday, December 9, 2002, at 08:14 AM, Adam D. Lopresto wrote:
Looks to me like with a few appropriate methods, you have left-to-right
ordering for free.
(@foo, @bar) := @a
. grep { $_ > 0}
. sort { $^b <=> $^b }
. part [/foo/, /bar/];
Hmm. Does operator precedence allow that?
In a message dated Mon, 9 Dec 2002, Adam D. Lopresto writes:
> Looks to me like with a few appropriate methods, you have left-to-right
> ordering for free.
>
> (@foo, @bar) := @a
> . grep { $_ > 0}
> . sort { $^b <=> $^b }
> . part [/foo/, /bar/];
Yes, exactly.
> Of course, that mean
On Sun, Dec 08, 2002 at 09:35:16PM -0800, Dave Whipp wrote:
> is to use an alphabetic name (e.g. || vs or). perhaps the we
> could name this operator C: its vaguely remenicent of the
>
>@out = @in
>pp map { foo }
>pp grep { bar }
>pp sort { $^a <=> $^b }
I like the id
Michael Lazzaro wrote:
> Of course, we *could* define piping such that the C is not
> necessary:
>
>@source >> /foo/ >> @out;
>
> ... by saying that a regex or closure in a pipe DWYM.
I think I'm against that because it makes it hard for somebody who sees
that in code for the first time to
On Monday, December 9, 2002, at 10:37 AM, Michael Lazzaro wrote:
@source >> grep { /foo/ } >> @out;# [5] pure L-to-R
Of course, we *could* define piping such that the C is not
necessary:
@source >> /foo/ >> @out;
... by saying that a regex or closure in a pipe DWYM. Similar to
Looks to me like with a few appropriate methods, you have left-to-right
ordering for free.
(@foo, @bar) := @a
. grep { $_ > 0}
. sort { $^b <=> $^b }
. part [/foo/, /bar/];
Of course, that means that grep and sort and part are all methods of the Array
class, so the standard way to
On Monday, December 9, 2002, at 01:19 AM, Me wrote:
So, I guess I'm suggesting a binary C<->> that
really is a left-to-right flow/assignment op
so that:
@data
-> grep { $_ > 0 }
-> sort { $^b <=> $^a }
-> part [/foo/, /bar/]
-> @foo, @bar;
does what you'd expect.
I like thi
Stéphane Payrard wrote:
I would like perl6 to support left-to-right part/sort/grep pipelines.
Left to right syntax is generally good because it facilitates the flow
of reading.
[cut]
Tentative syntax:
... is an left-associative operator that has the same precedence as .
[cut]
example:
@dat
On (09/12/02 06:00), Stéphane Payrard wrote:
> Date: Mon, 9 Dec 2002 06:00:40 +0100
> From: Stéphane Payrard <[EMAIL PROTECTED]>
> To: Damian Conway <[EMAIL PROTECTED]>
> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Subject: right-to-left pipelines
>
>
> I would like perl6 to support left-to-rig
In a message dated Mon, 9 Dec 2002, Stéphane Payrard writes:
>
>
> [snipped]
>
> > so it's easy to build up more complex right-to-left pipelines, like:
> >
> > (@foo, @bar) :=
> > part [/foo/, /bar/],
> > sort { $^b <=> $^a }
> > grep
Luke Palmer writes:
> > Date: Mon, 9 Dec 2002 06:00:40 +0100
> > From: Stéphane Payrard <[EMAIL PROTECTED]>
>
> > Damian:
> > > so it's easy to build up more complex right-to-left pipelines, like:
> > >
> > > (@foo, @bar) :=
> > > part [/foo/, /bar/],
> > > so
> Date: Mon, 9 Dec 2002 06:00:40 +0100
> From: =?iso-8859-1?Q?St=E9phane?= Payrard <[EMAIL PROTECTED]>
> Damian:
> > so it's easy to build up more complex right-to-left pipelines, like:
> >
> > (@foo, @bar) :=
> > part [/foo/, /bar/],
> > sort { $^b <=> $^a }
61 matches
Mail list logo
