Re: Status Summary; next steps

On Tuesday, November 26, 2002, at 12:47  PM, Dave Whipp wrote:
> I writing these definitions, I came to the conclusion that a
> context is more than a type. Others may disagree.

Hmm, I suppose it depends on how broadly we use the term "type"; I like 
your definition, if I understand it correctly.  :-)

(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