Re: Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]
HaloO Larry,
you wrote:
: we need only provide an alternate comparison to
: the constructor, and the set itself needn't remember it. On the
: other hand, hashes behaving like mutable sets need to remember their
: comparison operator if it is not the default.
:
: The slot accessor paradigma again...
: Isn't the comparator a free method subtype? Why interfering
: at construction time?
I haven't the foggiest idea what you are asking, but here are some
random answers.
Trying to lift the fog ;)
My point is to distinguish between on-board methods and self-contained,
free methods that are not stored or referenced through a vtable
or similar device from every object. Since slots are a metaphor on the
smallest part of an object I call these method invocations slot calls.
The syntactical destinction as pair juxtaposition $obj:action() is an
idea to make it more obvious that :action is firstly retrieved from
$obj somehow and then invoked by applying .() while $obj.action() looks
up .action and then dispatches according to the type of $obj.
A Comparator would be a free method. As such it defines a meaning and
users can hook in more implementations for certain types. In this approach
the method information is needed at compile time before the search of
syntactical invocant expressions starts. E.g. '.foo' needs the invocant to
the left or from some standard variable if there is nothing syntactically.
We don't want to force everyone to specify it every time, because defaults
are friendly.
So you want to install a Comparator into a Hash instance that is used
for *all* contained values? Or for enforcing unique keys? Or are you
talking about a Comparator that is to be used when the hash is compared
to a set value? But that would be the Method subtype Comparator[Hash,Set]
anyway.
Whose construction time? The hash's? Because that's when you'd want
to override the default.
Or are you just carping that you don't believe in OO-ness? The whole
point of OO is that objects have state.
Yes, of course. I think it's more likely that I don't understand why
Perlkind is so obsessed with the container versus value distinction
on the language level. The only importance I see in this is that objects
are heavy-weight and as such recommend handling per reference and in-place
mutation. The latter is carried out at some level through slot calls
provided by the object itself. But more generic concepts are provided
through free methods where class implementors can hook into. If this
hooking shall happen on a larger scale than single methods, roles can
be used to compose classes.
With
my $set = set(1,2,3); # correct syntax?
my %hash = { 1 = true, 2 = true, 3 = true };
questions like
if %hash eqv $set {...}
if 3 (in) $set {...}
if %hash3 {...}
have to be compiled to an actual test if the only thing you know
is that their result type is bool. If the compile time knowledge
is more specific---either true or false---then the test can be
skipped. E.g.
if 3 (in) set(1,2,3) { say 42; }
is just a verbose form of
say 42;
Ohh, perhaps you were talking about inhomogenious cases like
my $set = set(1,'2',Dog.new);
my %hash = { 1 = true, '2' = true, Dod.new = true };
such that you could force e.g. stringified comparison for
if $set eqv %hash {...}
If one of those answers doesn't suit, please feel free to make up another. :-)
Another question or another answer?
--
$TSa.greeting := HaloO; # mind the echo!
Re: Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]
HaloO, Larry Wall wrote: [..] but since sets are immutable values, Does that imply they travel in $vars and are a subtype of Value? Is Undef of Set the Set::Empty? Is Set::Empty false? we need only provide an alternate comparison to the constructor, and the set itself needn't remember it. On the other hand, hashes behaving like mutable sets need to remember their comparison operator if it is not the default. The slot accessor paradigma again... Isn't the comparator a free method subtype? Why interfering at construction time? -- $TSa.greeting := HaloO; # mind the echo!
Re: Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]
On Fri, Aug 12, 2005 at 04:30:09PM +0200, TSa wrote: : HaloO, : : Larry Wall wrote: : [..] but since sets are : immutable values, : : Does that imply they travel in $vars and are a subtype : of Value? I believe so. : Is Undef of Set the Set::Empty? I don't think so. The empty set should probably be considered a defined value. : Is Set::Empty false? Presumably that would be useful. : we need only provide an alternate comparison to : the constructor, and the set itself needn't remember it. On the : other hand, hashes behaving like mutable sets need to remember their : comparison operator if it is not the default. : : The slot accessor paradigma again... : Isn't the comparator a free method subtype? Why interfering : at construction time? I haven't the foggiest idea what you are asking, but here are some random answers. We don't want to force everyone to specify it every time, because defaults are friendly. Whose construction time? The hash's? Because that's when you'd want to override the default. Or are you just carping that you don't believe in OO-ness? The whole point of OO is that objects have state. If one of those answers doesn't suit, please feel free to make up another. :-) Larry
Re: Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]
On 8/10/05, Dave Rolsky [EMAIL PROTECTED] wrote: [changing the subject line for the benefit of the summarizer ...] On Wed, 10 Aug 2005, Larry Wall wrote: And now some people will begin to wonder how ugly set values will look. We should also tell them that lists (and possibly any-junctions) promote to sets in set context, so that the usual way to write a set of numbers and strings can simply be 1 dog 42 cat 666.5 Groovy, but what about this? 1 dog 42 cat 42 Maybe a warning with an optional fatality under use strict 'sets'? I doubt that should be any kind of warning or error. It's just that your set will end up having four elements instead of five. But you really don't want to warn in this case: @myset (+) 1; By using the (+) operator (instead of the list concatenation, er, operator?), the user is implying that he wants duplicates in @myset thrown away. Luke
Re: Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]
Luke Palmer wrote: On 8/10/05, Dave Rolsky [EMAIL PROTECTED] wrote: [changing the subject line for the benefit of the summarizer ...] On Wed, 10 Aug 2005, Larry Wall wrote: And now some people will begin to wonder how ugly set values will look. We should also tell them that lists (and possibly any-junctions) promote to sets in set context, so that the usual way to write a set of numbers and strings can simply be 1 dog 42 cat 666.5 Groovy, but what about this? 1 dog 42 cat 42 Maybe a warning with an optional fatality under use strict 'sets'? I doubt that should be any kind of warning or error. It's just that your set will end up having four elements instead of five. But you really don't want to warn in this case: @myset (+) 1; By using the (+) operator (instead of the list concatenation, er, operator?), the user is implying that he wants duplicates in @myset thrown away. Small issue, what comparison operator do you use to determine duplicates? For example (possibly pathological case): (undef but true) (+) (undef but false) -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]
Mark A. Biggar wrote: Luke Palmer wrote: On 8/10/05, Dave Rolsky [EMAIL PROTECTED] wrote: [changing the subject line for the benefit of the summarizer ...] On Wed, 10 Aug 2005, Larry Wall wrote: And now some people will begin to wonder how ugly set values will look. We should also tell them that lists (and possibly any-junctions) promote to sets in set context, so that the usual way to write a set of numbers and strings can simply be 1 dog 42 cat 666.5 Groovy, but what about this? 1 dog 42 cat 42 Maybe a warning with an optional fatality under use strict 'sets'? I doubt that should be any kind of warning or error. It's just that your set will end up having four elements instead of five. But you really don't want to warn in this case: @myset (+) 1; By using the (+) operator (instead of the list concatenation, er, operator?), the user is implying that he wants duplicates in @myset thrown away. Small issue, what comparison operator do you use to determine duplicates? For example (possibly pathological case): (undef but true) (+) (undef but false) Actually, I'm going to make a stab at answering this myself. The obvious answer is that you use the magic operator ~~ by default just like for a case statement. But there does need to be some way to change that when necessary. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]
On Thu, Aug 11, 2005 at 08:25:23PM -0700, Mark A. Biggar wrote: : Mark A. Biggar wrote: : Small issue, what comparison operator do you use to determine : duplicates? For example (possibly pathological case): : : (undef but true) (+) (undef but false) : : Actually, I'm going to make a stab at answering this myself. The : obvious answer is that you use the magic operator ~~ by default just : like for a case statement. But there does need to be some way to change : that when necessary. We talked about that some in Portland. We figured ~~ was probably too dwimmy to serve that purpose, and that what we really needed was the same comparison that will have to be used for hashes that are allowed to contain objects, but also want to store values as values. Essentially immutable values want to compare as values but mutable objects by reference as individual entities. At the moment we're calling that operator eqv, short for both equivalent and equal value. It does need to be possible to change that, but since sets are immutable values, we need only provide an alternate comparison to the constructor, and the set itself needn't remember it. On the other hand, hashes behaving like mutable sets need to remember their comparison operator if it is not the default. Larry
