Browse thread
[Caml-list] Constructors as functions and tuples in constructors
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Andreas Rossberg <rossberg@p...> |
| Subject: | Re: [Caml-list] Constructors as functions and tuples in constructors |
Dan Grossman wrote: > > (1) A pattern-match would have the potential of allocating memory, which > some may judge poorly. But the compiler could warn about this. Good point, but I don't think anybody would really care. > (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. Of course, no change there. > (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) > ... Not sure what your getting at. OCaml makes otherwise redundant parentheses around constructor argument types significant. That is a hack to allow for a more efficient representation. The idea is to make that hack as transparent as possible. But that aim of course is unrelated to changing the meaning of the multifix type operator * itself. So the first two of your examples should certainly be legal (and they are already), while the others should not, no more than ((1,2),(3,4)) : int * int * int * int (* eek! *) (1,(2,3),4) : int * int * int * int (* ouch! *) - Andreas -- Andreas Rossberg, rossberg@ps.uni-sb.de "Computer games don't affect kids; I mean if Pac Man affected us as kids, we would all be running around in darkened rooms, munching magic pills, and listening to repetitive electronic music." - Kristian Wilson, Nintendo Inc. ------------------- 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