Re: Proposal: "is defined" trait, "is typed" trait, "traits" pragma.

[TSa]

HaloO,

Autrijus Tang wrote:

The purpose is that we don't have to be strong typists to enjoy Strong
Typing.  To make Perl6 easier to type, and easier to Type.


Great! You, if not solve, but at least aim at relieving the pain caused
by the 'proliferation of type parameters' problem. Consider me as convinced.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Translating (or at least parsing) Java interface definitions

[Gaal Yahas]

On Mon, Aug 08, 2005 at 10:25:26AM +0100, Tim Bunce wrote:
> Anyone done any work on parsing Java interface definitions?
> 
> And, ideally, translating them into roughly equivalent Perl 6?

I wrote something that did this with Parse::RecDescent. Unfortunately,
I don't own the code.

For my purposes I needed to parse several hundred interface files and
build Perl 5 classes (with hierarchy) on the fly from them. The files
in practice only used a subset of the possible Java syntax available in
an interface, but more than a trivial subset. The grammar (together with
interspersed to buildcode) came out at about 120 lines. It was fast
enough for me after the initial Parse::RecDescent startup hit.

The Java language spec contains a few grammars that helped me.

I found I couldn't use autotree because I can't control the base for
the resulting namespace: I have a patch to Parase::RecDescent somewhere
that fixes that, or you could use Class::Rebless which I wrote initially
because of this problem -- though I ended up doing the blesswork inside
the code sections manually as it made much more algorithmic sense.

Hope this helps.

-- 
Gaal Yahas <[EMAIL PROTECTED]>
http://gaal.livejournal.com/

Typed type variables (my Foo ::x)

[Stuart Cook]

Hi,

What's the current meaning of type annotations on type-variables?

For example, if I say...

my Foo ::x;

...which of these does it mean?

a) ::x (<=) ::Foo (i.e. any type assigned to x must be covariant wrt. Foo)
b) ::x is an object of type Foo, where Foo.does(Class)
c) Something else?

I seem to recall Damian suggesting (a) in order to solve the "what's
the invocant type of a class method" problem[1], but I wasn't sure
whether it was already canon.

Also, can I do crazy stuff like this?

my $a = ::Foo;
my ::$a $obj;  # analogous to @$x, where $x is an arrayref


Thanks,

Stuart


[1] 

Classes as special undefs

[Stuart Cook]

On 11/08/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> I'll have to think about the rest of your proposal, but I was suddenly
> struck with the thought that our "platonic" Class objects are really
> forms of undef:
> 
> say defined IO; # prints 0
> 
> That is, we already have an object of type IO that doesn't really
> have a value yet.  And maybe that's the real difference between the
> class object and the metaclass object.  And maybe we can reason
> about objects of type IO without worrying about the definedness,
> if all classes already include their own personal undef.

Wow, that's crazy enough to actually work!

This approach has a few nice properties:

* It neatly handles the fact that 'platonic' instances only kinda-sorta 
exist by making them undefined.  You can answer hypothetical questions
about instances in general, but as soon as you try to treat undef
as an actual instance of something (rather than just dispatching to
the class) you'll encounter an error.

* Classes don't have to be considered first-class objects (beyond being
the type of certain special undefs); they can be their own kind of 
thing, and if you want to treat them as objects you can just use the
metaclass.

* It puts up quite a clear barrier between the responsibilities of the
class (dispatch class methods and initialisers, but don't actually
/do/ anything) and the metaclass (act as the class's representative
in object-space).

Am I thinking along the same lines as you?


Stuart

Re: Typed type variables (my Foo ::x)

[Autrijus Tang]

On Thu, Aug 11, 2005 at 08:02:00PM +1000, Stuart Cook wrote:
> What's the current meaning of type annotations on type-variables?
> 
> For example, if I say...
> 
> my Foo ::x;
> 
> ...which of these does it mean?
> 
> a) ::x (<=) ::Foo (i.e. any type assigned to x must be covariant wrt. Foo)
> b) ::x is an object of type Foo, where Foo.does(Class)
> c) Something else?

My current reading is a) -- but only if ::x stays implicitly
"is constant".  So your "assigned" above should read "bound".

> Also, can I do crazy stuff like this?
> 
> my $a = ::Foo;
> my ::$a $obj;  # analogous to @$x, where $x is an arrayref

Note that $a at compile time is unbound, so that automatically fails.
Now had you written this:

my $a ::= ::Foo;
my ::$a $obj;

Then I can see it working.

Thanks,
/Autrijus/


pgp1SkCTrbh4L.pgp
Description: PGP signature

Re: Classes as special undefs

[Brent 'Dax' Royal-Gordon]

Stuart Cook <[EMAIL PROTECTED]> wrote:
> On 11/08/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> > I'll have to think about the rest of your proposal, but I was suddenly
> > struck with the thought that our "platonic" Class objects are really
> > forms of undef:
> >
> > say defined IO; # prints 0
> >
> > That is, we already have an object of type IO that doesn't really
> > have a value yet.  And maybe that's the real difference between the
> > class object and the metaclass object.  And maybe we can reason
> > about objects of type IO without worrying about the definedness,
> > if all classes already include their own personal undef.
>
> Wow, that's crazy enough to actually work!
>
> This approach has a few nice properties:

One that you missed was that this syntax:

   my Dog $spot .=new();

Falls out of it quite naturally.

On the other hand, there are other things that don't work quite so well:

   my Dog $spot;
   $spot.can('bark');# Not until he's instantiated...

On the gripping hand, maybe you should have to ask the metaclass about
that anyway:

   $spot.meta.class_can('bark');#No
   $spot.meta.instance_can('bark');#Yes

Hmm.

-- 
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker

Re: Classes as special undefs

[Stuart Cook]

On 11/08/05, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> One that you missed was that this syntax:
> 
>my Dog $spot .=new();
> 
> Falls out of it quite naturally.

Actually I tried to mention that indirectly, but I'm glad you
explicitly mentioned it.

> On the other hand, there are other things that don't work quite so well:
> 
>my Dog $spot;
>$spot.can('bark');# Not until he's instantiated...

Are you objecting to the fact that it can't possibly return a valid
method, or that it will inappropriately true/false (depending on your
point of view)?

> On the gripping hand, maybe you should have to ask the metaclass about
> that anyway:
> 
>$spot.meta.class_can('bark');#No
>$spot.meta.instance_can('bark');#Yes

Yeah, but if we're trying to view (undef but Dog) as the platonic
instance of Dog, it would be nice if told us what the ideal Dog can &
can't do.  (In either case, the metaclass will be able to tell us.) 
Something to ponder, I suppose.


Stuart

Re: Typed type variables (my Foo ::x)

[TSa]

HaloO,

Autrijus Tang wrote:

On Thu, Aug 11, 2005 at 08:02:00PM +1000, Stuart Cook wrote:

   my Foo ::x;
a) ::x (<=) ::Foo (i.e. any type assigned to x must be covariant wrt. Foo)
b) ::x is an object of type Foo, where Foo.does(Class)
c) Something else?


My current reading is a) -- but only if ::x stays implicitly
"is constant".  So your "assigned" above should read "bound".


Same reading here! ::x is declared as a subtype of Foo.

Note that the subtype relation is *not* identical to the
subset relation, though. E.g. Foo (=) (1,2,3) gives
Foo (<=) Int but Foo is not a subtype of Int if Int requires
e.g. closedness under ++. That is forall Int $x the constraint
$t = $x; $x++; $t + 1 == $x must hold. Foo $x = 3 violates
it because 4 is not in Foo. OTOH ++ might not be specialized
on Foo and thus only ++:(Int --> Int) is applied anyway. But
that implies that Foo $x = 3; $x++ warps $x to Int or weird
things like (4 of Int but 3 of Foo) or (4 of Int but 1 of Foo)
when Foo is considered cyclic.



Also, can I do crazy stuff like this?

   my $a = ::Foo;
   my ::$a $obj;  # analogous to @$x, where $x is an arrayref



Note that $a at compile time is unbound, so that automatically fails.
Now had you written this:

my $a ::= ::Foo;
my ::$a $obj;

Then I can see it working.


But wouldn't it be right away optimized to

   my ::Foo $obj;

Same if it comes from a dynamic scope:

   sub foo( ::Foo )
   {
  my $a ::= ::Foo;
  my ::$a $obj;

  return $obj;
   }
   say foo( Str );
   say foo( Int );
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Classes as special undefs

[Autrijus Tang]

On Thu, Aug 11, 2005 at 08:53:47PM +1000, Stuart Cook wrote:
> On 11/08/05, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> > One that you missed was that this syntax:
> > 
> >my Dog $spot .=new();
> > 
> > Falls out of it quite naturally.
> 
> Actually I tried to mention that indirectly, but I'm glad you
> explicitly mentioned it.

What about this?

my $spot = Dog;
defined($spot); # false!?
$spot .= new;   # instantiated?

Thanks,
/Autrijus/


pgpVmHxYvBWWM.pgp
Description: PGP signature

Re: Classes as special undefs

[TSa]

HaloO,

Autrijus Tang wrote:

What about this?


OK, let's play some manual type inferencing ;)



my $spot = Dog;


$spot.does(Item of Dog), that means what ever the name Dog represents
was stored or bound to $spot.


defined($spot); # false!?


true! Even for my $spot = ::Dog because when my is evaluated the
name ::Dog has be be bound, AUTOLOADED or by whatever means become
available.


$spot .= new;   # instantiated?


Why not, a bit weird though to replace the class link with
a fresh instance of same class.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Classes as special undefs

[Autrijus Tang]

On Thu, Aug 11, 2005 at 04:47:49PM +0200, TSa wrote:
> OK, let's play some manual type inferencing ;)

Note that $spot here is intended to be dynamic typed, i.e. not subject
to inference.  :-)

> >my $spot = Dog;
> 
> $spot.does(Item of Dog), that means what ever the name Dog represents
> was stored or bound to $spot.

Right, except $spot can later hold other non-Dog values as well, as it
is dynamically typed by default...

> >defined($spot);  # false!?
> 
> true! Even for my $spot = ::Dog because when my is evaluated the
> name ::Dog has be be bound, AUTOLOADED or by whatever means become
> available.

I agree, with exactly the same logic.  However, Larry somehow thought
that defined(Dog) is false, which should lead defined($spot) is false
as well.  I still can't quite grasp this idea. :)

Thanks,
/Autrijus/


pgpvZJ8eFujzH.pgp
Description: PGP signature

Re: Classes as special undefs

[TSa]

HaloO,

Stuart Cook wrote:

On the other hand, there are other things that don't work quite so well:

  my Dog $spot;
  $spot.can('bark');# Not until he's instantiated...



Are you objecting to the fact that it can't possibly return a valid
method, or that it will inappropriately true/false (depending on your
point of view)?


Might I add my view of affairs? I want to point out the difference
between a slot call and a free method here. Major difference is that
a slot call starts from the $spot sigil expression, determines the
class and looks up .can there and calls it. While a free method .can
is lookup up first in namespace and then $spot has to qualify as an
invocant type. The selected dispatch target has to accept a Str
parameter and is executed in Void context.



Yeah, but if we're trying to view (undef but Dog) as the platonic
instance of Dog,


$Larry very nicely said that the name Dog here represents all
the potentialities with the package/module/class behind it.
I regard this potentiality as type information. That is after
my Dog $spot; the type of $spot is 'Item of Undef of Dog'.


it would be nice if told us what the ideal Dog can &
can't do.  (In either case, the metaclass will be able to tell us.) 
Something to ponder, I suppose.


Proposal: could we call all this META stuff somewhat generically
"Meta Info"? I mean .meta delivers a thingy that .does(Meta) nothing
more nothing less. There are whatever methods defined on that type.
Does that help you pondering?

In more implementation oriented terms .meta returns an opaque pointer
from which other methods can deliver whatever stringy, objectish or
classish information, links or refs. I guess parts of the structures
that this opaque pointer points to are really located on the Parrot
C level or equivalent things in other interpreters supporting Perl6.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Proposal: "is defined" trait, "is typed" trait, "traits" pragma.

[Larry Wall]

On Thu, Aug 11, 2005 at 10:47:35AM +0800, Autrijus Tang wrote:
: Really this is about path of least resistance.  Without inference,
: we are asking the user to choose between:
: 
: 1) Verbose annotation and type safety
: 2) Convenience (no annotation) and unsafe behaviour
: 
: Adding inference ("is typed") to the mix massively sweetens the first
: option, which would be a good thing.

Only if the programmer can be taught to understand the inferences...

: > Do you have a non-trivial application for this in mind?
: 
: Yes.  But I can only show trivial examples:
: 
: use traits ;
: my $test = Test::Builder.new();
: 
: Now, without inferencing (the first line above), $Test would have to be
: dynamically typed (no typechecks possible), essentially forcing the user
: who wants typechecks to write out by hand:
: 
: my Test::Builder $test = Test::Builder.new();

That's why we have:

   my Test::Builder $test .= new();

: This is silly.  Or, take another trivial (but common) example:
: 
: method skip (--> Test::Builder::Test::Skip) {
:   my Test::Builder::Test::Skip $skip = Test::Builder::Test::Skip.new;
:   my Test::Builder::Test::Base::Status $status = $skip.status;
:   $status.do_something; $skip.do_something; # ...
:   return $skip;
: }

my Test::Builder::Test::Skip $skip .= new;

: With inferencing:
: 
: use traits 'typed'; 
: method skip (--> Test::Builder::Test::Skip) {
:   my $skip  .= new;
:   my $status = $skip.status;
:   $status.do_something; $skip.do_something; # ...
:   return $skip;
: }
: 
: Which language do you want to write in? :-)

Probably the first, actually, given the .= shortcut.  It takes *me*
a lot of thought to reproduce in my head what the inferencer is doing
there, and you can't really understand code unless you can play the
same mindgames the computer is playing.  When the computer gets too
smart, it forces anyone of less-than-genius caliber into cargo-cult
programming.  That's what I don't like about type inferencing systems.

And there's something to be said for locating type information near
the "my" declaration for documentation purposes even if it's entirely
redundant.

: > It reminds me a bit to the 'bind a variable once in the constraint
: > store' of the constraint programming paradigma.
: 
: No, I didn't have that in mind; I think it's just local type inferences.
: 
: > But there it serves as guiding the control flow. What is the purpose
: > in a typed, imperative language as Perl6?
: 
: The purpose is that we don't have to be strong typists to enjoy Strong
: Typing.  To make Perl6 easier to type, and easier to Type.

Sure, but you're kinda smart, so you can just remember what you've
typed and/or Typed.  Stupid people also have to worry about reading
the code.  :-)

Actually, this is a case where a declared return variable would reduce
my cognitive load since I don't have to scan for a return statement
to see that $skip is in fact the return value:

use traits 'typed'; 
method skip (--> Test::Builder::Test::Skip $skip) {
$skip .= new;
my $status = $skip.status;
$status.do_something; $skip.do_something; # ...
}

Arguably that's just locating the type near the "my" again, though the
"my" is implicit in the signature in this case.

Larry

Re: Classes as special undefs

[Larry Wall]

On Thu, Aug 11, 2005 at 04:47:49PM +0200, TSa wrote:
: >defined($spot);  # false!?
: 
: true! Even for my $spot = ::Dog because when my is evaluated the
: name ::Dog has be be bound, AUTOLOADED or by whatever means become
: available.

What does binding have to do with definedness?  In Perl 6 the object
itself decides if it's defined regardless of how or where it's bound.
That's how we get interesting values of undef.  The recent proposal
only tweaks that idea to unify typed undefs with interesting undefs
so that an unthrown exception can also be an abstract (albeit
unsuccessful) IO or Dog or whatever, so that you don't have to play
games with junctions to get undef into typed variables.  In other
words, $spot is not successful, but that can be either because we
tried and failed, or because we haven't tried yet.  That's the
unification I'm looking at.

Larry

Re: Proposal: "is defined" trait, "is typed" trait, "traits" pragma.

[Autrijus Tang]

On Thu, Aug 11, 2005 at 09:22:27AM -0700, Larry Wall wrote:
> On Thu, Aug 11, 2005 at 10:47:35AM +0800, Autrijus Tang wrote:
> : Adding inference ("is typed") to the mix massively sweetens the first
> : option, which would be a good thing.
> 
> Only if the programmer can be taught to understand the inferences...

Aye.  That is a very good argument for "is typed" to be off by default,
which I fully concur. :)

> Probably the first, actually, given the .= shortcut.  It takes *me*
> a lot of thought to reproduce in my head what the inferencer is doing
> there, and you can't really understand code unless you can play the
> same mindgames the computer is playing.  When the computer gets too
> smart, it forces anyone of less-than-genius caliber into cargo-cult
> programming.  That's what I don't like about type inferencing systems.

Indeed, but I expect Perl6 programmers start rapid-prodotyping in the
dynamic variant of Perl6, so the inferencing does not kick in anyway.

However, once a programmer starts using type annotations, rapidly the
compiler will (rightfully) complain about unsafe coercing.  That would
force the programmer into another kind of cargo-cult programming,
rampant in the Java world, namely manually key-in type declarations
everywhere.

Also, it is common in inference-based language environment to tell you
the inferred type for expressions, in a way that can be copy-and-pasted
back to the program, instead of having to type them out by hand.

Something like this:

pugs> sub fact ($x) is typed { [*] 1..$x }
pugs> :t &fact
sub fact (Int $x --> Int)

> And there's something to be said for locating type information near
> the "my" declaration for documentation purposes even if it's entirely
> redundant.

That is true.

> Actually, this is a case where a declared return variable would reduce
> my cognitive load since I don't have to scan for a return statement
> to see that $skip is in fact the return value:
> 
> use traits 'typed'; 
> method skip (--> Test::Builder::Test::Skip $skip) {
>   $skip .= new;
>   my $status = $skip.status;
>   $status.do_something; $skip.do_something; # ...
> }
> 
> Arguably that's just locating the type near the "my" again, though the
> "my" is implicit in the signature in this case.

Yes, I think that form would rock.  Also, I think leaving off the
Test::Builder::Test::Base::Status from the $status declaration does
not harm its documentation value -- indeed, that's the DWIM form Perl
programmers are used to.

Thanks,
/Autrijus/


pgpx3ztVyRQVk.pgp
Description: PGP signature

Re: my $pi is constant = 3;

[Autrijus Tang]

On Wed, Aug 10, 2005 at 12:41:17PM -0700, Larry Wall wrote:
> : If yes, what does it desugar to?
> : 
> : my $pi is constant := 3;
> : my $pi is constant ::= 3;
> 
> In this case it desugars to
> 
> my $pi is constant = 3;
> 
> :-)

However, I wonder if the intention was to replace the Perl 5 form of:

use constant PI => 3;

Which is a binding that happens at compile time.  It'd be somewhat
strange if this dies with undef -- or even 'Str':

my Str $x is constant = 'foo';
BEGIN { die $x };

Or do you think that people should really write ::= for constants?

Thanks,
/Autrijus/


pgpAmjBsOMSlo.pgp
Description: PGP signature

Re: my $pi is constant = 3;

[Larry Wall]

On Fri, Aug 12, 2005 at 01:43:43AM +0800, Autrijus Tang wrote:
: On Wed, Aug 10, 2005 at 12:41:17PM -0700, Larry Wall wrote:
: > : If yes, what does it desugar to?
: > : 
: > : my $pi is constant := 3;
: > : my $pi is constant ::= 3;
: > 
: > In this case it desugars to
: > 
: > my $pi is constant = 3;
: > 
: > :-)
: 
: However, I wonder if the intention was to replace the Perl 5 form of:
: 
: use constant PI => 3;
: 
: Which is a binding that happens at compile time.  It'd be somewhat
: strange if this dies with undef -- or even 'Str':
: 
: my Str $x is constant = 'foo';
: BEGIN { die $x };
: 
: Or do you think that people should really write ::= for constants?

Hmm, well, we do need some form that is only temporarily constant for
this time through the elaboration and subsequent code.  That is the
sense of "constant" we're applying formal parameters, after all.

So either we have to bifurcate the concept into "temporarily constant"
and "permanently constant", or we force people to distinguish with ::=
(or "is constant('foo')"), or we make some representations about the
requirement for the compiler to optimize the = form to:

my Str $x is constant('foo');

if the assigned value is "static" (much as we require the tailcall
optimization these days).  So this would be another instance of
making the default semantics late binding, but optimized to earlier
binding in cases where it makes no semantic difference other than a
difference in run-time efficiency.  Making this determination is
pretty much equivalent to constant folding.

Larry

Re: Typed type variables (my Foo ::x)

[Luke Palmer]

On 8/11/05, TSa <[EMAIL PROTECTED]> wrote:
> HaloO,
> 
> Autrijus Tang wrote:
> > On Thu, Aug 11, 2005 at 08:02:00PM +1000, Stuart Cook wrote:
> >>my Foo ::x;
> >>a) ::x (<=) ::Foo (i.e. any type assigned to x must be covariant wrt. Foo)
> >>b) ::x is an object of type Foo, where Foo.does(Class)
> >>c) Something else?
> >
> > My current reading is a) -- but only if ::x stays implicitly
> > "is constant".  So your "assigned" above should read "bound".
> 
> Same reading here! ::x is declared as a subtype of Foo.
> 
> Note that the subtype relation is *not* identical to the
> subset relation, though. E.g. Foo (=) (1,2,3) gives
> Foo (<=) Int but Foo is not a subtype of Int if Int requires
> e.g. closedness under ++. That is forall Int $x the constraint
> $t = $x; $x++; $t + 1 == $x must hold. Foo $x = 3 violates
> it because 4 is not in Foo. 

That's perfectly okay.  The following is a valid subtype in Perl:

subtype Odd of Int where { $_ % 2 == 1 };

Even though it doesn't obey the algebraic properties of Int.

The way to state algebraic properties of a type is the same way as in
Haskell: use type classes.

macro instance (Type $type, Role $class) {
$type does $role; ""
}

role Addable[::T] {
multi sub infix:<+> (T, T --> T) {...}
}

instance Addable[Int], Int;

This would require the definition of a "multi sub infix:<+> (Int, Int
--> Int)", thus declaring that Ints are closed under addition. 
However, the subtype Odd above also does Addable, but it does
Addable[Int], not Addable[Odd].  That means that you can add two Odds
together and all you're guaranteed to get back is an Int.

Hmm, if we can have K&R C-style where clauses on subs, then we can
constrain certain parameters in the signature.  For instance:

sub foo ($x, $y)
where Int $x
where Int $y
{...}

Using this style, we can constrain types as well:

sub foo (T $x, T $y)
where Addable[T] ::T
{...}

foo is now only valid on two types that are closed under addition.

Notationally this has a few problems.  First, you introduce the
variable ::T after you use it, which is parserly and cognitively
confusing.  Second, you say T twice.  Third, there is a conflict in
the returns clause:

sub foo ($x) returns Int
where Int $x
{...}

The where there could go with Int as a subtype or with foo as a constraint.

Luke

Re: $object.meta.isa(?) redux

[Luke Palmer]

On 8/10/05, Sam Vilain <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-10 at 21:00 -0400, Joe Gottman wrote:
> >Will there be an operator for symmetric difference?  I nominate (^).
> 
> That makes sense, although bear in mind that the existing Set module for
> Perl 6, and the Set::Scalar and Set::Object modules for Perl 5 use % for
> this (largely due to overloading restrictions, of course).
> 
> There is no unicode or mathematical operator for symmetric difference,
> it seems.

I usually see infix delta (which probably comes from /\, where \ is
set difference).  That makes (^) seem all the sweeter, since it kinda
looks like a delta.  But then maybe we should make set difference (\).

Luke

Re: "set" questions -- Re: $object.meta.isa(?) redux

[Luke Palmer]

On 8/10/05, Flavio S. Glock <[EMAIL PROTECTED]> wrote:
> I wonder if infinite sets (recurrences) will be supported - then I'll
> move all(ext/Recurrence, ext/Span, ext/Set-Infinite) to
> Perl6::Container::Set::Ordered - cool.

Note "there is now a Set role".   Emphasis on role.  There will be a
finite set class to go with it, but really these operators just
specify an interface (and a few default implementations when they can
be inferred).  You can implement whatever you like that implements
this interface.

You might not want to call it a container, since it's not a container.

Luke

> - Flavio S. Glock
> 
> 2005/8/10, Dave Whipp <[EMAIL PROTECTED]>:
> > Luke Palmer wrote:
> >
> > > A new development in perl 6 land that will make some folks very happy.
> > >  There is now a Set role.  Among its operations are (including
> > > parentheses):
>

Re: Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]

[Luke Palmer]

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]

[Mark A. Biggar]

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]

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: my $pi is constant = 3;

[Ashley Winters]

On 8/11/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> So either we have to bifurcate the concept into "temporarily constant"
> and "permanently constant", or we force people to distinguish with ::=
> (or "is constant('foo')"), or we make some representations about the
> requirement for the compiler to optimize the = form to:
> 
> my Str $x is constant('foo');

Why isn't the late binding version

my Str $x is ro('foo');

In contrast to the 'is rw' trait? When I say 'is constant', can I be
rewarded for all my extra typing with some well-defined compile-time
optimization?

Ashley Winters

Re: Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]

[Larry Wall]

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