caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Patrick M Doane <patrick@watson.org>
To: Xavier Leroy <Xavier.Leroy@inria.fr>
Cc: Chris Hecker <checker@d6.com>, caml-list@inria.fr
Subject: Re: [Caml-list] variant with tuple arg in pattern match?
Date: Fri, 6 Apr 2001 21:42:38 -0400 (EDT)	[thread overview]
Message-ID: <Pine.BSF.3.96.1010406213912.16279A-100000@fledge.watson.org> (raw)
In-Reply-To: <20010406155241.D5178@pauillac.inria.fr>

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?

Patrick

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 caml-list-request@inria.fr.  Archives: http://caml.inria.fr


  reply	other threads:[~2001-04-07  1:42 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-04 11:04 Chris Hecker
2001-04-04 18:47 ` Alain Frisch
2001-04-04 19:18 ` Patrick M Doane
2001-04-04 19:36   ` Chris Hecker
2001-04-04 19:49     ` Daniel de Rauglaudre
2001-04-05  8:19       ` Christian RINDERKNECHT
2001-04-04 19:49     ` Patrick M Doane
2001-04-06 13:52   ` Xavier Leroy
2001-04-07  1:42     ` Patrick M Doane [this message]
2001-04-07  6:44       ` Daniel de Rauglaudre
2001-04-07  7:42     ` Fergus Henderson
2001-04-08 19:45       ` Pierre Weis
2001-04-08 20:37         ` Charles Martin
2001-04-08 23:57         ` Brian Rogoff
2001-04-09  0:22           ` Alain Frisch
2001-04-09 16:07             ` Pierre Weis
2001-04-10  8:23               ` Michel Mauny
2001-04-10  9:14                 ` Xavier Leroy
2001-04-10 10:09                   ` Michel Mauny
2001-04-10 10:44                 ` reig
2001-04-10 11:32                   ` Michel Mauny
2001-04-10 11:47                     ` reig
2001-04-10 12:10                       ` reig
2001-04-10 12:35                         ` Michel Mauny
2001-04-10 12:49                         ` Marcin 'Qrczak' Kowalczyk
2001-04-09  6:23           ` Mattias Waldau
2001-04-09  7:34             ` Daniel de Rauglaudre
2001-04-09 15:57           ` Pierre Weis
2001-04-10  9:07             ` Sven LUTHER
2001-04-09  8:20         ` Christian RINDERKNECHT
2001-04-10  2:54         ` Patrick M Doane
2001-04-10 19:04           ` John Max Skaller
2001-04-08  0:22 jgm
2001-04-10 12:17 Dave Berry
2001-04-10 13:12 ` Marcin 'Qrczak' Kowalczyk
2001-04-10 21:26   ` Bruce Hoult
2001-04-10 22:34     ` John Prevost
2001-04-10 13:51 ` Frank Atanassow
2001-04-10 17:25 Dave Berry
2001-04-10 23:16 ` Marcin 'Qrczak' Kowalczyk
2001-04-10 17:33 Dave Berry
2001-04-10 22:34 ` John Prevost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.BSF.3.96.1010406213912.16279A-100000@fledge.watson.org \
    --to=patrick@watson.org \
    --cc=Xavier.Leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=checker@d6.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).