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, potentially,
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 I said, I
[EMAIL PROTECTED] (Stephen McCamant) writes:
Simon I'm afraid I can't tell whether or not I'm being serious any
Simon more.
I don't know if this has been discussed before, but there are
completely serious parsing algorithms that work this way
Morale: If you can come up with a crazy enough
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
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 and all
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 the
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
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
foo(args)
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 simpler? You
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)
Hopefully
[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 will
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
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
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
[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 is
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] (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*
[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 two
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
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
#
[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
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 rule.
but you
[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
[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
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
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
signature.
[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
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 the first time in
Simon == Simon Cozens [EMAIL PROTECTED] writes:
Simon [EMAIL PROTECTED] (Damian Conway) writes:
Damian But in Perl 6, the consistency between a method's parameter
Damian list and its argument list *is* checked at run-time, so
Damian passing the wrong number of arguments is (quite literally)
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 one
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
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( {
[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 parens?
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] (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 return
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 happens on
[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 here.
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 to in
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
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 binding
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
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
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 { $_ 0
'-' isn't (in my mind) a left-to-right
flow/assignment operator. It's a unary
operator, synonymous with sub without
parens required around the argument list.
given $foo - $_ { ... }
given $foo sub { ... }
Are all equivalent (if sub topicalizes its
first parameter).
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-right part/sort
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 this so much
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 10:37 AM, Michael Lazzaro wrote:
@source grep { /foo/ } @out;# [5] pure L-to-R
Of course, we *could* define piping such that the Cgrep is not
necessary:
@source /foo/ @out;
... by saying that a regex or closure in a pipe DWYM. Similar to the
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 means that
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?
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
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
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
Note: this is back on-list.
From: Me [EMAIL PROTECTED]
Date: Mon, 9 Dec 2002 01:27:55 -0600
[regarding - as a left-to-right pipe-like operator]
Please do. As in, please point out on list that
'-' is already established as a left-to-right
flow/assignment operator so why not consider
54 matches
Mail list logo
