Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
Date: Thu, 12 Dec 2002 17:07:21 -0800 From: Larry Wall [EMAIL PROTECTED] It's not clear what .can should return for a multimethod, either. You'd have be able to return results like: yes int can mult, but only if the second argument is an int or num. Basically, .can has a bad syntax. We need a modifier on an ordinary multimethod or subroutine call that says, Go through all the motions of calling this, but don't really. To do that kind of almost-dispatch you often need the actual arguments, or something resembling them. One is tempted to say that taking a reference to a function call with arguments does something like this: \Main::foo(1,3) The reference could be bound to the dispatch list, or be false if nothing matched. Perhaps currying could be our aide: can(foo.assuming(1, 3)); The only question is, what happens when not all the arguments are curried? Perhaps it could return true if the rest of the arguments matched any multimethod. So: can(bar); Without any currying would be true if bar is a sub, and false if it isn't. I think that generalizes nicely. Luke
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
Date: Thu, 12 Dec 2002 16:26:28 -0500
From: John Siracusa [EMAIL PROTECTED]
On 12/12/02 4:01 PM, Larry Wall wrote:
On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
: So we'll _have_ to write $obj.*id when we mean $obj-UNIVERSAL::id;
If you wish to be precise, yes. But $a.id eq $b.id should work for most any
class that uses the the term id in the typical fashion.
I still feel like we're talking past each other here. What I was saying is
that, regardless of any admonitions to the contrary, I think people will
still write this:
$a.id == $b.id
and expect it to compare memory addresses.
And presumably, anyone who overrides .id in their own class knows what
they're doing. They, in fact, Iwant statements like that to behave
that way. Junction, by delegation, will override that method to
return a junction of the .ids of its states.
Speaking of which, how do you code delegation?
class Disjunction is Junction {
has @.states is public;
# ...
# Use the class's AUTOLOAD?
method AUTOLOAD($name, *@args) {
any(map { $_.$name.(*@args) } @.states);
}
# Or use some kind of DELEGATE method, taking a curried
# function with only the invocant left blank.
method DELEGATE(func) {
any(map { $_.func } @.states);
}
}
I rather like the latter.
Luke
RE: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
John Siracusa wrote:
On 12/12/02 12:55 PM, Larry Wall wrote:
As for namespace pollution and classes that use .id in Perl 5, I
don't think it's going to be a big problem. Built-in identifiers
do not have a required prefix, but they have an optional prefix,
which is C*. I think we can probably parse
$a.*id == $b.*id
if you really need to get to Object.id().
That'll only work out if everyone always writes it as *id.
If not, my Perl 6 objects that override id() won't work correctly
with any other classes or functions that simply call id and
expect it to really be *id
yes...
So we'll _have_ to write $obj.*id when we mean $obj-UNIVERSAL::id;
I'm not sure I understand what Larry means by most-global... Do you mean
outer-most scope, root-of-method-inheritence, or both?
And what of the case we someone does want to explicitly override a builtin
method like UNIVERSAL::can? What is the Perl6 equivalent to:
*UNIVERSAL::can = sub { print qq{hello\n} };
sub foo {};
print main-can('foo');
And what will:
main.*can('foo')
result in?
Larry Wall wrote:
I'd almost be tempted to argue that if push comes to shove, it's
the list splat star that gets shoved.
Don't you suspect the list splat will be more common than most-global?
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
: John Siracusa wrote:
: On 12/12/02 12:55 PM, Larry Wall wrote:
: As for namespace pollution and classes that use .id in Perl 5, I
: don't think it's going to be a big problem. Built-in identifiers
: do not have a required prefix, but they have an optional prefix,
: which is C*. I think we can probably parse
:
: $a.*id == $b.*id
:
: if you really need to get to Object.id().
:
: That'll only work out if everyone always writes it as *id.
: If not, my Perl 6 objects that override id() won't work correctly
: with any other classes or functions that simply call id and
: expect it to really be *id
:
: yes...
:
: So we'll _have_ to write $obj.*id when we mean $obj-UNIVERSAL::id;
If you wish to be precise, yes. But $a.id eq $b.id should work for most any
class that uses the the term id in the typical fashion.
: I'm not sure I understand what Larry means by most-global... Do you mean
: outer-most scope, root-of-method-inheritence, or both?
It's context dependent, just as the meaning of an identifier is context dependent.
In this case, it means root-of-method-inheritance, that is, Object. (That is
tne new name of UNIVERSAL.) So $a.*id is short for $a.Object::id. But $*foo
is short for $Global::foo or some such.
: And what of the case we someone does want to explicitly override a builtin
: method like UNIVERSAL::can? What is the Perl6 equivalent to:
:
: *UNIVERSAL::can = sub { print qq{hello\n} };
: sub foo {};
: print main-can('foo');
Any of:
method Object::can ($meth) { print qq[hello\n] }
or
*can := method ($meth) { print qq[hello\n] };
or
Object::can ::= sub ($object, $method) { print qq[hello\n] };
Hmm. Those don't really stand out enough. Maybe we should go with
OBJECT:: and GLOBAL:: just for a little more visual punch.
: And what will:
:
: main.*can('foo')
:
: result in?
These days it's Main, not main. And it's a module, not a class,
so probably it fails, unless someone can think of something useful
for it to mean.
: Larry Wall wrote:
:
: I'd almost be tempted to argue that if push comes to shove, it's
: the list splat star that gets shoved.
:
: Don't you suspect the list splat will be more common than most-global?
That's why I said almost.
Larry
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On 12/12/02 4:01 PM, Larry Wall wrote: On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote: : So we'll _have_ to write $obj.*id when we mean $obj-UNIVERSAL::id; If you wish to be precise, yes. But $a.id eq $b.id should work for most any class that uses the the term id in the typical fashion. I still feel like we're talking past each other here. What I was saying is that, regardless of any admonitions to the contrary, I think people will still write this: $a.id == $b.id and expect it to compare memory addresses. That is not the typical fashion for an object method named id to work, IMO. The need to compare memory addresses is so infrequent that warrants a much less common and/or longer method name than id. -John
RE: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
Larry Wall:
# Hmm. Those don't really stand out enough. Maybe we should go with
# OBJECT:: and GLOBAL:: just for a little more visual punch.
How about CORE:: instead of GLOBAL::? This helps stick with tradition
and minimize the number of reserved packages.
# : And what will:
# :
# : main.*can('foo')
# :
# : result in?
#
# These days it's Main, not main. And it's a module, not a
# class, so probably it fails, unless someone can think of
# something useful for it to mean.
I'd hope that Perl would allow me to do something like that to see if
Main::foo exists...
--Brent Dax [EMAIL PROTECTED]
@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
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On Thu, Dec 12, 2002 at 01:50:37PM -0800, Brent Dax wrote:
: Larry Wall:
: # Hmm. Those don't really stand out enough. Maybe we should go with
: # OBJECT:: and GLOBAL:: just for a little more visual punch.
:
: How about CORE:: instead of GLOBAL::? This helps stick with tradition
: and minimize the number of reserved packages.
I don't like the Perl 5 tradition on top-level namespaces.
First of all, nobody really knows what core means anymore. Is it
just the built-in opcodes? Is it the functions that come with the
distribution? Neither of those map onto Perl 5 concept of CORE::
anymore. So Perl 6 doesn't have a CORE:: anymore. What used to
be in CORE goes into *, whever that means.
Second, in Perl 5 there are two global namespaces apart from CORE::.
If you say $::foo, you get $main::foo. If you say $STDIN, you
get some other namespace that has no name in Perl 5. In Perl 6,
the latter truly global namespace is combined with CORE to get what
main was trying to be in Perl 5. The former main namespace is
no longer intended to be used for globals, and the $::foo syntax is
no longer supported for that purpose. The translator will translate
$::foo to $Main::foo.
So $*IN really is considered to be in the global namespace, not
in the core namespace. You might argue that stdin is core in
some sense, but all global names go into *, not just built-ins.
This includes all user-defined package names. So the real name of
package Foo is GLOBAL::Foo. It's not Main::Foo, nor is it CORE::Foo.
It's short name isn't ::Foo, but *Foo. And you can just call it Foo
because the search for identifiers ends in GLOBAL (except for methods,
for which the search ends in OBJECT).
: # : And what will:
: # :
: # : main.*can('foo')
: # :
: # : result in?
: #
: # These days it's Main, not main. And it's a module, not a
: # class, so probably it fails, unless someone can think of
: # something useful for it to mean.
:
: I'd hope that Perl would allow me to do something like that to see if
: Main::foo exists...
Ordinarily you'd test for subs with one of
exists Main::foo
Main::foo.exists
As to whether .can should work for that, it should depend on whether
it's possible to invoke foo as a method in Main. This may or may
not be the same thing as having a sub declaration named foo.
Certainly classes will distinguish subs from methods. It may be
that modules will too, and you'd have to write package Main to
get Perl to confuse them like Perl 5 does. But that's not decided yet.
It's not clear what .can should return for a multimethod, either.
You'd have be able to return results like: yes int can mult, but
only if the second argument is an int or num. Basically, .can
has a bad syntax. We need a modifier on an ordinary multimethod
or subroutine call that says, Go through all the motions of calling
this, but don't really. To do that kind of almost-dispatch you often
need the actual arguments, or something resembling them. One is tempted
to say that taking a reference to a function call with arguments
does something like this:
\Main::foo(1,3)
The reference could be bound to the dispatch list, or be false if nothing
matched.
Except that syntax currently means something else, and doesn't work
for method calls. Maybe it's a good place for a question mark:
Main::foo?(1,3)
$foo.bar?(3)
and maybe even
$x +? $y
It's vaguely possible this should be unified with currying if the
construct actually returns a reference with prebound arguments.
It's also possible that it's not visible enough, and we should say
splashy like:
can { Main::foo(1,3) }
can { $foo.bar(3) }
can { $a + $y }
Exactly how much can-{} should do without doing anything is left as
an exercise for the reader. What would it do with this:
can { $a + $y + snort() }
I suppose one could set up a transactional structure in which can
actually does the side effects hypothetically, with the option of
committing later. Sort of what a try block would like to be when
it grows up...
Larry
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On 12/12/2002 4:01 PM, Larry Wall wrote:
On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
: And what will:
:
: main.*can('foo')
:
: result in?
These days it's Main, not main. And it's a module, not a class,
so probably it fails, unless someone can think of something useful
for it to mean.
It would, logicaly, mean that the class Module has a method foo if
true -- applying can on an object tells you if the class of that object
can do somthing, and Main is an object of class Module... right?
(%Main:: is a hash, but Main (bareword) is an object, no?)
-=- James Mastros
