specifying the key Type for a Hash

[Abhijit Mahabal]

A6 included examples of syntax for specifying the type of the key for a
hash:

my %pet is Hash(keytype => Str, returns => Cat)

None of the synopses have anything like this. S6 talks about the
types of values, but not keys. Oversight, or is this syntax dead?

--abhijit

Abhijit Mahabal http://www.cs.indiana.edu/~amahabal/

[Larry Wall]

On Fri, Dec 03, 2004 at 05:23:56PM -0500, Abhijit Mahabal wrote:
: A6 included examples of syntax for specifying the type of the key for a

: hash:
:
: my %pet is Hash(keytype => Str, returns => Cat)
:
: None of the synopses have anything like this. S6 talks about the
: types of values, but not keys. Oversight, or is this syntax dead?

S9 talk about it. We current have things like:

my Cat %pet is shape(Str);

and parameters to types are in square brackets, so it's more like:

my %pet is Hash[:shape(Str) :returns(Cat)];

Larry

[Abhijit Mahabal]

On Fri, 3 Dec 2004, Larry Wall wrote:
> : None of the synopses have anything like this. S6 talks about the
> : types of values, but not keys. Oversight, or is this syntax dead?
>
> S9 talk about it.

Oops. Sorry. So it was oversight after all :)

[David Green]

In article <20041203230...@wall.org>,

la...@wall.org (Larry Wall) wrote:
>S9 talk about it. We current have things like:
> my Cat %pet is shape(Str);
>and parameters to types are in square brackets, so it's more like:
> my %pet is Hash[:shape(Str) :returns(Cat)];

I still prefer "shaped", for pronounceability. Although "shape" is a
bit of a stretch for something that's really more like "size", and even
stretchier for describing hash keys. I'm not sure what better word we
could use, though.

is built # a constructive choice
is determined # good for typing practice =P
is bound # what if you're bound AND determined?
is disposed # sounds like a destructor
is composed # I kinda like this one
is arrayed # oh, "array" in that other sense
is reckoned # bet no other language has that as a keyword
is cinched # it sounds so easy
is confined # to quarters
is walled # now we're just being silly (no offense to Larry)
is earmarked # some people wouldn't hear of it
is indexed # a bit better than "is keyed" (especially if it's your car)
is sized # I think this was already rejected
is like # works really well if your type happens to be 'Totally'
is thus # very vague, but short

Hm.

On the other hand, imagining Type-shaped holes into which your hash
keys fit *does* have a rather picturesque appeal...

-David "the thesaurus is your friend (sometimes)" Green

[Larry Wall]

On Sat, Dec 04, 2004 at 08:01:46AM -0700, David Green wrote:
: In article <20041203230...@wall.org>,

: la...@wall.org (Larry Wall) wrote:
: >S9 talk about it. We current have things like:
: > my Cat %pet is shape(Str);
: >and parameters to types are in square brackets, so it's more like:
: > my %pet is Hash[:shape(Str) :returns(Cat)];
:
: I still prefer "shaped", for pronounceability.

To me that implies a process of shaping, which isn't necessarily a
connotation I want in a declaration.

In English we actually say it "has a" shape, but I don't think we
dare change it to "has shape". Semantically it's more like "does",
since the parameters of the shape "role" select a set of valid
multimethods for the object to handle, some of which are disguised
as subscripting operations. In fact, it's arguable that the parameter
should be in square brackets like any other type parameter:

my Cat %pet does key[Str];

'Course, that makes me wonder then if we can make

my Cat %pet does key{Str};

work. Maybe type parameters are just subscripts? Then we can have
the brackets on the shape be the same as the brackets on the subscript,
and it's only natural that multiple dimensions would be separated
with semicolon:

my Fight %fight does key{Dog;Cat};

But if English-like is the criterion that'd still read better as

my Fight %fight has key{Dog;Cat};

And now I'm wondering if we can do any role with "has".

class Array has Iterator {...}

$myobj has MyProperty;

That would mean, however, that both the human and the computer would have
to glance ahead to see what it is we're composing. Currently we know
that "has" is composing an attribute, while "does" is composing a role.
Maybe we can confuse those without confusing people. And confusing it
with "is" is even worse, since roles are supposed to be well-behaved,
while traits can be traitorous.

So I guess we're back to "is shape". :-)

Of course, the moment I turn around, someone will define a "has"
multimethod that just translates to "does" if the argument is
a role. Maybe "has" and "does" are just synonyms, and you can use
whatever makes more grammatical sense. But pretty much every time
I've introduced synonyms into Perl I've come to regret it. But hey,
if I introduce *different* synonyms this time, does that count as
making a new mistake?

: Although "shape" is a

: bit of a stretch for something that's really more like "size", and even
: stretchier for describing hash keys. I'm not sure what better word we
: could use, though.
:
: is built # a constructive choice
: is determined # good for typing practice =P
: is bound # what if you're bound AND determined?
: is disposed # sounds like a destructor
: is composed # I kinda like this one
: is arrayed # oh, "array" in that other sense
: is reckoned # bet no other language has that as a keyword
: is cinched # it sounds so easy
: is confined # to quarters
: is walled # now we're just being silly (no offense to Larry)
: is earmarked # some people wouldn't hear of it
: is indexed # a bit better than "is keyed" (especially if it's your car)
: is sized # I think this was already rejected
: is like # works really well if your type happens to be 'Totally'
: is thus # very vague, but short

The problem with a thesaurus is that it only gives you synonyms, not the
word you really want. :-)

: Hm.

Well, there's always "domain" and "range", if we want to be mathematical.

Or we we wanted to be NASAesque, they'd be FATs, for Formal Argument Types.

: On the other hand, imagining Type-shaped holes into which your hash

: keys fit *does* have a rather picturesque appeal...

Well, I just put "is shape" because that's what the PDLers settled on,
but as far as I'm concerned linguistically, it could just be "is dim".
That would settle the "make-it-like-English" question by making it
not at all like English.

On the aesthetic hand, "shape" is a much prettier word than "dim".

Larry

[David Wheeler]

On Dec 4, 2004, at 10:57 AM, Larry Wall wrote:

> Well, I just put "is shape" because that's what the PDLers settled on,
> but as far as I'm concerned linguistically, it could just be "is dim".
> That would settle the "make-it-like-English" question by making it
> not at all like English.
>
> On the aesthetic hand, "shape" is a much prettier word than "dim".

Yes, to me, "dim" means "not bright", as in dumb.

Cheers,

David

[Smylers]

Larry Wall writes:

> But pretty much every time I've introduced synonyms into Perl I've
> come to regret it. But hey, if I introduce *different* synonyms this
> time, does that count as making a new mistake?

No! Avoid synonyms. They're initially tempting, because then everybody
gets to pick the one he/she wants to use, but then it turns out you need
to learn all of them so as to read other people's code, and that's worse
than not having them at all. 'MySQL' is riddled with them, and they're
most inconvenient!

Smylers

[Nigel Sandever]

I probably missed teh comprehensive dismissal thread, but why not 'type'?

my %pet is Hash[:type(Str) :returns(Cat)];

njs

[David Green]

In article <slrncr73it....@stripey.com>,
Smy...@stripey.com (Smylers) wrote:

>No! Avoid synonyms. They're initially tempting, because then everybody
>gets to pick the one he/she wants to use, but then it turns out you need
>to learn all of them so as to read other people's code, and that's worse
>than not having them at all.

In one way I agree, but I think there's a better (right!) way to use
synonyms. In natural language, you don't use a synonym to avoid
learning some other word; you learn both and choose whichever one has
the more appropriate connotations, the more suitable flavour under
the given circumstances. (Computers care only about denotations, so
typical computer languages don't bother with synonyms, but that's one
of the reasons why Perl has a better flavour than your typical
language.)

Perl already has lots of synonyms, really: "zip" and "･", "or" and "||",
"unless" and "if not". Nobody learns <= *instead* of > -- you expect
everyone to be familiar with both, and use whichever one reads better
in its particular context. So some synonyms (perhaps like "has" for
"is") I'm all for: people would use both on a regular basis and I don't
see any problem with that.

On the other hand, I do think your point applies to things like, say,
suggesting "put" as a synonym for "unshift". The only reason to do
that is not to have to use "unshift" at all, but you have to know it
anyway because if it's available, you're going to run into it sooner
or later.

- David "a rose by any other name would parse as sweet" Green

[David Green]

In article <20041204185...@wall.org>,
la...@wall.org (Larry Wall) wrote:
>Maybe type parameters are just subscripts? [...]

> my Fight %fight does key{Dog;Cat};

I like that.

>But if English-like is the criterion that'd still read better as
> my Fight %fight has key{Dog;Cat};

I like that even better.

>Maybe "has" and "does" are just synonyms, and you can use
>whatever makes more grammatical sense. But pretty much every time
>I've introduced synonyms into Perl I've come to regret it. But hey,
>if I introduce *different* synonyms this time, does that count as
>making a new mistake?

=) Isn't "synonym" just Greek for TMTOWTDI?

To me, role-"has" seems different enough from attribute-"has" that
the context would make it pretty clear which was meant. (But maybe
I'm just missing something subtle. Or else something blatant.)

>The problem with a thesaurus is that it only gives you synonyms, not the
>word you really want. :-)

Heh. Sometimes I know the word I want, I just don't know I know it
until the thesaurus reminds me. And the rest of the time I just like
looking through all the words. As often as not, something on the
opposite page catches my eye and I end up forgetting what I was
looking for in the first place.

>Well, there's always "domain" and "range", if we want to be mathematical.

I'm happy with those too (perhaps because I do want to be a bit
mathematical).

>Or we we wanted to be NASAesque, they'd be FATs, for Formal Argument Types.

"is FAT"? Yeah, that works for me too. =)

>Well, I just put "is shape" because that's what the PDLers settled on,
>but as far as I'm concerned linguistically, it could just be "is dim".
>That would settle the "make-it-like-English" question by making it
>not at all like English.
>On the aesthetic hand, "shape" is a much prettier word than "dim".

I would take that as an abbreviation and read it as "is dimensioned",
which is English-like enough for me. It's also short. And I don't
mind calling it dim, because if it were so smart, I wouldn't have to
tell it what to do in the first place. But "shape" *is* prettier.

-David "pondering the shape of things to come" Green

[Luke Palmer]

David Green writes:
> In article <20041204185...@wall.org>,
> la...@wall.org (Larry Wall) wrote:
> >Maybe type parameters are just subscripts? [...]
> > my Fight %fight does key{Dog;Cat};
>
> I like that.

Yeah, me too. Except I'm having trouble seeing how key is a role. It's
not adding anything into a hash; it's changing it. Maybe I just don't
quite grok roles yet.

>
> >But if English-like is the criterion that'd still read better as
> > my Fight %fight has key{Dog;Cat};
>
> I like that even better.
>
> >Maybe "has" and "does" are just synonyms, and you can use
> >whatever makes more grammatical sense. But pretty much every time
> >I've introduced synonyms into Perl I've come to regret it. But hey,
> >if I introduce *different* synonyms this time, does that count as
> >making a new mistake?

Yeah, that's true. But, on the other hand, "has" seems to have quite a
lot to do with roles:

class Foo {
has $.bar; # compose in a .bar() method
}

Then you can think of a class as an elementary decomposition of roles.
That's algebralicious. (And its one of those things I can imagine not
seeing the potential in until someone does something Profound with it).

> >Well, there's always "domain" and "range", if we want to be
> >mathematical.
>
> I'm happy with those too (perhaps because I do want to be a bit
> mathematical).

Remember what happened last time you gave something a mathematical name
that was wrong? Yeah, vector ops. And then everyone (read: me) carped
about them not being vector anything.

What you want here is "domain" and "codomain". Which leads me to
believe that you don't want either.

Luke

[Larry Wall]

On Mon, Dec 06, 2004 at 05:43:16AM +0000, Nigel Sandever wrote:
: I probably missed teh comprehensive dismissal thread, but why not 'type'?

:
: my %pet is Hash[:type(Str) :returns(Cat)];

Well, "type" is just a little off in a couple of ways. On the one hand,
it's not specific enough, insofar as there are several different
types involved. On the other hand, it's too specific, insofar as what
you're specifying there is not a type, but something more like a signature,
albeit one without parameters. It's more like the attachment on a
multi to pick one of a set: &abs<complex>.

That says to me that what we're really looking at is

my Cat %pet is sig(Str);
my @matrix is sig(int where 0..3, int where 0..3);

where those might be abbreviated as:

my Cat %pet (Str);
my %matrix (3,3);

or

my Cat %pet .{Str};
my %matrix .[3;3];

or maybe even

my Cat %pet{Str};
my %matrix[3;3];

Which says that

my sub foo ($a) {...}

is maybe short for

my sub foo .($a) {...}

Hmm. Also says maybe you could attach a block to a hash or array to
define what subscripting does. Hmm.

Larry

[arcadi]

This _is_ really interesting!!

[Abhijit Mahabal]

On Mon, 6 Dec 2004, Larry Wall wrote:

> Hmm. Also says maybe you could attach a block to a hash or array to
> define what subscripting does. Hmm.

That's tantalizing. Did you have something like this in mind:

# Count number of accesses to each key
our %counter_hash;
my %hash is subscripted
-> $subscript { %counter_hash{$subscript}++; %hash{$subscript} };

Or even:

# Provide a "view" of the hash
my %hash is subscripted
-> $address { %hash{address_to_zipcode($address)}};

so that users can think that they are accessing %hash{"Bloomington, IN"}
when they are really accessing %hash{47401}.

Or scarier, using MMD-like stuff (I am not even thinking about syntax) we
get different things based on the signature of the key, giving us the
ability to differentiate between %hash{$Dog} or %hash{$Vet}.

And pretty soon somebody will define an accessor for the signature
(SQL_Query $s).

It seems to me that this idea is not very far away from P5 "tying", but I
may be wrong. If it is not very far away, maybe we can even have:

my %hash is subscripted -> $s{
FETCH {...}
STORE {...}
}

Crazy stuff. I don't know if it is doable or even desirable, but it sure
is cool!

> Larry

[Larry Wall]

On Mon, Dec 06, 2004 at 03:11:15AM -0700, David Green wrote:
[snip]
: I like that.
[snip]
: I like that even better.
[snip]
: I'm happy with those too (perhaps because I do want to be a bit
: mathematical).
[snip]
: "is FAT"? Yeah, that works for me too. =)
[snip]
: I would take that as an abbreviation and read it as "is dimensioned",

: which is English-like enough for me.

[snip]
: But "shape" *is* prettier.

Um. You're so very...easy to please... I guess I'm okay with that...

Larry

[Brent 'Dax' Royal-Gordon]

Larry Wall <la...@wall.org> wrote:
> Also says maybe you could attach a block to a hash or array to
> define what subscripting does. Hmm.

That's...wow.

class Patient {
my DBI::Connection $db;

my Patient @byid[Int $id] {
select_patients("SELECT * FROM patients WHERE patientid = ?", $id)[0];
}
multi my Patient %byname{String $last} {
select_patients(
"SELECT * FROM patients WHERE lastname = ?",
$last, $first
);
}
multi my Patient %byname{String $last, String $first} {
select_patients(
"SELECT * FROM patients WHERE lastname = ? AND firstname = ?",
$last, $first
);
}

...
}

--
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker

"I might be an idiot, but not a stupid one."
--c.l.p.misc (name omitted to protect the foolish)

[David Green]

In article <2004120618...@wall.org>,

la...@wall.org (Larry Wall) wrote:
>On Mon, Dec 06, 2004 at 03:11:15AM -0700, David Green wrote:
>[snip]
>: I like that.

>: I like that even better.

[etc.]

>Um. You're so very...easy to please... I guess I'm okay with that...

=) But you'll notice we didn't hit anything I liked best of all. Maybe
I should rank my responses on a scale from 1 to 10.

Of course, it's all about psychology: complaining about the stuff I
don't like only buys it increased mind-share, whereas you can catch more
flies with honey...

-David "doesn't actually want to catch flies,
yuck... time to rethink this strategy" Green

[David Green]

In article <20041206114...@navi.cx>,

lu...@luqui.org (Luke Palmer) wrote:
>David Green writes:
> > In article <20041204185...@wall.org>,
> > la...@wall.org (Larry Wall) wrote:
> > >Maybe type parameters are just subscripts? [...]
> > > my Fight %fight does key{Dog;Cat};
> > I like that.
>
>Yeah, me too. Except I'm having trouble seeing how key is a role. It's
>not adding anything into a hash; it's changing it. Maybe I just don't
>quite grok roles yet.

I definitely don't, but from my approximate understanding, couldn't we
look at the "Role" of hash as giving you methods for FETCH, STORE,
EXISTS, etc.? And "my %hash does key{Str}" is a shorthand for "my %hash
does Hasherdabery :key(Str)" (or whatever the correct version would
be)? And the mere appearance of a % -- "my %hash" -- is shorterhand
for telling Perl you want your variable to play the Role of an ordinary
unaccessorised hash.

This notion was reinforced by Larry's suggesting that you could supply
code (instead of just a type) to define the keys and values; to me that
sounds like old-fashioned tying in Role's clothing. (But that's
glossing over a lot of details, some of which may actually be important.)

> > >Well, there's always "domain" and "range", if we want to be
> > >mathematical.

>[...]

>What you want here is "domain" and "codomain". Which leads me to
>believe that you don't want either.

Hm. Well, if you want to get picky, yes, the "range" should be the set
of *all* values mapped to from the domain, and it's unlikely that your
hash contains every possible Str [or whatever] as a value. But if we're
being that picky, it's also unlikely that every possible Str is a key,
either, unless you want to say they map onto 'non-existent' values (not
to be confused with undefined values). But a hash isn't a function
anyway, pickily speaking, because your hash can change (its domain or
its range), so at best it represents a set of functions. And what we're
actually specifying is some sort of metadomain and metarange.

Or we could just say we don't want to be that picky anyway. =)

-David "why we wouldn't want to is beyond me, nit-picking is fun!" Green

[Matt Diephouse]

On Tue, 7 Dec 2004 00:39:08 -0800, Brent 'Dax' Royal-Gordon
<bren...@gmail.com> wrote:
> Larry Wall <la...@wall.org> wrote:
> > Also says maybe you could attach a block to a hash or array to
> > define what subscripting does. Hmm.
>
> That's...wow.
>
> class Patient {
> my DBI::Connection $db;
>
> my Patient @byid[Int $id] {
> select_patients("SELECT * FROM patients WHERE patientid = ?", $id)[0];
> }
> multi my Patient %byname{String $last} {
> select_patients(
> "SELECT * FROM patients WHERE lastname = ?",
> $last, $first
> );
> }
> multi my Patient %byname{String $last, String $first} {
> select_patients(
> "SELECT * FROM patients WHERE lastname = ? AND firstname = ?",
> $last, $first
> );
> }
>
> ...
> }

for @byid -> $patient { ... }
for %byname.kv -> $key, $value { ... }

???

--
matt diephouse
http://matt.diephouse.com

[Brent 'Dax' Royal-Gordon]

Matt Diephouse <mdd...@gmail.com> wrote:
> On Tue, 7 Dec 2004 00:39:08 -0800, Brent 'Dax' Royal-Gordon

> > my Patient @byid[Int $id] {
> > select_patients("SELECT * FROM patients WHERE patientid = ?", $id)[0];
> > }
> > multi my Patient %byname{String $last} {
> > select_patients(
> > "SELECT * FROM patients WHERE lastname = ?",
> > $last, $first
> > );
> > }
> > multi my Patient %byname{String $last, String $first} {
> > select_patients(
> > "SELECT * FROM patients WHERE lastname = ? AND firstname = ?",
> > $last, $first
> > );
> > }
> >
> > ...
> > }
>
> for @byid -> $patient { ... }
> for %byname.kv -> $key, $value { ... }

Point. Maybe you just have to make all objects handled through this
method multi, though, and provide an empty-arguments variant:

multi my Patient @byid[] {
return select_patients("SELECT * FROM patients");
}

If the underlying code returns lazy lists, this can be a fairly
efficient way to do things.

The usefulness of this might be limited to providing several views an
underlying data (as above), but if you're doing something much more
complicated, chances are you really ought to use a class and an C<is>.

[arcadi]

does it mean that sub may become unnecessary:

my &foo .($a) {...}

may it be usefull to have hash-like, array-like or sub-like
view of the same variable ?

my %foo .($a) {...}
my %foo .{str $a} {...}
my %foo .[num $a] {...}

arcadi

[Michele Dondi]

<OT>

On Mon, 6 Dec 2004, Luke Palmer wrote:

>>> Well, there's always "domain" and "range", if we want to be
>>> mathematical.

[snip]

> What you want here is "domain" and "codomain". Which leads me to
> believe that you don't want either.

For the record, in most connections "range" would be just as good. Indeed
"codomain", especially from the algebraic/categorial point of view is
sounds somehow better.
</OT>

Michele
--
> [ standard bull-shit snipped ]
> Your friend,
> Nathan the Great
> Age 11

The best of your postings is the backside.
Please let the front also blank in the
future.
- Rainer Rosenthal in sci.math, "Re: Cantor Paradox :-)"

[arcadi]

can this be potentially meningfull/usefull ?
my multi %hash{str} ;
my multi %hash{Day} ;