Everything is an object.

3 views
Skip to first unread message

Michael G Schwern

unread,
Dec 11, 2002, 6:27:29 PM12/11/02
to perl6-l...@perl.org
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 new operator. Instead, consider
a method. Its an actual word.

Stemming the tide of new grammar and operators heads off another
problem, typos becoming meaningful. The more operators you have, the more
chance that this sort of thing:

if $num1 === $num2 {
...

will be hard to find. Was it a typo or did they really mean to do a shallow
object comparison?


Instead of introducing new built-in functions they can be done as methods.
This reduces core namespace pollution. Think of the core like a big CPAN
module. Every built-in is like an exported function. Every word used as a
built-in is one that noone else can safely use for something else in their
own code.


If you want a tactile grasp of the "Everything is an object" concept, try
some Ruby.

Many pieces of edge functionality which are useful but would have been
rejected because they don't really warrent a new built-in or operator can be
put in as methods. For example, in Ruby you can alter the default value of
a hash like so:

h = {"foo" => 42};
h.default = "wibble";

# Prints 'wibble' rather than undef.
print h["bar"];

Isn't that neat? Not important enough to warrent a new built-in, but
something nice to have in your toolbox.

How many times have you done this in perl:

print grep defined, @array;

in Ruby, its just this:

print array.compact

I find myself doing this alot:

$string =~ s/^\s+//;
$string =~ s/\s+$//;

in Ruby:

string.strip!

Ruby can add neat little features without long deliberations about the
impact on language growth and backwards compatibilty because they have the
ability to add methods to core types.

A flip through the Ruby builtin methods is nice for building up some envy. :)
http://www.rubycentral.com/book/builtins.html


Sometimes you do need to use an operator or built-in. Usually to make data
transformations flow nicely:

@foo = join "\n", map { ... } grep { ... } sort @bar;

the concept can be reversed:

@foo = @bar.sort.grep(...).map(...).join("\n");

but is that Perlish?

Or you will commonly use the operator on expressions rather than variables.

1 + 2 == 3

would suck as:

(1 + 2).eq 3


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.


In closing: Consider a method rather than a built-in or operator.
Everything is an object. Tattoo it on your forehead today.


--

Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
Do you actually think about what you are saying or is it an improvisational
game of Mad Libs that you play in your head?

Simon Cozens

unread,
Dec 11, 2002, 6:36:17 PM12/11/02
to perl6-l...@perl.org
sch...@pobox.com (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 up some envy. :)
> http://www.rubycentral.com/book/builtins.html

I vaguely object to calling them builtins, as I've objected to similar
concepts in Perl 6. They aren't *built in* to the language - you could
add another method and the parser wouldn't give a damn - they are
methods of the standard libraries that ship with Ruby. This
distinction is important, despite what Damian would have you believe.

In the same way, the specification of C-as-a-language, its syntax and
operators and the stuff that makes it look, act and feel like C, is
agnostic of the C standard library. (Even though "ANSI C" specifies
both, they are seperable.) This seperability is something I'd like
to see thought about a lot more in Perl 6.

> 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.

Yes, yes, yes. This is what I've been trying to say for a while.

--
"If that makes any sense to you, you have a big problem."
-- C. Durance, Computer Science 234

Dave Whipp

unread,
Dec 11, 2002, 7:24:04 PM12/11/02
to perl6-l...@perl.org
"Michael G Schwern" <sch...@pobox.com> 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
asymmetries suh as:

> 1 + 2 == 3
>
> would suck as:
>
> (1 + 2).eq 3

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:

"the cat sat on the mat"

is that

the_mat.sat_on(the_cat)
or
the_cat.sat_on(the_mat)
or
sat_on(the_cat, the_mat)

All of those seem to loose the preposition. Are sat_on and sat_beside
really completely independent things? Under perl's grammar: yes. Seems
to me that identifiers have a complex fusional word-structure, which is
opaque to the grammar of the language. The more structure you can
expose into the parse tree, the more powerful will be manipulations on
that tree.

Perl6 allows there different worldviews, but we need to make sure that
verbs are as entensible as nouns. Multimethods are wonderful things.
Don't add something as a method if it makes more sense as a
multi-method. Don't use an asymmetric method syntax for a
symmetric concept.

To say "everything is an object: extend by adding methods" elevates
Nouns over Verbs. And it completely ignores all the other parts of
the language. Sometimes people seem to think that the only alternative
is to add built-ins: but this really shouldn't be the case -- not in a
language as powerful as Perl6.


Dave.


Simon Cozens

unread,
Dec 11, 2002, 7:29:17 PM12/11/02
to perl6-l...@perl.org
david...@fast-chip.com (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 from.

> "the cat sat on the mat"
> is that
> the_mat.sat_on(the_cat)

Nope.

> or
> the_cat.sat_on(the_mat)

This one. If you called
$cat->sit_on($mat);
in Perl 5, who would you expect to be sitting on what?

> All of those seem to loose the preposition. Are sat_on and sat_beside
> really completely independent things?

$x.sat_beside($y);
$y.sat_beside($x);

Hey, it's just like English, but with more punctuation! And we know how
well people deal with punctuation!

> Under perl's grammar: yes.

Well, no, as I've just demonstrated.

--
It's a testament to the versatility of the human mind that we're so able
to compensate for our own incompetence.
- Darrell Furhiman

Michael Lazzaro

unread,
Dec 11, 2002, 7:56:03 PM12/11/02
to Michael G Schwern, perl6-l...@perl.org

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
it was very well explained. The 02% is this:

First, universal operators and universal methods both pollute the
useful (programmer) namespace to nearly the same extent. It's just one
pollution is alphanumeric, the other is punctuational. For example,
'.eq' and '==' are (abstractly) just multimethods upon their
invocant/arguments, tho one has a funny-charactered name. Either way,
you're defining something that everyone has to remember, and that
people can't use for their own purposes.

Second, one person's trivial feature is another person's dream come
true. C<given>, for example, or vectorops. So the object-based
argument can be used to support or crush pretty much *anything*,
depending solely on POV. Or put any feature in or out of the "builtin"
list, for that matter. It's only our opinions, we can't really justify
them except through our own experiences.

So I don't think we have an alternative to just plain arguing over each
such proposal as it arrives, which we *hope* will produce the overall
correct results as a sheer accident of demographics.

MikeL

(I don't *really* think '===' is critically important, though as an
obviously symmetric binary operation it has some minor charm. I tend
to use the concept somewhat frequently, but others don't, so it
probably doesn't pass the bar.)

Dave Whipp

unread,
Dec 11, 2002, 8:01:37 PM12/11/02
to perl6-l...@perl.org
"Simon Cozens" <si...@simon-cozens.org> 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
concept -> OO mapping is very lossy.

> > All of those seem to loose the preposition. Are sat_on and sat_beside
> > really completely independent things?

> > Under perl's grammar: yes.
> Well, no, as I've just demonstrated.

I must have missed it in your post. I saw no Perl grammar that sees the
commonality between .sit_on and .sit_beside. Perl thinks of them as two
independent methods (The programmer can choose to implement them
with some commonality). We seem happy to structure objects (using
attributes, etc.), but verbs remain flat and uninteresting: just arbitrary
names.

As a result of this lack of expressiveness in the grammar, we find ourselves
saying that if a concept doesn't fit the "everything is an object"
worldview,
then it needs to be a built-in. I'm not saying that I have an alternative:
just
explaining why we keep proposing built-ins instead of using the methods
on objects.


Dave.


Michael G Schwern

unread,
Dec 11, 2002, 8:21:10 PM12/11/02
to Michael Lazzaro, perl6-l...@perl.org
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, not Object (or whatever we're calling the
equivalent of UNIVERSAL today), and only inherited by those objects which
wish to masquerade as strings.

%hash.default

is in the Hash class.

The sameas example:

$obj.sameas $obj2

would be in the Object class and would pollute. Using Ruby as a rough
guide, there aren't many of those.
http://www.rubycentral.com/book/ref_c_object.html


--

Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One

One disease, long life. No disease, short life.

Michael Lazzaro

unread,
Dec 11, 2002, 8:34:48 PM12/11/02
to Michael G Schwern, perl6-l...@perl.org

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 universal. For example:
>
> $foo.compress
>
> would be in the String class, not Object (or whatever we're calling the

Right, I just wanted to clarify. Because deciding between, say:

$foo.sameas($bar); # universal method

$foo === $bar; # universal operator

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 it is.

(Again, though, C<$foo.id == $bar.id> is OK by me.)

MikeL

Simon Cozens

unread,
Dec 11, 2002, 8:39:08 PM12/11/02
to perl6-l...@perl.org
mlaz...@cognitivity.com (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 it is.

Bingo. And things like "purge" only apply to arrays and lists, hence...

--
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development."
(By dmeg...@aix1.uottawa.ca)

Michael Lazzaro

unread,
Dec 11, 2002, 9:41:57 PM12/11/02
to perl6-l...@perl.org
On Wednesday, December 11, 2002, at 05:39 PM, Simon Cozens wrote:
> mlaz...@cognitivity.com (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 it is.
>
> Bingo. And things like "purge" only apply to arrays and lists, hence...

Welllll... 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:

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...

in which case right-to-left pipes go away entirely, if we want them to.

But if we decide to allow _some_ array-based builtins (or even if we
just make them all methods of Array and Hash) then deciding _which_
ones to include falls under the YMMV argument -- we have to guess. So
purge or C<part> is valid to at least *consider* for inclusion.

My point was that in lang design it's possible to make a convincing but
purely philosophical argument for or against anything (postmodernism?),
and as such it will never be possible to declare hard-and-fast rules
for what should or should not be a builtin. We just have to fight it
out on a case-by-case basis.

MikeL

Michael Lazzaro

unread,
Dec 11, 2002, 9:50:12 PM12/11/02
to perl6-l...@perl.org

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, I'm aware that (1 <= N <= 5) of those are going away already.)

MikeL

Simon Cozens

unread,
Dec 11, 2002, 9:56:47 PM12/11/02
to perl6-l...@perl.org
mlaz...@cognitivity.com (Michael Lazzaro) writes:
> Welllll... 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 the idea.

--
Feed me on TOASTIES! There's no HALL for PHILOSOPHERS ON FRIDAYS.
- Henry Braun is Oxford Zippy

Piers Cawley

unread,
Dec 12, 2002, 5:53:50 AM12/12/02
to Simon Cozens, perl6-l...@perl.org
Simon Cozens <si...@simon-cozens.org> writes:

> david...@fast-chip.com (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 from.
>
>> "the cat sat on the mat"
>> is that
>> the_mat.sat_on(the_cat)
>
> Nope.
>
>> or
>> the_cat.sat_on(the_mat)
>
> This one. If you called
> $cat->sit_on($mat);
> in Perl 5, who would you expect to be sitting on what?

C<< $cat.sat_on($the_mat) >> is surely a predicate, returning true or false
depending on whether the cat is on the mat or not. But unless I can
write it as C<< $cat.sat_on?($the_mat) >> then I'd be very cross with
anyone who didn't call the method C<< is_sat_on >>.

--
Piers

"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?

Austin Hastings

unread,
Dec 12, 2002, 11:50:53 AM12/12/02
to Dave Whipp, perl6-l...@perl.org

--- Dave Whipp <david...@fast-chip.com> wrote:

> We seem happy to structure objects (using
> attributes, etc.), but verbs remain flat and uninteresting: just
> arbitrary names.
>
> As a result of this lack of expressiveness in the grammar, we find
> ourselves saying that if a concept doesn't fit the "everything
> is an object" worldview, then it needs to be a built-in.

This is a good point.

I think that to a certain extent, this can be handled with properties.
It's just that we haven't gotten used to thinking this way, yet.

Already we've borrowed the Spanish ser/estar model (is/but) to
differentiate between permanent and transient characteristics.
(Then I unpacked my adjectives... He was a hairy bear. He was a scary
bear...)

Prepositions are kind-of-there with properties, and with the
specially-named-blocks (first, last, etc.) for order-prepositions.

The cat sat on the TV.
The cat sat near the TV.
The cat sat beside the TV.
The @#$@#$ cat sat in front of the TV.

Currently, that's going to be

$cat.sit($TV);
$cat.sit($TV but 'near');
$cat.sit($TV but 'beside');
and:
$cat = $cat but '@#$@#$';
$cat.sit($TV but 'in front of');

Some adverbial work has been put into blocks-as-arguments, as with sort
(sort these *ascendingly*). But in general, adverbs aren't obviously
there, yet.

(Lolly Lolly Lolly, get your adverbs here!
Quickly quickly quickly, get your adverbs here!
Slowly surely really, learn your adverbs here!)

Another use of adverbs is as intensifiers.

$x = 'useless' but 'necessary';
$y = but very 'necessary'; # How do you say this, really?
$z = but very very 'necessary';

If there were some (automatic) mechanism that ordered objects according
to their necessity (like the new part() built-in!!), the intensifiers
should affect the order:

sub do_stuff(@honeydew)
{
my (@a, @b, @c) = part
{
when necessary ;
default ;
when optional is reversed; #? syntax
} @honeydew;

do_list(@a);
do_list(@b);
do_list(@c);
}

Ideally, the @a list and the @c list should honor the intensifiers and
be ordered such that the very-very necessary come before the very
necessary come before the necessary come before the not-very ...

Likewise, adverbs as verb modifiers provides a way to avoid having
several functions with similar behaviors.

C<sort> does this with a block: cool. But adverbs like securely,
surely, quickly, and dynamically don't necessarily translate well to
blocks, and they don't set context.

Perhaps we need adverbial scope?

# From LWP
# Pass request to the user agent and get a response back
my $res = $ua->request($req) securely;

... somewhere in the bowels of LWP6? ...
my $pcl = "http";
when securely { $pcl = "https" };

Thus anyone could "suggest" behavior, and it may-or-may-not be acted
upon in the subsequent code. But the overall activity (the verb, which
is to say the subs/methods) gets done, regardless.

Ideas?

=Austin

Michael Lazzaro

unread,
Dec 12, 2002, 1:11:00 PM12/12/02
to Simon Cozens, perl6-l...@perl.org
On Wednesday, December 11, 2002, at 06:56 PM, Simon Cozens wrote:
> mlaz...@cognitivity.com (Michael Lazzaro) writes:
>> Welllll... 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 the idea.

Yes. But Java sucks. Me no like make Perl like Java.

I would still like to be able to do things in Perl6 like:

@out = sort map {...} grep { ... } @in; # [1]

Even though that technically means having sort, map, grep as builtins.

We can make that

@out = @in.grep({...}).map({...}).sort; # [2]

if we want to grind our OO axe, but I find that syntax disappointing.
I like that the idea is important enough in Perl to have it's own
grammar, but I realize the problem of namespace pollution involved in
having a bunch of builtins called grep, map, whatever.

The only encompassing solution would seem to be to find a grammar rule
by which map,grep,etc are unambiguously methods of Array, but can still
be called in a fashion similar to [1]. That would, I suspect, satisfy
everyone.

MikeL

Luke Palmer

unread,
Dec 12, 2002, 3:42:48 PM12/12/02
to mlaz...@cognitivity.com, si...@simon-cozens.org, perl6-l...@perl.org
> Date: Thu, 12 Dec 2002 10:11:00 -0800
> From: Michael Lazzaro <mlaz...@cognitivity.com>

>
> On Wednesday, December 11, 2002, at 06:56 PM, Simon Cozens wrote:
> > mlaz...@cognitivity.com (Michael Lazzaro) writes:
> >> Welllll... 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 the idea.
>
> Yes. But Java sucks. Me no like make Perl like Java.
>
> I would still like to be able to do things in Perl6 like:
>
> @out = sort map {...} grep { ... } @in; # [1]

Or, better yet:

@out = sort map grep @in: { ... }: { ... }:;

Hi Mister Maintainence Programmer :-P

Luke

Simon Cozens

unread,
Dec 12, 2002, 5:23:04 PM12/12/02
to perl6-l...@perl.org
mlaz...@cognitivity.com (Michael Lazzaro) writes:
> The only encompassing solution would seem to be to find a grammar rule
> by which map,grep,etc are unambiguously methods of Array, but can
> still be called in a fashion similar to [1]. That would, I suspect,
> satisfy everyone.

Right. And that's what my clever-parsing-of-blocks idea was working towards:
making the syntax palatable for the most common forms.

--
ADVERSITY:
That Which Does Not Kill Me Postpones the Inevitable

http://www.despair.com

Smylers

unread,
Dec 12, 2002, 5:40:20 PM12/12/02
to perl6-l...@perl.org
Michael Lazzaro wrote:

> I would still like to be able to do things in Perl6 like:
>
> @out = sort map {...} grep { ... } @in; # [1]
>

> The only encompassing solution would seem to be to find a grammar rule
> by which map,grep,etc are unambiguously methods of Array, but can
> still be called in a fashion similar to [1]. That would, I suspect,
> satisfy everyone.

What if the thing being C<sort>ed (or whatever) is not an array but a
list?

@out = sort $scalar, @array, result_of_calling_function($param);

Would the list have to be stored in an array before it could be sorted?

That doesn't sound very nice ...

@out = [$scalar, @array, result_of_calling_function($param)].sort;

I think I'm in favour of things that operate on an arbitrary lists
remaining functions rather than becoming methods.

Smylers

Michael G Schwern

unread,
Dec 12, 2002, 7:17:44 PM12/12/02
to Smylers, perl6-l...@perl.org
On Thu, Dec 12, 2002 at 10:40:20PM -0000, Smylers wrote:
> What if the thing being C<sort>ed (or whatever) is not an array but a
> list?
>
> @out = sort $scalar, @array, result_of_calling_function($param);
>
> Would the list have to be stored in an array before it could be sorted?

I would hope Perl would be smart enough to allow this:

@out = ($scalar, @array, result_of_calling_function($param)).sort

which Ruby does:

$ ruby -wle 'out = ["foo", "bar"].sort; print out.join " "'
bar foo

but as I said, I find the Lisp flow style worth keeping.

@out = join "\n", map {...} grep {...} sort {...} @foo


--

Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One

Pancakes is the better part of valor.
http://www.goats.com/archive/971202.html

Michael Lazzaro

unread,
Dec 12, 2002, 7:24:19 PM12/12/02
to Smylers, perl6-l...@perl.org
On Thursday, December 12, 2002, at 02:40 PM, Smylers wrote:
> What if the thing being C<sort>ed (or whatever) is not an array but a
> list?
>
> @out = sort $scalar, @array, result_of_calling_function($param);
>
> Would the list have to be stored in an array before it could be sorted?

I hope and expect that there is sufficient magic to treat a list as an
Array wherever necessary, such that Array method calls should be
allowed on any literal or C<return>ed list.

( $scalar, @array, foo() ).sort {...}; # [1]

my @a = ( $scalar, @array, foo() ); # [2]
@a.sort {...};

If we kept the current map syntax, the same should be true:

sort {...} $scalar, @array, foo(); # [1]

my @a = ( $scalar, @array, foo() ); # [2]
sort {...} @a;

Or if we can come up with a reverse-dot syntax that treats C<sort> as a
method of Array, and not a reserved keyword:

sort { ... } <- $scalar, @array, foo(); # [1]

my @a = ( $scalar, @array, foo() ); # [2]
sort {...} <- @a;

In each case, [1] should be marginally more efficient than [2], because
it's doing less.

Same magic for hashes, too. And maybe even for references upon
arrays/hashes:

(1,2,3,4,5).reverse; # returns (5,4,3,2,1)
[1,2,3,4,5].reverse; # returns [5,4,3,2,1]

But note:

@a.reverse;
@a .= reverse; # these two might mean different things?

my @a = (1,2,3,4,5);
@a.reverse; # OK

my $a = [1,2,3,4,5];
$a.reverse; # but this might be problematic

That last line would be OK only if the C<Ref> type either didn't have
any methods of it's own (unlikely), or if C<Ref> knew to look in the
methods of the referred-to obj if the method was not part of C<Ref>
itself.

MikeL

Larry Wall

unread,
Dec 12, 2002, 8:26:15 PM12/12/02
to perl6-l...@perl.org
On Thu, Dec 12, 2002 at 04:17:44PM -0800, Michael G Schwern wrote:

: On Thu, Dec 12, 2002 at 10:40:20PM -0000, Smylers wrote:
: > What if the thing being C<sort>ed (or whatever) is not an array but a
: > list?
: >
: > @out = sort $scalar, @array, result_of_calling_function($param);
: >
: > Would the list have to be stored in an array before it could be sorted?
:
: I would hope Perl would be smart enough to allow this:
:
: @out = ($scalar, @array, result_of_calling_function($param)).sort

It does, under the rule that says a comma list in a scalar context
assumes [...]. (The dot provides the scalar context to the comma
list--the outer list context is only meaningful to the sort.)

: which Ruby does:


:
: $ ruby -wle 'out = ["foo", "bar"].sort; print out.join " "'
: bar foo
:
: but as I said, I find the Lisp flow style worth keeping.
:
: @out = join "\n", map {...} grep {...} sort {...} @foo

That too. But you don't have to think of them as built-ins, except
insofar as any subroutine defined in * is a built-in. It's possible
the only real built-in is *sub. And maybe *rx.

Larry

Larry Wall

unread,
Dec 12, 2002, 8:33:06 PM12/12/02
to perl6-l...@perl.org
On Wed, Dec 11, 2002 at 06:50:12PM -0800, Michael Lazzaro wrote:
:

Actually, N might be 0. The : may not always be required on single arg
methods in indirect object syntax. That is, if there's no sub matching

keys %h

it'll fall back to looking for

keys %h:

I have horrors of seeing programs full of things like

close $FH:;

Larry

Larry Wall

unread,
Dec 12, 2002, 8:56:17 PM12/12/02
to perl6-l...@perl.org
On Wed, Dec 11, 2002 at 11:36:17PM +0000, Simon Cozens wrote:
: sch...@pobox.com (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 up some envy. :)
: > http://www.rubycentral.com/book/builtins.html
:
: I vaguely object to calling them builtins, as I've objected to similar
: concepts in Perl 6. They aren't *built in* to the language - you could
: add another method and the parser wouldn't give a damn - they are
: methods of the standard libraries that ship with Ruby. This
: distinction is important, despite what Damian would have you believe.

Foul! I suspect this is a fight over definitions, not beliefs. Damian
is usually pretty much on the mark with his beliefs.

: In the same way, the specification of C-as-a-language, its syntax and


: operators and the stuff that makes it look, act and feel like C, is
: agnostic of the C standard library. (Even though "ANSI C" specifies
: both, they are seperable.) This seperability is something I'd like
: to see thought about a lot more in Perl 6.
:
: > 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.
:
: Yes, yes, yes. This is what I've been trying to say for a while.

Don't get discouraged--I've been saying it for a good long time now, and
people still don't hear it, regardless of which side they're on...

About the only things that have to be truly built-in to Perl 6 are
lambda and the regex engine. Everything else is negotiable. (I'm
counting method dispatch under "lambda", of course... :-)

Larry

Chris Dutton

unread,
Dec 13, 2002, 12:28:32 AM12/13/02
to Michael Lazzaro, Simon Cozens, perl6-l...@perl.org
On Thursday, December 12, 2002, at 01:11 PM, Michael Lazzaro wrote:

> We can make that
>
> @out = @in.grep({...}).map({...}).sort; # [2]
>
> if we want to grind our OO axe, but I find that syntax disappointing.
> I like that the idea is important enough in Perl to have it's own
> grammar, but I realize the problem of namespace pollution involved in
> having a bunch of builtins called grep, map, whatever.
>
> The only encompassing solution would seem to be to find a grammar rule
> by which map,grep,etc are unambiguously methods of Array, but can still
> be called in a fashion similar to [1]. That would, I suspect, satisfy
> everyone.

Well, if the source file were considered to be just a big giant class,
sans

class main {
...
}

then it becomes as simple as having a method in Object, grep, something
like:

class Object {
method grep($a_closure, *@input) {
...
}
}

Luke Palmer

unread,
Dec 13, 2002, 4:52:49 AM12/13/02
to la...@wall.org, perl6-l...@perl.org
> Mailing-List: contact perl6-lan...@perl.org; run by ezmlm
> Date: Thu, 12 Dec 2002 17:33:06 -0800
> From: Larry Wall <la...@wall.org>
> Mail-Followup-To: perl6-l...@perl.org
> Content-disposition: inline
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/

>
> On Wed, Dec 11, 2002 at 06:50:12PM -0800, Michael Lazzaro wrote:
> :
> : 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, I'm aware that (1 <= N <= 5) of those are going away already.)
>
> Actually, N might be 0. The : may not always be required on single arg
> methods in indirect object syntax.

Yay!

Luke

Michael Lazzaro

unread,
Dec 13, 2002, 1:13:35 PM12/13/02
to Piers Cawley, perl6-l...@perl.org
>> The only encompassing solution would seem to be to find a grammar rule
>> by which map,grep,etc are unambiguously methods of Array, but can
>> still be called in a fashion similar to [1]. That would, I suspect,
>> satisfy everyone.

On Friday, December 13, 2002, at 03:07 AM, Piers Cawley wrote:
> What's wrong with:
>
> class Array {
> method grep ( &block ) {
<snip>
> }
>
> sub grep (Object $obj, @*ary) { @ary.grep($obj); }
>
> AFAICT, (modulo getting the laziness done right, this should allow
> you to write)
>
> grep { ... } @ary;
> grep /.../, @ary;

The only issue is that it still treats C<grep> as a universal sub --
it's just giving you an identically named C<grep> method of Array, too.
The ideal solution IMO is one that would remove C<map>, C<grep>, etc.
_entirely_ from the main/core/Object, and leave it _solely_ as a method
of Array. Not because C<grep> is inherently evil, but because that
would give us a completely generic way to make other "piped" grep-style
functions, like C<part>, without polluting the core namespace.

A (placeholder for a) R-to-L "dot-like" operator:

grep {...} <- @foo;

would be intended to be the *exact* equiv of

@foo.grep {...};

but with a reversed syntax for the invocant. So grep-like functions
could be nested, and new ones could be created by making new methods of
Array, AND we could get rid of the "specialness" of the Perl5 map/grep
syntax -- the syntax isn't special to a few list-munging functions, it
can be used for anything.

@out = sort <- map {...} <- grep {...} <- @in;

So it's almost what we had in Perl5, but more regular.

Of course, maybe '<-' is just spelled post-"given", and we're done:

@out = sort
given map { ... }
given grep { ... }
given @in;

Or would that be @out = .sort given .map ...etc...?

MikeL

Piers Cawley

unread,
Dec 13, 2002, 3:51:05 PM12/13/02
to Michael Lazzaro, perl6-l...@perl.org
Michael Lazzaro <mlaz...@cognitivity.com> writes:

> >> The only encompassing solution would seem to be to find a grammar rule
> >> by which map,grep,etc are unambiguously methods of Array, but can
> >> still be called in a fashion similar to [1]. That would, I suspect,
> >> satisfy everyone.
>
> On Friday, December 13, 2002, at 03:07 AM, Piers Cawley wrote:
> > What's wrong with:
> >
> > class Array {
> > method grep ( &block ) {
> <snip>
> > }
> >
> > sub grep (Object $obj, @*ary) { @ary.grep($obj); }
> >
> > AFAICT, (modulo getting the laziness done right, this should allow
> > you to write)
> >
> > grep { ... } @ary;
> > grep /.../, @ary;
>
> The only issue is that it still treats C<grep> as a universal sub --
> it's just giving you an identically named C<grep> method of Array,
> too. The ideal solution IMO is one that would remove C<map>, C<grep>,
> etc. _entirely_ from the main/core/Object, and leave it _solely_ as a
> method of Array. Not because C<grep> is inherently evil, but because
> that would give us a completely generic way to make other "piped"
> grep-style functions, like C<part>, without polluting the core
> namespace.

To what end? Actually, if we have multimethods correctly sorted, one
could envisage a CunningCollection class:

class CunningCollection {
method grep ( Object $obj ) { .as_array.grep($obj) }
sub grep ( Object $obj, CunningCollection $coll ) is exported {
$coll.grep($obj);
}
}

And it's trivial to do the same with any other syntax-like generic
function you care to come up with, no need for an extra syntactic wart.

>
> A (placeholder for a) R-to-L "dot-like" operator:
>
> grep {...} <- @foo;
>
> would be intended to be the *exact* equiv of
>
> @foo.grep {...};
>
> but with a reversed syntax for the invocant. So grep-like functions
> could be nested, and new ones could be created by making new methods
> of Array, AND we could get rid of the "specialness" of the Perl5
> map/grep syntax -- the syntax isn't special to a few list-munging
> functions, it can be used for anything.
>
> @out = sort <- map {...} <- grep {...} <- @in;
>
> So it's almost what we had in Perl5, but more regular.
>
> Of course, maybe '<-' is just spelled post-"given", and we're done:
>
> @out = sort
> given map { ... }
> given grep { ... }
> given @in;
>
> Or would that be @out = .sort given .map ...etc...?

Both of your proposed options are, frankly, vile. The
multimethod/generic function approach has the advantage of putting the
'burden' of writing the generic function on the implementor rather
than on the user. Given that implementation happens once and something
is used countless times, that seems like a decent trade off to me.

Austin Hastings

unread,
Dec 13, 2002, 5:54:00 PM12/13/02
to Piers Cawley, mlaz...@cognitivity.com, perl6-l...@perl.org

--- Piers Cawley <pdca...@bofh.org.uk> wrote:

>
> Both of your proposed options are, frankly, vile. The
> multimethod/generic function approach has the advantage of putting
> the
> 'burden' of writing the generic function on the implementor rather
> than on the user. Given that implementation happens once and
> something
> is used countless times, that seems like a decent trade off to me.

Dictionary.com sez:

"vile
adj. vil·er, vil·est
1. Loathsome; disgusting: vile language.
2. Unpleasant or objectionable: vile weather. See Synonyms at
offensive.
3.
- a. Contemptibly low in worth or account; second-rate.
- b. Of mean or low condition.
4. Miserably poor and degrading; wretched: a vile existence.
5. Morally depraved; ignoble or wicked: a vile conspiracy."


Is this one of those BOFH things where you insult the hell out of
someone and then give them a pat on the head, and six months later
they're arrested while sneaking into the London Zoo wearing a leather
corset and silk panties? (*)

Otherwise, I'm left to wonder. As I read Mike's post, he's proposing
that we regularize a feature of the language, make it extensible, and
potentially use a conceptual framework based on an existing syntactical
element.

Yours, on the other hand, gives (I hope) the extensibility, doesn't
require the syntactic bits but does appear to require that every such
method be implemented twice.

I'm going to need some more convincing.

=Austin

(*) Because if so, I'm all for it!


Piers Cawley

unread,
Dec 14, 2002, 1:59:09 AM12/14/02
to Austin_...@yahoo.com, mlaz...@cognitivity.com, perl6-l...@perl.org
Austin Hastings <austin_...@yahoo.com> writes:

> --- Piers Cawley <pdca...@bofh.org.uk> wrote:
>
> >
> > Both of your proposed options are, frankly, vile. The
> > multimethod/generic function approach has the advantage of putting
> > the 'burden' of writing the generic function on the implementor
> > rather than on the user. Given that implementation happens once
> > and something is used countless times, that seems like a decent
> > trade off to me.
>
> Dictionary.com sez:
>
> "vile
> adj. vil·er, vil·est
> 1. Loathsome; disgusting: vile language.
> 2. Unpleasant or objectionable: vile weather. See Synonyms at
> offensive.
> 3.
> - a. Contemptibly low in worth or account; second-rate.
> - b. Of mean or low condition.
> 4. Miserably poor and degrading; wretched: a vile existence.
> 5. Morally depraved; ignoble or wicked: a vile conspiracy."

I choose 2.

> Is this one of those BOFH things where you insult the hell out of
> someone and then give them a pat on the head, and six months later
> they're arrested while sneaking into the London Zoo wearing a
> leather corset and silk panties? (*)

I gave him a pat on the head? I told him that his proposed solutions
were unpleasant or possibly loathsome, and that he should throw them
away and stick with my proposed generic subroutines solution and you
call that a pat on the head? Coo.

> Otherwise, I'm left to wonder. As I read Mike's post, he's proposing
> that we regularize a feature of the language, make it extensible,
> and potentially use a conceptual framework based on an existing
> syntactical element.
>
> Yours, on the other hand, gives (I hope) the extensibility, doesn't
> require the syntactic bits but does appear to require that every
> such method be implemented twice.

Um. Not really implemented twice no. One subroutine implementation
can act as the facade for an awful lot of overloaded methods in the
class. Look at the grep implementation again:

class Array {
method grep ( Block &block ) {...}
method grep ( Rule $rx ) { ... }
method grep ( rx/<expr>/ $expr ) { ... }
sub grep ( Object $selector, @*ary ) is exported { ... }
}

A single generic sub is used to provide a functional interface to a
bunch of methods. Now, when we add grep behaviour to the
'CunningCollection' class, we will need to overload the generic sub
so that, in the case of

grep .selector, $some_cunning_collection;

the $cunning_selector doesn't just get stuffed into an array. One
could also imagine a scenario where someone implements a new
'selecting' object:

class NewSelector {
method grep ( $self: @*args ) {
grep $self.as_block, *@args;
}
sub grep ( NewSelector $selector, @*args ) is exported {
$selector.grep( *@args );
}
}

And I fail to see how Mike's proposed syntax will deal with
this. Remember that the one time (per class admittedly) cost of
setting up a generic sub buys us a good deal of not having to use
gratuitous punctuation (or ghod help us 'is given') at use time.

map { .[0] }
sort { $^a[1] cmp $^b[1] }
map { [ $_ => some_transform($_) }
grep /.../, @array

happily stays as it is; I fail to see what recasting that as

map { .[0] } <-
sort { $^a[1] cmp $^b[1] } <-
map { [ $_ => some_transform($_) } <-
grep /.../, @array

or any other 'noisy' suggestion buys us. It just seems like the wrong
kind of Laziness to me.

Michael Lazzaro

unread,
Dec 16, 2002, 12:58:45 PM12/16/02
to Piers Cawley, Austin_...@yahoo.com, perl6-l...@perl.org
On Friday, December 13, 2002, at 10:59 PM, Piers Cawley wrote:
> map { .[0] }
> sort { $^a[1] cmp $^b[1] }
> map { $_ => some_transform($_) }
> grep /.../, @array
>
> happily stays as it is; I fail to see what recasting that as
>
> map { .[0] } <-
> sort { $^a[1] cmp $^b[1] } <-
> map { $_ => some_transform($_) } <-
> grep /.../ <- @array

>
> or any other 'noisy' suggestion buys us. It just seems like the wrong
> kind of Laziness to me.
<edited to fix a minor typo>

My only concern is that the first implies (as it does in perl5) yet
more special behaviors attached to the {...} brackets. Either "no
comma is needed after a closure", or "no comma needed after the first
arg of the specific functions named C<map>, C<grep>, ...

I'm worried that in attaching even _more_ specialness to curlies (which
are already highly (impossibly?) magical), we're setting ourselves up
for some hurt down the road. It was OK in perl5, but I don't know if
it's OK in perl6.

Mind you (purely devil's advocate), I'm not entirely sure the R-to-L
syntax truly _needs_ to be in Perl6. It's true I use it all the time,
but I can retrain to use L-to-R method calls with little effort.

If we have a post-given, e.g. C<map {...} given @a> or C<map {...} is
given @a>, I think that gives us R-to-L without any special {...} rules
at all.

MikeL

Piers Cawley

unread,
Dec 16, 2002, 1:47:39 PM12/16/02
to Michael Lazzaro, Austin_...@yahoo.com, perl6-l...@perl.org
Michael Lazzaro <mlaz...@cognitivity.com> writes:

> On Friday, December 13, 2002, at 10:59 PM, Piers Cawley wrote:
>> map { .[0] }
>> sort { $^a[1] cmp $^b[1] }
>> map { $_ => some_transform($_) }
>> grep /.../, @array
>>
>> happily stays as it is; I fail to see what recasting that as
>>
>> map { .[0] } <-
>> sort { $^a[1] cmp $^b[1] } <-
>> map { $_ => some_transform($_) } <-
>> grep /.../ <- @array
>>
>> or any other 'noisy' suggestion buys us. It just seems like the wrong
>> kind of Laziness to me.
> <edited to fix a minor typo>
>
> My only concern is that the first implies (as it does in perl5) yet
> more special behaviors attached to the {...} brackets. Either "no
> comma is needed after a closure",

I think that's already a given; there's definitely discussion
elsewhere that takes that as read. And it's (prototyped) perl 5
behaviour, changing it to require a comma would be the Wrong Thing.

> or "no comma needed after the first arg of the specific functions
> named C<map>, C<grep>, ...

Definitely the Wrong Thing.

> I'm worried that in attaching even _more_ specialness to curlies
> (which are already highly (impossibly?) magical), we're setting
> ourselves up for some hurt down the road. It was OK in perl5, but I
> don't know if it's OK in perl6.
>
> Mind you (purely devil's advocate), I'm not entirely sure the R-to-L
> syntax truly _needs_ to be in Perl6. It's true I use it all the time,

> but I can retrain to use L-to-R method calls with little effort.\

Personally I really don't like the L to R style; I know we've got it
for C<< for ... -> $a { ... } >>, but I can see the logic behind
that, otherwise L to R looks worryingly like C++ to me.

> If we have a post-given, e.g. C<map {...} given @a> or C<map {...} is
> given @a>, I think that gives us R-to-L without any special {...}
> rules at all.

No, just the addition of much ugliness to code for no gain in
readability. And one more area where Perl 6 fails to look like Perl 5
for no good reason.

Dave Storrs

unread,
Dec 16, 2002, 2:12:40 PM12/16/02
to perl6-l...@perl.org
On Mon, Dec 16, 2002 at 06:47:39PM +0000, Piers Cawley wrote:
> Michael Lazzaro <mlaz...@cognitivity.com> writes:
>
> > Mind you (purely devil's advocate), I'm not entirely sure the R-to-L
> > syntax truly _needs_ to be in Perl6. It's true I use it all the time,
> > but I can retrain to use L-to-R method calls with little effort.\
>
> Personally I really don't like the L to R style;

That's ok. Personally, I do. You find R2L easier to read, I find L2R
easier. TIMTOWDI. Perl6 should be smart enough to support both.

>I know we've got it
> for C<< for ... -> $a { ... } >>, but I can see the logic behind
> that, otherwise L to R looks worryingly like C++ to me.

I'm not convinced that language snobbery is a good reason to include
or exclude a feature from Perl6. And, if there is logic in having L2R
in one case (for), why shouldn't we generalize it to be useful (or at
least possible) in all cases?


> > If we have a post-given, e.g. C<map {...} given @a> or C<map {...} is
> > given @a>, I think that gives us R-to-L without any special {...}
> > rules at all.
>
> No, just the addition of much ugliness to code for no gain in
> readability. And one more area where Perl 6 fails to look like Perl 5
> for no good reason.

Personally, I'm not fond of the specific syntax that MikeL is suggesting.

However, I think that L2R is valuable enough that it should make it
into the language, and I don't have a better suggestion.


--Dks


Piers Cawley

unread,
Dec 16, 2002, 3:26:25 PM12/16/02
to perl6-l...@perl.org

I haven't been arguing against his syntax for adding L to R
pipelines, but against the damage he proposes doing to R to L syntax.

> However, I think that L2R is valuable enough that it should make it
> into the language, and I don't have a better suggestion.

Well, L2R is really easy:

@ary.map({...}).grep(rx/.../).whatever(...);

For ugly values of 'really easy' of course.


Dan Sugalski

unread,
Dec 16, 2002, 3:44:21 PM12/16/02
to perl6-l...@perl.org
At 11:12 AM -0800 12/16/02, Dave Storrs wrote:
>On Mon, Dec 16, 2002 at 06:47:39PM +0000, Piers Cawley wrote:
>> Michael Lazzaro <mlaz...@cognitivity.com> writes:
>>
>> > Mind you (purely devil's advocate), I'm not entirely sure the R-to-L
>> > syntax truly _needs_ to be in Perl6. It's true I use it all the time,
>> > but I can retrain to use L-to-R method calls with little effort.\
>>
>> Personally I really don't like the L to R style;
>
>That's ok. Personally, I do. You find R2L easier to read, I find L2R
>easier. TIMTOWDI. Perl6 should be smart enough to support both.

Why?

Yes, technically we can do both R2L and L2R. We can also support an
alternative Scheme/Lisp form of perl's syntax, as well as a
Forth/Postscript style. Heck, we can probably manage a prolog-style
unification style for a not-insignificant subset of perl programs.
That doesn't mean its a good idea.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

Dave Storrs

unread,
Dec 16, 2002, 8:45:51 PM12/16/02
to perl6-l...@perl.org
On Mon, Dec 16, 2002 at 03:44:21PM -0500, Dan Sugalski wrote:
> At 11:12 AM -0800 12/16/02, Dave Storrs wrote:

> >You find R2L easier to read, I find L2R
> >easier. TIMTOWDI. Perl6 should be smart enough to support both.
>
> Why?
>
> Yes, technically we can do both R2L and L2R. We can also support an
> alternative Scheme/Lisp form of perl's syntax, as well as a
> Forth/Postscript style. Heck, we can probably manage a prolog-style
> unification style for a not-insignificant subset of perl programs.
> That doesn't mean its a good idea.


Just so I'm clear, are you saying that you think L2R is a bad idea,
and should not be supported? Or just that it has not yet been
demonstrated that this is a good idea?


--Dks


Dave Storrs

unread,
Dec 16, 2002, 8:43:30 PM12/16/02
to perl6-l...@perl.org
On Mon, Dec 16, 2002 at 08:26:25PM +0000, Piers Cawley wrote:
> Dave Storrs <dst...@megazone.bigpanda.com> writes:
> > On Mon, Dec 16, 2002 at 06:47:39PM +0000, Piers Cawley wrote:
> >> Michael Lazzaro <mlaz...@cognitivity.com> writes:

> I haven't been arguing against his syntax for adding L to R
> pipelines, but against the damage he proposes doing to R to L syntax.

Fair enough. I'd like to find a way for neither of them to go away,
or get damaged.

> > However, I think that L2R is valuable enough that it should make it
> > into the language, and I don't have a better suggestion.
>
> Well, L2R is really easy:
>
> @ary.map({...}).grep(rx/.../).whatever(...);
>
> For ugly values of 'really easy' of course.

Yick. I'll definitely agree on the "ugly" part.

However, I'm curious--and I know this has been hashed over, I'm just
not clear on where we stand at this point--are you proposing that map,
grep, and whatever would be methods on Array? Because that seems
unnecessarily restrictive. And yet, having them be methods of Object
seems a bit TOO generous.

Perhaps the answer is to have an inheritance tree that goes

Object
|
v
Collection
|
+-Array
|
+-Hash
|
+-etc (maybe Set, or maybe junction)

...and map, grep, etc, would be elements of Collection, overriden in
sensible ways by the derived classes?

This is an off-the-cuff idea and I may well be full of it.


--Dks

Piers Cawley

unread,
Dec 17, 2002, 12:44:21 AM12/17/02
to perl6-l...@perl.org
Dave Storrs <dst...@megazone.bigpanda.com> writes:

I've suggested a full blown Collection hierarchy elsewhere, but this
would be an ideal place for it. Then you can set up the function
style variants with just a couple of generic functions:

sub grep ( Object $selector, @*args ) { @args.grep($selector) }
sub grep ( Object $selector, Collection $coll ) {
$coll.grep($selector)
}

You know, the more I monkey with multi dispatch stuff, the more I
like it.

Josh Jore

unread,
Dec 17, 2002, 4:12:09 AM12/17/02
to perl6-l...@perl.org
On Wed, 11 Dec 2002, Michael G Schwern wrote:

> 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.

Are these objects class based or where do the methods come from? Is there
an accomodation for something like classless objects? Being forced into
class based objects might be problematic for a capabilities system where
you wouldn't want to have objects bristling with exposed methods.

Joshua Jore

Simon Cozens

unread,
Dec 17, 2002, 4:52:51 AM12/17/02
to perl6-l...@perl.org
dst...@megazone.bigpanda.com (Dave Storrs) writes:
> ...and map, grep, etc, would be elements of Collection, overriden in
> sensible ways by the derived classes?

Once again we're getting steadily closer to inventing Ruby.

--
void russian_roulette(void) { char *target; strcpy(target, "bullet"); }

Simon Cozens

unread,
Dec 17, 2002, 4:54:12 AM12/17/02
to perl6-l...@perl.org
dst...@megazone.bigpanda.com (Dave Storrs) writes:
> Just so I'm clear, are you saying that you think L2R is a bad idea,
> and should not be supported? Or just that it has not yet been
> demonstrated that this is a good idea?

I think supporting two distinct syntaces, one being a mirror image of
the other, is a bad idea. I'll leave people to argue over which one is
better because it keeps them out of the way. ;)

--
Congratulations, Simon - I think I've finally discovered someone with a
mind that is more warped than mine.
- Lionel Lauer

Simon Cozens

unread,
Dec 17, 2002, 4:55:40 AM12/17/02
to perl6-l...@perl.org
jo...@lavendergreens.org (Josh Jore) writes:
> Are these objects class based or where do the methods come from? Is there
> an accomodation for something like classless objects?

Piers earlier suggested having anonymous classes available (Class.new,
etc.), which seems like a good idea, meaning you could instantiate a new
object in a brand new class all at runtime if you needed to.

--
It's a testament to the versatility of the human mind that we're so able
to compensate for our own incompetence.
- Darrell Furhiman

Andy Wardley

unread,
Dec 17, 2002, 6:38:32 AM12/17/02
to Simon Cozens, perl6-l...@perl.org
Simon Cozens wrote:
> Once again we're getting steadily closer to inventing Ruby.

Agreed, but I don't think this is necessarily a Bad Thing.

Larry said ~~ "People have been borrowing ideas from Perl for a long time,
now it's time to borrow some back".

I like Ruby, I like dot ops, and I like being able to chain them together
from left to right. I would really like it if these were some of the
ideas that we borrow back from Ruby (and other places).

As it happens, I've already borrowed them for the Template Toolkit.
Of course, TT doesn't count as a Real Programming Language, but it
does support the same syntax for accessing data and it's very useful.

myhash.keys.sort.join(', ') # valid in both Ruby and TT

Of course, this is semantically no different to the Perl 5 equivalent:

join(', ', sort keys %$myhash)

but I find it easier to read as it progresses more naturally, to me at
least, from left to right. Take myhash, get the keys, sort them, then
join them together.

This is essentially a pipeline style of processing:

a --> b --> c

whereas the usual right to left is technically a nested form:

a ( b ( c ) )

which effectively reverses the order of evaluation of the pipeline:

c --> b --> a

I think both are equally valid and should be supported, if possible.

Sometimes it makes sense to think about a problem from start to finish
(input driven or "push"). Other times it's better to think about the
desired goal and work backwards towards the beginning (output driven
or "pull").

In one situation you might think "I want to take myhash, extract the
keys, sort them and then join them together to make a string" and
write C<$myhash.keys.sort.join(', ')>. In another you'll think
"I need a string containing the sorted keys of myhash" and instead
write C<join(', ', sort keys %$myhash)>.

It seems to me that L.R syntax falls out naturally in Perl 6 from the
dotop. Hash objects will have 'keys' methods, Array objects will have
'sort' and 'join' methods and everything should just work as expected.

$hash.keys.sort.join(', ');

The sticky issue is how to pass a block to sort, map, grep, etc.

Well, if we can't come up with anything better than explicitly passing
a block as an argument, e.g.

$hash.keys.sort({ ... }).join(', ');

then I still think this is better than nothing at all.

If you end up writing pathological cases where you're passing lots of
blocks as arguments, then perhaps it would be better written in a regular
Perl 5 right to left (nested), or even a mixed style.

join( ', ', sort { ... } $hash.keys );

If we can come up with something that makes this syntactic pill a little
easier to swallow, then that's great. But even if we can't, I don't think
it's the end of the world, or even the world.end :-)


A

sch...@pobox.com

unread,
Dec 17, 2002, 4:53:39 AM12/17/02
to Josh Jore, perl6-l...@perl.org

These are questions about the general design of Perl 6's OO system and out of the scope of ths discussion. The Perl 6 OO Cookbook does a good job of documenting what OO will look like in Perl 6 this week:
http://cog.cognitivity.com/perl6/

Dan Sugalski

unread,
Dec 17, 2002, 9:49:42 AM12/17/02
to perl6-l...@perl.org

I think it's a good idea, and that it should *not* be supported.

Dan Sugalski

unread,
Dec 17, 2002, 9:48:56 AM12/17/02
to Andy Wardley, Simon Cozens, perl6-l...@perl.org
At 11:38 AM +0000 12/17/02, Andy Wardley wrote:
>Simon Cozens wrote:
>> Once again we're getting steadily closer to inventing Ruby.
>
>Agreed, but I don't think this is necessarily a Bad Thing.

Disagreed--we're getting steadily closer to inventing Smalltalk. :)
Which isn't altogether a bad thing. (As long as we don't vet closer
to inventing Lisp...)

Michael Lazzaro

unread,
Dec 17, 2002, 12:15:57 PM12/17/02
to Josh Jore, perl6-l...@perl.org

On Tuesday, December 17, 2002, at 01:53 AM, sch...@pobox.com wrote:
> These are questions about the general design of Perl 6's OO system and
> out of the scope of ths discussion. The Perl 6 OO Cookbook does a
> good job of documenting what OO will look like in Perl 6 this week:
> http://cog.cognitivity.com/perl6/

...except for the parts I completely made up, as placeholders for real
stuff later. :-) (But I think I have those sections all marked now.)

MikeL

Michael Lazzaro

unread,
Dec 17, 2002, 12:54:52 PM12/17/02
to perl6-l...@perl.org
Umm... I think some of these recent messages have had typos between L2R
and R2L. (?) In that people seem to have been arguing against
themselves. (??) I'll try using --> and <--.

On Monday, December 16, 2002, at 05:45 PM, Dave Storrs wrote:
> Just so I'm clear, are you saying that you think L2R is a bad idea,
> and should not be supported? Or just that it has not yet been
> demonstrated that this is a good idea?

We _must_ (for some value of "must" that is real close to being a 100%
drop-dead requirement) support --> (L2R), in the form of

@a.grep( {...} )
.map( {...} )
.sort;

i.e. however else we do it, array processing functions _MUST_ exist as
methods of Array. That may not be the preferred spelling, or anything
close to attractive, but it would be simply pathetic for it not to
exist.

Almost everyone's been clamoring over how we want OO and OO is cool and
everything should be treatable as an object. If arrays are objects,
the above is How It's Gonna Look, unless we want to invent a
method-call syntax for arrays that is completely different from that of
scalars.

So if anyone _doesn't_ want the above dot-syntax to exist AT ALL,
please explain the rationale!

_However_, the above code is probably the most formal usage of the
array-manipulation methods. If we want another way to say it, e.g. <--
(R2L) or a prettier --> (L2R), we could probably have it. But it would
have to be in _addition_ to the above, not _instead_ of. We can add
the Perl5-style:

@out = sort map {...} grep {...} @a;

if we want to, but I don't think it should be given a free ride in
Perl6. It's not regular (not like anything else in the language),
sucks up those names as globally reserved (as opposed to merely methods
of arrays), implies more possible wacky behaviors of curlies, and
cannot credibly be tortured into being OO upon @a.

So whether prettyified <-- (R2L) and --> (L2R) forms exist and what
they look like, we can argue about. But the method form (L2R) @a.grep,
etc, simply _must_ be valid, if not encouraged.

MikeL

Dan Sugalski

unread,
Dec 17, 2002, 2:51:04 PM12/17/02
to Michael Lazzaro, perl6-l...@perl.org
At 9:54 AM -0800 12/17/02, Michael Lazzaro wrote:
>Umm... I think some of these recent messages have had typos between
>L2R and R2L. (?) In that people seem to have been arguing against
>themselves. (??) I'll try using --> and <--.
>
>On Monday, December 16, 2002, at 05:45 PM, Dave Storrs wrote:
>>Just so I'm clear, are you saying that you think L2R is a bad idea,
>>and should not be supported? Or just that it has not yet been
>>demonstrated that this is a good idea?
>
>We _must_ (for some value of "must" that is real close to being a
>100% drop-dead requirement) support --> (L2R), in the form of
>
> @a.grep( {...} )
> .map( {...} )
> .sort;

Those are simple method calls, so there's no reason we shouldn't
support them, though they will *only* work if each returns an actual
array, rather than a list. They are, however, not the same as doing:

@b = @a grep {} map {} sort {};

because that's true L2R, as it'll work for:

@b = (*@a, *@b, foobar()) grep {} map {} sort {};

That can't work as methods of the list, unless we're wildly
redefining how lists work, which I don't think we're going to do.

*That's* the sort of way, the L2R way, that I'd argue against.
Shifting directions in mid-stream is, well, really tough for us old
codgers.

And you can't get rid of the old way, since it's just implicit
function calls. To forbid

@b = sort {} map {} grep {} @a;

is the same as forbidding

@b = sort({}, map({}, grep({}, @a)));

which I think would be... unwise. As would chopping sort/map/grep and
friends from the language entirely. One of the hallmarks of perl is
its richness, and I think losing that would be ill-advised.

Dan Sugalski

unread,
Dec 17, 2002, 6:00:14 PM12/17/02
to sch...@pobox.com, Andy Wardley, Simon Cozens, perl6-l...@perl.org
At 2:47 PM -0800 12/17/02, sch...@pobox.com wrote:

>On Tue, Dec 17, 2002 at 09:48:56AM -0500, Dan Sugalski wrote:
>> >Simon Cozens wrote:
>> >> Once again we're getting steadily closer to inventing Ruby.
>> >
>> >Agreed, but I don't think this is necessarily a Bad Thing.
>>
>> Disagreed--we're getting steadily closer to inventing Smalltalk. :)
>
>Silly rabbit, Ruby is Smalltalk!

And it's part of this nutritious breakfast! Well, adjacent to it, at
least... :-P

sch...@pobox.com

unread,
Dec 17, 2002, 5:47:38 PM12/17/02
to Dan Sugalski, Andy Wardley, Simon Cozens, perl6-l...@perl.org
On Tue, Dec 17, 2002 at 09:48:56AM -0500, Dan Sugalski wrote:
> >Simon Cozens wrote:
> >> Once again we're getting steadily closer to inventing Ruby.
> >
> >Agreed, but I don't think this is necessarily a Bad Thing.
>
> Disagreed--we're getting steadily closer to inventing Smalltalk. :)

Silly rabbit, Ruby is Smalltalk!

Petras

unread,
Dec 19, 2002, 8:52:41 AM12/19/02
to perl6-l...@perl.org
First of all, I would like to introduce myself. I have been watching the
Perl6 language ideas for some time with growing interest. I am not a great
programmer, more like a hobbyist who sometimes applies his programming
skills at work. And here are my views on this very interesting topic ;)

> Simon Cozens wrote:
>> Once again we're getting steadily closer to inventing Ruby.
> Agreed, but I don't think this is necessarily a Bad Thing.

Now, I do like Ruby. And I definately don't see this as a Bad Thing.
In my opinion, Perl6 should have all the best features from all the best
languages ;)

> myhash.keys.sort.join(', ') # valid in both Ruby and TT
> Of course, this is semantically no different to the Perl 5 equivalent:
> join(', ', sort keys %$myhash)

The first one seems to be more readable to me, although I am used to using
the second one. I think it would be easier for new people to learn (and to
use) the first case rather the second one (I am taking a newbie point of
view here ;)

> I think both are equally valid and should be supported, if possible.

TIMTOWTDI revisited. I am not sure how Larry stands on thsi fundamental
Perl paradigm in Perl6, but I have grown accustomed with TIMTOWTDI and
that's why I like Perl.

> The sticky issue is how to pass a block to sort, map, grep, etc.
> Well, if we can't come up with anything better than explicitly passing
> a block as an argument, e.g.
> $hash.keys.sort({ ... }).join(', ');

This is not as bad. At least it seems to me quite natural and easily
understandable.

> If you end up writing pathological cases where you're passing lots of
> blocks as arguments, then perhaps it would be better written in a
> regular Perl 5 right to left (nested), or even a mixed style.
> join( ', ', sort { ... } $hash.keys );

Now this it where things start to get weird, of course. Lots of
possibilities for obfuscation, but again, Perl5 has been famous for these
kind of things.

Petras Kudaras

David Storrs

unread,
Dec 19, 2002, 10:28:17 AM12/19/02
to perl6-l...@perl.org

On Tue, Dec 17, 2002 at 09:49:42AM -0500, Dan Sugalski wrote:
> At 5:45 PM -0800 12/16/02, Dave Storrs wrote:
> >Just so I'm clear, are you saying that you think L2R is a bad idea,
> >and should not be supported? Or just that it has not yet been
> >demonstrated that this is a good idea?
>
> I think it's a good idea, and that it should *not* be supported.

Um...I'm sorry, I really don't understand that, could you explain it
to me? If it's a good idea, why shouldn't we support it?

--Dks

David Storrs

unread,
Dec 19, 2002, 10:25:39 AM12/19/02
to perl6-l...@perl.org
On Tue, Dec 17, 2002 at 09:54:12AM +0000, Simon Cozens wrote:
> dst...@megazone.bigpanda.com (Dave Storrs) writes:
> > Just so I'm clear, are you saying that you think L2R is a bad idea,
> > and should not be supported? Or just that it has not yet been
> > demonstrated that this is a good idea?
>
> I think supporting two distinct syntaces, one being a mirror image of
> the other, is a bad idea.

I honestly don't understand why not...can you explain it to me? So
long as, within any given statement, it is clear which syntax is being
used, what's the problem? Perl has always been famous for supporting
the kitchen sink and letting you choose which faucet you want to turn
on--e.g., we have OO style, imperative style, and a pretty full
language built into the regexen.

--Dks

David Storrs

unread,
Dec 19, 2002, 10:55:24 AM12/19/02
to perl6-l...@perl.org
On Tue, Dec 17, 2002 at 09:54:52AM -0800, Michael Lazzaro wrote:
> Umm... I think some of these recent messages have had typos between L2R
> and R2L. (?) In that people seem to have been arguing against
> themselves. (??) I'll try using --> and <--.

Just to make sure I'm not one of those people, I'll clarify my terms:

I am calling this L2R:

@b = @a --> sort --> map { $_++ } --> grep { $_ > 0 };

I don't care about the syntax at all, I just made up something that
seemed moderately clear to me. In point of fact, I hope we DON'T use
the above syntax, or anything else where you are required to have an
operator between each element of the pipeline.

I am calling this R2L:

@b = grep { $_ > 0 } map { $_++ } sort @a;

Note that this is just Perl5 code.


> We _must_ (for some value of "must" that is real close to being a 100%
> drop-dead requirement) support --> (L2R), in the form of
>
> @a.grep( {...} )
> .map( {...} )
> .sort;
>
> i.e. however else we do it, array processing functions _MUST_ exist as
> methods of Array. That may not be the preferred spelling, or anything
> close to attractive, but it would be simply pathetic for it not to
> exist.

Well, I generally agree with you, but with an important nit: they
shouldn't be members of Array, they should be members of Collection,
Array's base class. Otherwise, what if I define an UnorderedMultiSet class and I want to grep over it?

Ok, let me play Devil's Advocate (*) for a moment. Why do we need
this? Why should these names be locked up in the Array class? What
if I want to grep a list, or if I want to define some kind of class
for which it is meaningful to grep an instance...perhaps an
UnorderedMultiSet class. If these functions are locked up in Array, I
will need to either derive my UnorderedMultiSet from Array
(inappropriate), use an Array internally (perhaps inconvenient), or
redefined the methods myself (wasteful).

> have to be in _addition_ to the above, not _instead_ of. We can add
> the Perl5-style:
>
> @out = sort map {...} grep {...} @a;
>
> if we want to, but I don't think it should be given a free ride in
> Perl6. It's not regular (not like anything else in the language),
> sucks up those names as globally reserved (as opposed to merely methods
> of arrays), implies more possible wacky behaviors of curlies, and
> cannot credibly be tortured into being OO upon @a.

Hmmm...I don't suppose that, with implicit promotion to Array, we can
get out of this with the indirect object notation, can we? I'm not
sure what it looks like this week, but perhaps we could make a minor
requirement change (e.g., need a comma on the methods and a trailing :
on the @a) and shoehorn it into something like this:

@out = sort map {...}, grep {...}, @a:;

--Dks

David Storrs

unread,
Dec 19, 2002, 11:03:14 AM12/19/02
to perl6-l...@perl.org
On Tue, Dec 17, 2002 at 02:51:04PM -0500, Dan Sugalski wrote:
> At 9:54 AM -0800 12/17/02, Michael Lazzaro wrote:
> >We _must_ (for some value of "must" that is real close to being a
> >100% drop-dead requirement) support --> (L2R), in the form of
> >
> > @a.grep( {...} )
> > .map( {...} )
> > .sort;
>
> Those are simple method calls, so there's no reason we shouldn't
> support them, though they will *only* work if each returns an actual
> array, rather than a list.

Question on this: for me, one of the trickiest things when teaching
Perl5 has always been explaining the difference between an array and a
list, when you need one versus the other, why they aren't precisely
the same, and where the differences are.

What exactly are the advantages of having both in Perl6? Is it
possible that we could put them together and have only one or the
other without losing anything (that we aren't willing to lose)?


> @b = (*@a, *@b, foobar()) grep {} map {} sort {};
>
> That can't work as methods of the list, unless we're wildly
> redefining how lists work, which I don't think we're going to do.

I don't know enough to see why this is a problem. Can you explain it?


> *That's* the sort of way, the L2R way, that I'd argue against.
> Shifting directions in mid-stream is, well, really tough for us old
> codgers.

Mid-stream in terms of the work that's been done on Parrot or in terms
of your programming experience? i.e., are you saying that it would
require major redesign and recoding on the existing engine, or that it
would be hard to get used to having it in the language?


> function calls. To forbid
>
> @b = sort {} map {} grep {} @a;
>
> is the same as forbidding
>
> @b = sort({}, map({}, grep({}, @a)));
>
> which I think would be... unwise. As would chopping sort/map/grep and
> friends from the language entirely. One of the hallmarks of perl is
> its richness, and I think losing that would be ill-advised.

Indeed.


--Dks

Jonathan Scott Duff

unread,
Dec 19, 2002, 11:14:25 AM12/19/02
to perl6-l...@perl.org
On Thu, Dec 19, 2002 at 08:03:14AM -0800, David Storrs wrote:
> On Tue, Dec 17, 2002 at 02:51:04PM -0500, Dan Sugalski wrote:
> > At 9:54 AM -0800 12/17/02, Michael Lazzaro wrote:
> > >We _must_ (for some value of "must" that is real close to being a
> > >100% drop-dead requirement) support --> (L2R), in the form of
> > >
> > > @a.grep( {...} )
> > > .map( {...} )
> > > .sort;
> >
> > Those are simple method calls, so there's no reason we shouldn't
> > support them, though they will *only* work if each returns an actual
> > array, rather than a list.
>
> Question on this: for me, one of the trickiest things when teaching
> Perl5 has always been explaining the difference between an array and a
> list, when you need one versus the other, why they aren't precisely
> the same, and where the differences are.
>
> What exactly are the advantages of having both in Perl6? Is it
> possible that we could put them together and have only one or the
> other without losing anything (that we aren't willing to lose)?

I was under the impression that the distinction between array and list
was going away in perl 6. Surely if (1,2,3) creates an anonymous
array reference, then (1,2,3).foo will work for any foo able to
operate on an array.

> > @b = (*@a, *@b, foobar()) grep {} map {} sort {};
> >
> > That can't work as methods of the list, unless we're wildly
> > redefining how lists work, which I don't think we're going to do.
>
> I don't know enough to see why this is a problem. Can you explain it?

So, the above would be written a little punctuatively different:

@b = (*@a, *@b, foobar()).grep({}).map({}).sort({});

-Scott
--
Jonathan Scott Duff
du...@cbi.tamucc.edu

Simon Cozens

unread,
Dec 19, 2002, 11:15:34 AM12/19/02
to perl6-l...@perl.org
du...@cbi.tamucc.edu (Jonathan Scott Duff) writes:
> I was under the impression that the distinction between array and list
> was going away in perl 6.

@a is an array; *@a is a list.

--
"In matters of principle, stand like a rock; in matters of taste, swim with
the current."
-- Thomas Jefferson

Brent Dax

unread,
Dec 19, 2002, 11:35:54 AM12/19/02
to David Storrs, perl6-l...@perl.org
David Storrs:
# I don't care about the syntax at all, I just made up
# something that seemed moderately clear to me. In point of
# fact, I hope we DON'T use the above syntax, or anything else
# where you are required to have an operator between each
# element of the pipeline.

How else would you disambiguate?

# > We _must_ (for some value of "must" that is real close to
# being a 100%
# > drop-dead requirement) support --> (L2R), in the form of
# >
# > @a.grep( {...} )
# > .map( {...} )
# > .sort;
# >
# > i.e. however else we do it, array processing functions
# _MUST_ exist as
# > methods of Array. That may not be the preferred spelling,
# or anything
# > close to attractive, but it would be simply pathetic for it not to
# > exist.

If we put in my idea of "longest possible signature" when there's no
parens and a low-precedence 'dot' operator, we could do this without the
parens. *ducks*

# Well, I generally agree with you, but with an important nit:
# they shouldn't be members of Array, they should be members of
# Collection, Array's base class. Otherwise, what if I define
# an UnorderedMultiSet class and I want to grep over it?

Fine. What do you grep over when you're grepping a hash? .k? .v? .kv
and pass two values in? Pair objects?

# > have to be in _addition_ to the above, not _instead_ of. We can add
# > the Perl5-style:
# >
# > @out = sort map {...} grep {...} @a;
# >
# > if we want to, but I don't think it should be given a free ride in
# > Perl6. It's not regular (not like anything else in the language),
# > sucks up those names as globally reserved (as opposed to
# merely methods
# > of arrays), implies more possible wacky behaviors of curlies, and
# > cannot credibly be tortured into being OO upon @a.
#
# Hmmm...I don't suppose that, with implicit promotion to
# Array, we can get out of this with the indirect object
# notation, can we? I'm not sure what it looks like this week,
# but perhaps we could make a minor requirement change (e.g.,
# need a comma on the methods and a trailing : on the @a) and
# shoehorn it into something like this:
#
# @out = sort map {...}, grep {...}, @a:;

Eww. Indir object is like this:

@out = sort map grep @a: {grepblock} {mapblock};
#I'm not sure you can actually leave out the
# parens--it might be ambiguous.

I assume you can see why this is a Bad Thing.

--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be

Brent Dax

unread,
Dec 19, 2002, 1:45:18 PM12/19/02
to Michael Lazzaro, David Storrs, perl6-l...@perl.org
Michael Lazzaro:
# On Thursday, December 19, 2002, at 08:35 AM, Brent Dax wrote:
# > Eww. Indir object is like this:
# >
# > @out = sort map grep @a: {grepblock} {mapblock};
# > #I'm not sure you can actually leave out the
# > # parens--it might be ambiguous.
#
# I actually thought the indirect object syntax would be... umm...
#
# @out = sort map grep @a : {grepblock} : {mapblock} :;
#
# (with three ':'s, one per method?)

Oh, yeah, that's it. Sorry.

Michael Lazzaro

unread,
Dec 19, 2002, 1:14:59 PM12/19/02
to Brent Dax, David Storrs, perl6-l...@perl.org
On Thursday, December 19, 2002, at 08:35 AM, Brent Dax wrote:
> Eww. Indir object is like this:
>
> @out = sort map grep @a: {grepblock} {mapblock};
> #I'm not sure you can actually leave out the
> # parens--it might be ambiguous.

I actually thought the indirect object syntax would be... umm...

@out = sort map grep @a : {grepblock} : {mapblock} :;

(with three ':'s, one per method?)

Wow. Now that's *spectacularly* ugly! It looks like it has cooties.
(Hmm, perhaps ':' can be the 'cootie' operator...)

MikeL

Michael Lazzaro

unread,
Dec 19, 2002, 1:04:24 PM12/19/02
to David Storrs, perl6-l...@perl.org
On Thursday, December 19, 2002, at 07:55 AM, David Storrs wrote:
> On Tue, Dec 17, 2002 at 09:54:52AM -0800, Michael Lazzaro wrote:
>> We _must_ (for some value of "must" that is real close to being a 100%
>> drop-dead requirement) support --> (L2R), in the form of
>>
>> @a.grep( {...} )
>> .map( {...} )
>> .sort;
>>
>> i.e. however else we do it, array processing functions _MUST_ exist as
>> methods of Array. That may not be the preferred spelling, or anything
>> close to attractive, but it would be simply pathetic for it not to
>> exist.
>
> Well, I generally agree with you, but with an important nit: they
> shouldn't be members of Array, they should be members of Collection,
> Array's base class. Otherwise, what if I define an UnorderedMultiSet
> class and I want to grep over it?

Yeah. I don't know what the precise class tree will look like, but as
long as you can call these methods on an Array and whatever other
collections exist, it works, regardless of how we put them there.

MikeL