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