Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] variant with tuple arg in pattern match?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: [Caml-list] variant with tuple arg in pattern match?
[ Difference between "type foo = Foo of int * int" and
  "type foo = Foo of (int * int)" ]

> I would certainly like it if Caml could:
> 
>   1) Treat this entirely as an optimization issue and not make a syntactic
> distinction.

This is extremely hard to do in the presence of modules and abstract
type.  The problem is that the structure

      struct
        type foo = Foo of int * int
        type arg = int * int
        ...
      end

would then match

      sig
        type arg
        type foo = Foo of arg
        ...
      end

and users of the module would believe that "Foo" is a constructor with
one argument (that happens to be a pair), which does not match the
representation used in the rest of the structure ("Foo" as a
constructor with two arguments).

Type-based compilation strategies such as TAL and FLINT can deal with
this issue, but at considerable cost in complexity of the compiler and
execution speed.

Frankly, I think there is no point in maintaining the illusion that
datatype constructors are either nullary (constant) or unary.  The
only efficient implementation model is N-ary constructors, so let's
reflect this in the language.

>   2) Be able to make reasonable choices about which representation would
> be more appropriate.

99% of the time, the current representation choice (N-ary constructor
if the constructor is declared with a N-tuple type) is adequate.

I agree that in an ideal world the syntax of the declaration should
make this more explicit, e.g. the CamlP4 way ("Foo of int and int"
vs. "Foo of int * int").  The current "syntactic overloading" of "*"
in constructor declarations is sometimes misleading, but did make the
conversion from Caml V3.1 code convenient a long, long time ago...

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr