Luke Palmer wrote:
LP my $foos = 'foo' ~ any(0..9) ~ any(0..9);
Actually $foos will be a junction. You could use Cstates to get
each state out of the junction in an array.
my @foos = states $foos;
Luke's right on target (as usual :-). Just one slight niggle. I suspect
Cstates may
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
Date: Wed, 11 Dec 2002 19:15:53 +1100
From: Damian Conway [EMAIL PROTECTED]
I suspect Cstates may be a method only, so that would be either:
my @foos = states $foos:;
or:
my @foos = $foos.states;
Though, I suppose we might argue that Cstates is as fundamental to Perl
The Perl 6 Summary for the week ending 20021208
Another Monday evening. Another summary to write.
Starting, as is becoming tediously predictable, with perl6-internals.
Another JIT discussion
Toward the end of the previous week, Leopold Tötsch posted something
about the latest
[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 Tue, Dec 10, 2002 at 03:38:58PM -0800, Rich Morin wrote:
On occasion, I have found it useful to cobble up a little language
that allows me to generate a list of items, using a wild-card or some
other syntax, as:
foo[0-9][0-9] yields foo00, foo01, ...
I'm wondering whether Perl
On Mon, Dec 09, 2002 at 03:58:54PM -0700, Luke Palmer wrote:
From: Dave Storrs [EMAIL PROTECTED]
My understanding was that in Perl6, you could use pretty much anything
for a hashkey--string, number, object, whatever, and that it did not
get mashed down into a string. Did I have this
Michael Lazzaro:
# Piers wrote:
# I doggishly maintain my preference for treating stringification for
# output and stringification for debugging differently, but
# as long as
# I can specify an AS_STRING (sp?) method for a class, and
# _still_ get
# at a debugging version to print to other
At 2:28 PM -0800 12/11/02, Michael G Schwern wrote:
On Wed, Dec 11, 2002 at 02:15:40PM -0800, Michael Lazzaro wrote:
On Wednesday, December 11, 2002, at 11:16 AM, Luke Palmer wrote:
This brings up something that's been on the tip of my toungue for
awhile. In many object-oriented languages
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
Luke Palmer asked:
Can junctions have methods?
If we decide they can, yes. ;-)
How do you tell the difference between calling a junction's method and
calling a method on each of its states?
If it's a method of the class Junction (or one of its four subclasses) then it's
a method call on
This is just your friendly neighborhood curmudgeon reminding you that in
Perl 6, everything is an object. This is a concept that, as Perl
programmers, we're not familiar with.
What are the consequences of this in language design? Well, it means not
every new piece of functionality requires a
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
Dave Storrs wrote:
On Tue, Dec 10, 2002 at 10:37:10PM -0700, Luke Palmer wrote:
Why use regexen when you can just use junctions?
my $foos = 'foo' ~ any(0..9) ~ any(0..9);
At what moment does a junction actually create all of its states?
Hmm...perhaps a clearer way to say that is At what
[EMAIL PROTECTED] (Michael G Schwern) writes:
If you want a tactile grasp of the Everything is an object concept, try
some Ruby.
If you want a tactile grasp of Perl 6, try some Ruby. But I'll be saying
a lot more on that later...
A flip through the Ruby builtin methods is nice for building
[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
On 12/11/02 6:16 PM, Damian Conway wrote:
There's no need for special methods or (gods forbid) more operators.
Just:
$obj1.id == $obj2.id
That's what the universal Cid method is *for*.
I must have missed this (or forgotten it?) Any chance of it becoming .ID or
.oid or even ._id? I'm
Michael G Schwern [EMAIL PROTECTED] wrote:
This is just your friendly neighborhood curmudgeon reminding you that in
Perl 6, everything is an object
...
Instead of introducing new built-in functions they can be done as methods.
The problem with this worldview is that you end up with horrible
On Wednesday, December 11, 2002, at 02:54 PM, Dave Whipp wrote:
There's actually a fourth concept: two (different) objects represent
the same value. (Actually, its the generalization of [1] and [2]).
I think that is covered by C~~. As long as we can create
class-specific variants of smart
[EMAIL PROTECTED] (Dave Whipp) writes:
There is a difference between verbs and noun. Sometimes you don't want
to associate a verb with an object: you want to associate it with the
subject:
Verbs are almost always associated with their subject in OO languages,
so I don't see where you're coming
[EMAIL PROTECTED] (Michael Lazzaro) writes:
I think that is covered by C~~. As long as we can create
class-specific variants of smart matching, we're fine.
If we can't, case^Wgiven statements become very boring indeed.
For reference, and purely for reference, Ruby has four object comparators:
On Wednesday, December 11, 2002, at 03:27 PM, Michael G Schwern wrote:
There's lots of reasons to use an operator or built-in instead of a
method, but remember to make the consideration first. Don't go
grammar happy.
I agree 98% with your argument (especially re: grammar extensions), and
Simon Cozens [EMAIL PROTECTED] wrote
Verbs are almost always associated with their subject in OO languages,
so I don't see where you're coming from.
Actually, the important part of it was the 3rd option (the multimethod):
sometimes the association is symmetrical. I was pointing out that the
On Wed, Dec 11, 2002 at 04:56:03PM -0800, Michael Lazzaro wrote:
First, universal operators and universal methods both pollute the
useful (programmer) namespace to nearly the same extent.
Most of the methods are not universal. For example:
$foo.compress
would be in the String class,
On Wednesday, December 11, 2002, at 05:21 PM, Michael G Schwern wrote:
On Wed, Dec 11, 2002 at 04:56:03PM -0800, Michael Lazzaro wrote:
First, universal operators and universal methods both pollute the
useful (programmer) namespace to nearly the same extent.
Most of the methods are not
[EMAIL PROTECTED] (Michael Lazzaro) writes:
would be a false savings. If a method _is_ universal, especially if
it's symmetric, it might be an OK candidate for a builtin or operator.
And if it isn't universal, I can see (almost) no justification for
wasting an op on it, no matter how common
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
On Wednesday, December 11, 2002, at 05:39 PM, Simon Cozens wrote:
[EMAIL PROTECTED] (Michael Lazzaro) writes:
would be a false savings. If a method _is_ universal, especially if
it's symmetric, it might be an OK candidate for a builtin or operator.
And if it isn't universal, I can see (almost)
On Wednesday, December 11, 2002, at 06:41 PM, Michael Lazzaro wrote:
print $i; # ILLEGAL; use $STDOUT.print($i) or $i.print (?)
reverse @a; # ILLEGAL; use @a.reverse;
map {...} @a; # ILLEGAL; use @a.map({...});
sort {...} @a; #
keys %h;# ...etc...
(And yes,
[EMAIL PROTECTED] (Michael Lazzaro) writes:
Wel... yes and no. You can make the same argument for operators
upon scalars, for example, since 'scalar' is arguably no more
universal than 'array'. And we could easily use that argument to
remove *all* builtins, period:
Now you're getting
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
Rich == Rich Morin [EMAIL PROTECTED] writes:
Rich On occasion, I have found it useful to cobble up a little language
Rich that allows me to generate a list of items, using a wild-card or some
Rich other syntax, as:
Richfoo[0-9][0-9] yields foo00, foo01, ...
Rich I'm wondering whether Perl
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
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Wed, 11 Dec 2002 19:21:35 -0500
From: John Siracusa [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
On 12/11/02 6:16 PM, Damian Conway wrote:
There's no need for special
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
From: Dave Whipp [EMAIL PROTECTED]
Date: Wed, 11 Dec 2002 14:54:18 -0800
Organization: Fast-Chip inc.
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4920.2300
X-MimeOLE: Produced By Microsoft
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
At 9:43 PM -0700 12/11/02, Luke Palmer wrote:
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
X-Sent: 11 Dec 2002 23:16:30 GMT
Date: Thu, 12 Dec 2002 10:16:26 +1100
From: Damian Conway [EMAIL PROTECTED]
X-Accept-Language: en, en-us
X-SMTPD: qpsmtpd/0.20,
50 matches
Mail list logo
