Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: 2001-04-07 (01:42)
From: Patrick M Doane <patrick@w...>
Subject: Re: [Caml-list] variant with tuple arg in pattern match?
Very good points regarding compilation.  As I think about it more, I agree
that you are right about making N-ary constructors exposed at the
syntactic level.  I especially like the syntax modifications that are part
of the revised syntax, but times certainly change:  when I first looked at
that syntax long ago, I didn't understand why the difference was there in
the first place. 

What are the current thoughts about adopting the revised syntax as the
"standard one"? How many programmers use that syntax?


On Fri, 6 Apr 2001, Xavier Leroy wrote:

> [ 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  Archives: