]> 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