Do Existential Types make Algebraic Types obsolete? (was Re: how to exploit existential types)

[S. Alexander Jacobson]

Do existential types makes algebraic types obsolete?
I mean there seems to be a large semantic overlap between the two
concepts.

For example, once you can implement lists with just the product type (,),
why bother with algebraic types?

Arguably Boolean is a natural algebraic type, but if we pattern
match on typenames then we don't need the algebraic types here. e.g.

> --Booleans w/o algebraic types
> data True = True 
> data False = False
> class Boolean where -- no methods required
> instance Boolean True where -- trivial implentation
> instance Boolean False where --trivial implementation
> --(There is probably much better syntax for this)

Pattern matching on type names would not be a violation of the type
system, it would just be syntactic sugar...e.g. for booleans it would be
equivalent to:

> --Hack because there is no built in pattern matching on type names
> instance TypeName True where
>  typeName x = "True"
> instance TypeName False where
>  typeName x = "False"
> --definition of if' in this framework
> if' x y z = case (typeName x) of
>               "True" -> y
>               "False" -> z

Languages like C and Java do not seem to have an equivalent to algebraic
types because they allow heterogenous lists.  

Are there contexts where you need algebraic types because existential
types won't do the job?  Wouldn't everybody be happier if you could just
pattern match on type names (someone else requested this in a recent
thread)?

--
Or the most extreme version of this question, once you abandon algebraic
types, do you need constructor names at all or can you just use
position e.g.

> data MyType a b = Int a b
> myFunc (MyType x y z) = MyType (x+1) y z
> data MyType2 a b = {field1::Int,field2::a,field3::b}
> myFunc2 x = (field1 x+1,field2 x)

-Alex-


On Fri, 19 Feb 1999, Michael Hobbs wrote:

> "S.D.Mechveliani" wrote:
> > With existentials, i hoped to achieve the effect of simplification,
> > something like          ...
> >                         Just d -> (dn  , d)
> >                         _      -> (s:dn, s)
> >                                     where
> >                                     s = DMeat {name = "shashlyk"...}
> > Is this possible?
> > If there is no chance, i would rather forget of existentials, so far.
> > 
> > Thanks a lot for the help.
> 
> I'm not sure if this is a real world problem, or just a for-instance.
> (You never know! :) Anyway, I can see that fundamental issue that you
> want to resolve is how to store various types of data into a single
> list. The issue of figuring out the type of each element is is resolved
> by the `Name' stored with each element. I don't know much yet about
> existential types, but I would think that you would still have to have
> some function or something that relates `Name's to particular types.
> 
> But my real point in replying to this message is to see if you actually
> need a multi-type list. Do you really *need* to have separate types for
> DMeat, DVine, etc.? For example, instead of having:
> 
>   data DMeat      = DMeat      {mName  :: String  -- ,...several fields
>                                } 
>   data DVegetable = DVegetable { different fields }
>   data DVine      = DVine      { different fields }
>   ...
>   -- 50 kinds of dishes, each described in individual manner
>   data Dish = Meat' DMeat | Vegetable' DVegetable | ... -- 50 items
> 
> would it be possible to use:
> 
>   data Dish = DMeat {mName :: String, ...}
>     | DVegetable {...}
>     | DVine {...}
>     | ...
> 
> This would eliminate the need to have a multi-type list, for this
> particular example anyway.
> 
> - Michael Hobbs
> 

___________________________________________________________________
S. Alexander Jacobson                   Shop.Com
1-212-697-0184 voice                    The Easiest Way To Shop