Strongly typed containers?

5 views
Skip to first unread message

Yuval Kogman

unread,
May 30, 2005, 10:11:12 AM5/30/05
to perl6-l...@perl.org
We already have the Set class, how do we say what it contains?

class Set {
has $.type;

submethod BUILD {
# get something into $.type, using 'of' handler
}

method members returns $.type () { ... }
}

my Set of Int $s = Set.new; # is this how you call it?

Or do we say

class Set is Container { # magical?
method members returns returns ... # some facility by Container?
}

Even if the way to implement this is as thin as C++ templates, that
is, we'll have to define a container of some type, and define the
type as a complex thing, instead of defining a container of complex
things, it's still better than nothing.

This brings me to another issue - can I say what type the elements
of a list has, without putting it into a typed array?

--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me whallops greyface with a fnord: neeyah!!!!!!!

Yuval Kogman

unread,
May 30, 2005, 4:18:10 PM5/30/05
to TSa (Thomas Sandlaß), perl6-l...@perl.org
On Mon, May 30, 2005 at 18:51:19 +0200, "TSa (Thomas Sandla)" wrote:

> class Set does Array {...}

I don't like this... A set is just a simple example... What if I
want something sillier?

My question is really:

"How do I make sub foo returns $computable"

And how do I make this friendly to the compiler (declarable), so
that type inferrence like behavior can be enforced

> and use the corresponding sigil for variables:
>
> my @a is Set;

This works with your example, but it makes more sense if it's only a
derefernce-overload op.

A set and an array are distinct.. Sets are unordered, arrays are
ordered by definition. Sets know how to do set ops on each other,
arrays don't...

This becomes very problematic when you have several methods for
extraction - how do you distinct a method that returns the contained
type from another? An array can only be flattenned to a list, and
have subscripts extracted.... Other extractions are generic to list
data (grep, etc), and do not apply to things like Sets.

> My guess is that there is a Parrot level class that implements
> the level of indirection needed by Perl6 sigiled variables. If
> it weren't for Perl5 referential legacy it could easily be called
> Ref.

Please explain this idea in more detail.

>
> This container base class might just implement the basic machinery needed
> to make your Set available as container. But once again I don't know
> about the mapping to sigils and the set of supported operations.

STL (C++) has some nice ideas, if you consider templates and so
forth nice. In perl 6 I wouldn't like to see that, because it would
hinder flexibility, but basically what you do there is

typedef map <key_type, Foo> FooMap; // garbage fields omitted

And then your FooMap is usable as a container of Foos. But since we
have dynamic runtime things, and much more complicated operations
with mixins, roles, MMD, and we're still trying to optimize all of
these (or rather expose the data to help parrot optimize it for us),
and more importantly help those who want safe programs (or safe
parts of programs) with a little more effort get that.

This is a hard conflict to deal with.

What we need to define is the possibility that a declaration:

my Set of Foo $set;

Affects the 'returns' trait of some methods

$set.members; # we now know it's Foo, because that's what $set is `of`

Aye?

> Hmm, the usual thing the implementation of a container requires
> is a minimal interface needed from the elements for the container
> to do what it is supposed to do.

You mean like generic methods for a container?

> In the case of a set this requirement is to check the identity of
> elements---basically like the keys of hashes.

True, but there are more complicated containers out there... =)

> Well, I think there are the concrete list types Eager and Lazy,
> so it could be a simple 'Lazy of Int'. In a signature you use the
> slurpiness indicator * which I presume is available in :() as well.
> So a list of Int might be :(*Int) and a recurring tuple type might
> be :(*(Int,Str)).

That seems pretty nice, although not aesthetically appealing.

Sam Vilain

unread,
May 30, 2005, 10:23:03 PM5/30/05
to Yuval Kogman, perl6-l...@perl.org
Yuval Kogman wrote:
> We already have the Set class, how do we say what it contains?
> class Set {
> has $.type;
> method members returns $.type () { ... }
> }
> my Set of Int $s = Set.new; # is this how you call it?

You are describing "Higher Order" types, also called Generic Algebraic Data Types (GADTs) in Haskell.

Please refer to the earlier discussions

Parts 1 and 2 of http://xrl.us/f9re

I also started a similar post on a related note that was "warnocked", though the post was more to demonstrate an apparent syntax
isomorphism between Haskell and Perl 6 than posing a particular question (probably why it was unanswered).

http://xrl.us/f9rg

I think there has probably been other discussions, including one where Autrijus specifically asked this question for the Set module,
but I can't find that one.

Sam.

Reply all
Reply to author
Forward
0 new messages