Re: no names allowed, we serve types only

From: Keith H Duggar <duggar_at_alum.mit.edu>
Date: Sun, 14 Feb 2010 23:01:52 -0800 (PST)
Message-ID: <f079ae60-83a3-4650-a916-c0a45701ae4d_at_r24g2000yqd.googlegroups.com>



On Feb 14, 4:45 pm, Ben Finney <bignose+hates-s..._at_benfinney.id.au> wrote:
> Keith H Duggar <dug..._at_alum.mit.edu> writes:
>
> > On Feb 14, 12:41 am, Ben Finney <bignose+hates-s..._at_benfinney.id.au>
> > wrote:
> > > Keith H Duggar <dug..._at_alum.mit.edu> writes:
> > > > I'm wondering, do we really need A? Can we not simplify this
> > > > header notion to just a set of types?
>
> > > The point of a unique name is to be able to address the attribute.
> > > Without it, there would be no way to distinguish between attributes
> > > of identical types in the header.
>
> > Which is why I said you could "copy" identical types to yield unique
> > but related types.
>
> You didn't say that, but thanks for the explanation. Okay, so the é─˙copy
> typeé─¨ operation yields a type that is identical to the original except
> for its name. What problem is being solved by this?

It is an alternate solution to the problem of identifying attributes that we want to have the "same type". One solution is to introduce "attribute names". Another, the one I'm proposing here, is to enrich the type system to provide these "type copies" which are distinct but mutually coercible types. I believe this solution is simpler in some ways and that often one is already in possession of all unique types in which case attribute names just "get in the way" to some extent.

Of course if you are dealing with crippled domain support then names are essential. But envision a system with rich type support. I'm asking
if, in that world, we even need to bother with attribute names at all?

KHD Received on Mon Feb 15 2010 - 01:01:52 CST

Original text of this message