[e-lang] TypeDesc/__getAllegedType replacement notes

[Kevin Reid]

On Nov 7, 2007, at 19:08, Mark Miller wrote:
> On Oct 16, 2007 6:36 PM, Kevin Reid <kpreid at mac.com> wrote:
>> * What is the protocol of a "signature" object? What I have now is {
>>     to getNode()
>>     to getEnvironment()
>>   }
>
> Seems good.

In practice, I've added getFQName/0; I haven't decided whether this  
is just compatibility or a good idea.

Note that this protocol is often combined with the guard protocol, so  
its names should be well-considered.

>> * TypeDesc has a "supers" field, which is used in interface  
>> expressions. What should correspond to this in the new world? My  
>> answer for the moment is that it's an additional field in the  
>> "signature" object. Another possiblity would be using a  
>> NKObjectExpr (nonkernel) which has "extends" in the syntax, but  
>> that seems not quite right since the alleged-type is defined in  
>> terms of the kernel.
>
> I'm not sure I understand the first option. What would be the value  
> of a signature's getSuper() (or whatever the name of the new field  
> is)?

I'm not proposing new concepts; I'm trying to map what is already in  
the design of TypeDesc, though unused.

typeDesc#getSupers() returns a ConstList; I have always assumed it  
was a list of type objects.

(By 'type objects' I mean things which are signatures, guards, or  
both; those things which are returned by __getAllegedType/0 and  
asType/0 implementations, used in guard positions, etc.)

>> * Currently, if an object "extends" another, the latter's alleged  
>> messages are included in the former's __getAllegedType answer. How  
>> should this be handled? ...
>
>  If we come up with a satisfying answer for the previous question  
> -- what's a signature's getSuper()? -- might that take case of this  
> as well?
>
> For example, when an object is asked __getAllegedType(), it asks  
> its matcher for their __getAllegedType() as now, and includes the  
> answer as the getSuper() value of the signature it makes and  
> returns. Does this make sense?

My first thought was that no, it's not relevant at all, because the  
issue is not what the representation is, but rather how the E source  
is transformed into it; but now I see that it is in fact a solution:  
the signature's node includes the matcher just like any other, and  
getSupers() contains the TypeDesc of the parent node. Merged method  
lists can be left up to the choices of help() or other display tools.

This is actually a useful simplification of the implementation, too,  
because it means that the signatures don't have to be *merged*, which  
is nontrivial (nouns with the same name but different slots must be  
renamed).

Thanks.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>