My original question was related to use of existing facilities. I find it somewhat surprising how rich and complex a language Haskell turns out to be. I'm wary of yet more features.

That said, you seem to be suggesting a kind of "anonymous" union type (to complement the proposed "anonymous" record type?). At one level, that seems to answer the question I was raising, and seems to require that alternative selection is based on (unification of?) the datatypes, rather than by simple matching of constructor labels. That sounds to me a bit like class instance selection (and I note that Scott did suggest using type classes).

Could your proposal be viewed as a syntactic sugaring of classes and instances, without explicit instance declarations?

#g
--

At 10:35 08/07/04 +0100, Alastair Reid wrote:
It sounds a little as though you want a family of n-ary union type
constructor.  A crude first attempt would be:

  data Either2 t1 t2 = In1 t1 | In2 t2
  data Either3 t1 t2 t3 = In1 t1 | In2 t2 | In3 t3
  ...

but this would be a bit tedious to use because the names are a bit meaningless
- you'd be relying heavily on type checking to keep you straight. e.g., it's
kinds hard to read:


  f :: Either String Bool -> Either String Bool
  f (In1 "Fred") = In1 "Frederick"
  f (In2 m)      = In2 (not m)

Proposals for records gives you an easy way to define arbitrary product types
with convenient syntax:

  { name = "Fred", married = True } :: { name :: String, married :: Bool }

Maybe what you really want here is a way to define union types with some
convenient syntax.  In the following made up syntax, |[ ... |] contains a
list of types to be unioned together with each type labelled by a constructor
name.

  f :: |[ Name :: String, Married :: Bool |]
    -> |[ Name :: String, Married :: Bool |]
  f |[ Name = "Fred" |] = |[ Name = "Frederick |]
  f [| Married = m |]   = [| Married = not m |]

I wonder if an extension like this would be generally useful?  (Would it be
useful for defining a compiler/interpreter by first giving a simple language
and then adding further operations?)

--
Alastair Reid

------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to