caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Dan Grossman <djg@cs.washington.edu>
To: Andreas Rossberg <rossberg@ps.uni-sb.de>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Constructors as functions and tuples in constructors
Date: Wed, 08 Oct 2003 10:05:05 -0700	[thread overview]
Message-ID: <3F8443C1.6030404@cs.washington.edu> (raw)
In-Reply-To: <3F843C6E.8060407@ps.uni-sb.de>


A good point, with these rebuttals:

(1) A pattern-match would have the potential of allocating memory, which 
some may judge poorly.  But the compiler could warn about this.

(2) This transformation does require the type A carries is transparent. 
  So we still couldn't relax the "other" restriction that a signature 
cannot hide an unparenthesized t1 * t2 variant.

(3) It's not clear how far this trivial transformation should be 
generalized.  For example, given
   type t = A of int * int * int * int
which of these should we allow
   A(1,2,3,4)
   A((1,2,3,4))
   A((1,2),(3,4))
   A(1,(2,3),4)
   ...

--Dan

Andreas Rossberg wrote:
> Dan Grossman wrote:
> 
>>
>>> Second, it would also be nice not to have "the concept of constructor
>>> arity", and treat the code below as correct:
>>>
>>> type t = A of int * int
>>> let _ =   match A (17, 0) with
>>>     A z -> match z with (x, y) -> ()
>>
>>
>> Works with type t = A of (int * int).  You put the parens in.  So the 
>> choice is yours.  The advantage of leaving them out is usually 
>> performance.
> 
> 
> That is not true. It would be quite trivial for the compiler to translate
> 
>   A z -> e
> 
> into the equivalent of
> 
>   A(z1,z2) -> let z = (z1,z2) in e
> 
> without affecting performance of other programs in any way. Likewise,
> 
>   A z
> 
> could be transformed into
> 
>   let (z1,z2) = z in A(z1,z2)
> 
> instead of rejecting it. OTOH, your workaround certainly decreases 
> performance for type t, as other pointed out.
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  reply	other threads:[~2003-10-08 17:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-08 15:57 Serge
2003-10-08 16:07 ` Dan Grossman
2003-10-08 16:33   ` Andreas Rossberg
2003-10-08 17:05     ` Dan Grossman [this message]
2003-10-09 12:40       ` Andreas Rossberg
2003-10-08 18:28     ` Alain.Frisch
2003-10-08 18:44       ` Marcin 'Qrczak' Kowalczyk
2003-10-08 16:13 ` Michal Moskal
2003-10-08 16:25 ` Nicolas Cannasse

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=3F8443C1.6030404@cs.washington.edu \
    --to=djg@cs.washington.edu \
    --cc=caml-list@inria.fr \
    --cc=rossberg@ps.uni-sb.de \
    /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).