On Sat, Dec 04, 2004 at 08:01:46AM -0700, David Green wrote:
: In article <[EMAIL PROTECTED]>,
: [EMAIL PROTECTED] (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
