On Tuesday, November 26, 2002, at 12:47 PM, Dave Whipp wrote:
Hmm, I suppose it depends on how broadly we use the term "type"; I like your definition, if I understand it correctly. :-)I writing these definitions, I came to the conclusion that a context is more than a type. Others may disagree.
(thinking aloud...)
For example, suppose you have a context that says "I expect to see [a reference to a function that has an argument "bar" of type int, and an argument "foo" which is a reference to a MyBlah]".
Even if there isn't an explicit type name associated with it, I'd consider everything inside the [...] to be the description of a certain expected "type". You _could_ name that type, but you don't have to -- the long-form description will do.
Or, for your list example, suppose you say "I expect to see [a list with three elements]", to differentiate from "I expect to see [a list with four elements]".
my($a,$b,$c) = &foo(); # two different contexts:
my($a,$b,$c,$d) = &foo(); # two possible multimethod variants
Both are different contexts, and both the [...] parts represent different unnamed "types"; the multimethod &foo could _theoretically_ be given a different variant for each.
So I'd maybe say context and type are matched one-to-one IFF you can give a name to every possible context, and use that name wherever you want to represent that context. (Where "name" means "possibly multi-word signature-like description that you can give a shorter explicit name to if you want to.")
I'm trying to think of a counterexample, in which you have a context that _cannot_ be represented as a "type" according to this very broad definition. I don't think it should be possible, is it? If it _is_ possible, does that represent a flaw/limitation of the perl6 "types"?
....again, thinking aloud.
MikeL
