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 RAA30940; Wed, 29 Sep 2004 17:03:05 +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 RAA31423 for ; Wed, 29 Sep 2004 17:03:03 +0200 (MET DST) Received: from is.intellij.net (mail.intellij.net [213.182.181.98]) by nez-perce.inria.fr (8.13.0/8.13.0) with SMTP id i8TF32HZ004353 for ; Wed, 29 Sep 2004 17:03:03 +0200 Received: (qmail 20647 invoked by uid 89); 29 Sep 2004 15:03:02 -0000 Received: from unknown (HELO ?192.168.1.58?) (dsl@intellij.net@192.168.1.58) by mail.intellij.net with SMTP; 29 Sep 2004 15:03:02 -0000 Message-ID: <415ACEA5.50800@jetbrains.com> Date: Wed, 29 Sep 2004 19:03:01 +0400 From: Dmitry Lomov Organization: JetBrains Inc. User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: caml-list@inria.fr Subject: Re: [Caml-list] Observations on OCaml vs. Haskell References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 415ACEA6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; lomov:01 lomov:01 jetbrains:01 caml-list:01 observations:01 haskell:01 2004:99 run-time:01 run-time:01 bounded:01 bounded:01 unification:01 jetbrains:01 ocaml:01 dmitry:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Brian Hurt wrote: > On Tue, 28 Sep 2004, Jon Harrop wrote: > > >>On Tuesday 28 September 2004 08:22, Ville-Pertti Keinonen wrote: >> >>>I'm fairly certain that type safety is a significant part of the reason; >>>if they were polymorphic, they'd accept any kind of arguments, not just >>>numbers. What's the product of two strings? A run-time type error? >> >>It seems odd then, that the polymorphic comparisons do raise run-time type >>errors (on functions). I guess that's just the way the cookie crumbled... >> >>I think a static analysis program to pick up on such problems could be very >>useful... > > > This gets tricky, I would think. One thing I don't want to lose is the > ability to make ('a -> 'b) list types. Comparing two functions is > obviously bogus, but in most other places being able to handle both > functions and data is a usefull thing. > Apparently one needs some sort of bounded quantification on polymorphic functions, bound being "'a can be anything but a function". Interestingly, one already can have the quantification bounded other way round ("'a can be any function") - just write 'b -> 'c instead of 'a. This bounding corresponds, of course, to partial order imposed by type unification. Friendly, Dmitry -- Dmitry Lomov JetBrains Inc. http://www.jetbrains.com "Develop With Pleasure!" ------------------- 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