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
On Tuesday, December 10, 2002, at 02:50 PM, Damian Conway wrote:
Simon Cozens asked:
*Why* do methods need their parens?
examples snipped
*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.
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
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
* 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 Ruby.
[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
[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
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
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 the
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
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.)
#
# Seems to
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/],
sort { $^b
[regarding - as a left-to-right pipe-like operator]
'-' 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.
You seem to be forgetting:
given $foo - $_
and cousins.
--
ralph
From: Me [EMAIL PROTECTED]
Date: Mon, 9 Dec 2002 02:12:41 -0600
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
[regarding - as a left-to-right pipe-like operator]
'-' isn't (in my mind) a left-to-right
flow/assignment operator.
'-' 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
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
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
Michael Lazzaro wrote:
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.
I think I'm against that because it makes it hard for somebody who sees
that in code for the first time to look
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 Cpp: its vaguely remenicent of the
@out = @in
pp map { foo }
pp grep { bar }
pp sort { $^a = $^b }
I like the idea of
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?
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 issues
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
element to pass
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
[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 }
@data;
I would like
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
65 matches
Mail list logo
