From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA32079; Wed, 10 Sep 2003 10:18:39 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA26688 for ; Wed, 10 Sep 2003 10:18:38 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h8A8IZT19486 for ; Wed, 10 Sep 2003 10:18:36 +0200 (MET DST) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2/3.7W) with ESMTP id RAA18839; Wed, 10 Sep 2003 17:18:30 +0900 (JST) To: BeckW@t-systems.com Cc: caml-list@inria.fr Subject: RE: [Caml-list] strange behaviour with variants and "cannot be g eneralized" In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030910171830O.garrigue@kurims.kyoto-u.ac.jp> Date: Wed, 10 Sep 2003 17:18:30 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 jacques:01 t-systems:01 didier:01 morgon:01 3.06:01 orthogonal:01 implemented:01 3.07:01 omitted:01 backquote:01 3.06.:01 uglier:01 compiles:01 checker:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: "Beck01, Wolfgang" > Didier Remy [mailto:remy@morgon.inria.fr] wrote: > > > Here is some explanation of > > > > 1) what happened in version 3.06 and > > 2) how this is related to a relaxed form of value restriction, > > 3) which is actually orthogonal to the solution implemented in 3.07 > > > > [detailed explanation omitted] > > well, I was not aware that compilation of polymorphic variants is an area > of ongoing research. In the OCaml manual, they are not mentioned under > "Language extensions" but as a section in the chapter "An introduction to > Objective Caml". There is a statement > > "In programs, polymorphic variants work like usual ones. You just > have to prefix their names with a backquote character `." > > and this is not true, at least in 3.06. After spending another evening > with weird type errors, I replaced polymorphic variants with ordinary > ones. My project looks uglier now since I had to split up some files, > but at least it compiles and runs. Well the problem discussed above is not one of polymorphic variants, but of polymorphism in general. And it is about type checking, not compilation (the latter being pretty trivial). The relaxed value restriction happens to make life easier with variants, but this is not its only goal. There is maybe a misunderstanding on the "work like" bit. Honestly, if polymorphic variants where "just like" normal variants, there would be no point in using them. The intended meaning, is that they have the same operational semantics as normal variants, but the typing is fully another story. And there are a few warnings in the manual about the need to write some types if want to avoid an overdose of polymorphism. Polymorphic variants are not dangerous (actually they're type safe!) but they can bite if you're not careful. I understand your disappointment, and just hope you will look again at this feature after getting more used to the type checker. Answering to Didier Remy, when I introduced the relaxed value restriction I intended first to do both improvements simultaneously, but I stopped short of it for several reasons. * the improvement you describe would require extensive changes in the type checker, as all the work on polymorphism is currently delegated to the handling of let. * the combination with the relaxed restriction makes it even trickier * in many cases, the relaxed restriction does already the job * even when this is not the case, this improvement is purely syntactic, so you can still expand your definition to solve the problem, as Wolfgang discovered himself * actually there is an exception, if a record type mixes both mutable and immutable fields type 'a mix = {data: 'a ; mutable count: int} let r = {data = (fun x -> x); count = 0} There is no solution here, short of changing the type to use a reference rather than a mutable field. But it might also be the case that you just want to put the identity there. In that case we have now polymorphic fields. type mix = {data: 'a. 'a -> 'a ; mutable count: int} let r = {data = (fun x -> x); count = 0} So, I think this is a good idea in itself, but before I try again introducing this improvement, I need a few compelling examples to justify the effort. Cheers, Jacques Garrigue ------------------- 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