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
next prev parent 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