From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 0F681BB84 for ; Thu, 15 Jan 2009 13:46:16 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUBAFG/bklKfS4ck2dsb2JhbACTQD4BAQEBCQkKCREDrVSNAAEEiik X-IronPort-AV: E=Sophos;i="4.37,269,1231110000"; d="scan'208";a="33778860" Received: from yw-out-2324.google.com ([74.125.46.28]) by mail4-smtp-sop.national.inria.fr with ESMTP; 15 Jan 2009 13:46:15 +0100 Received: by yw-out-2324.google.com with SMTP id 5so411751ywb.3 for ; Thu, 15 Jan 2009 04:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PQUy21XowVrdccCdi8kNoZ9RRcpFyLQPKgHwNHuTvAs=; b=jLBdWjxtZOAcV4ZmoG+DghWL8IRYyRz1eIzBTdAzYRGgRbHmp4nizXsV9eF/HCHWm2 D6I2xfIBmcBmxKDIVqBtyI50liubjTXPdUUe12nBDmMfs+tlmUDCKCY9ujVp3/WMTvFw MlyDcvJ0unfDE8IdYI1jlJ3Emx1JdkONL3RY0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EhsAelQUleHtpbMfgo3B3AvvNwEUQd/IqdAylw1DarV9AN6Fff3z7icGuDkjuqab6+ 9U8/OctZH+5Wh9l6mtP7JUG1sL2QaMFB+5UEJBj5MqQy/C2h8CfDg+ftyUOJnyDk3Tqn f/RznvgLOlFXJ1hasv+FLrEC0+D0Qftm+LHBs= MIME-Version: 1.0 Received: by 10.151.43.19 with SMTP id v19mr3945689ybj.143.1232023574172; Thu, 15 Jan 2009 04:46:14 -0800 (PST) In-Reply-To: <20090115.211335.27794984.garrigue@math.nagoya-u.ac.jp> References: <1231924711.2711.11.camel@serphost.localdomain> <496DEC48.7000906@wp.pl> <001801c9765e$4fabc3b0$ef034b10$@com> <20090115.211335.27794984.garrigue@math.nagoya-u.ac.jp> Date: Thu, 15 Jan 2009 12:46:14 +0000 Message-ID: <9b415f950901150446u3f4781e3n3dc2dcb8e2732263@mail.gmail.com> Subject: Re: [Caml-list] What is a future of ocaml? From: Benedikt Grundmann To: Jacques Garrigue Cc: dra-news@metastack.com, caml-list@yquem.inria.fr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ocaml:01 grundmann:01 grundmann:01 ocaml's:01 model:01 ocaml:01 syntax:01 cheers:01 inference:01 annotations:01 variants:01 annotations:01 haskell:01 variants:01 principality:01 I would even go so far as to say that One of the advantages of OCaml's current development model is that it is not changing the language very quickly. OCaml is already a big language (featurer/syntax and so on wise), it should (IMHO) not grow a lot more at least not without giving each change a lot of thought. cheers, Bene 2009/1/15 Jacques Garrigue : > From: "David Allsopp" >> Dawid Toton wrote: >> > Could anybody explain why it's impossible to have type classes in OCaml? >> >> I don't think it's impossible - but I believe that if you introduce type >> classes then you "damage" Hindley-Milner type inference and you can no >> longer derive a principal typing for an arbitrary ML expression without >> resorting to type annotations. Whether this is a problem or not is a matter >> of taste - but it does make the language harder to call "ML" if you lose one >> of its central features! That said, there are of course two big features >> (objects and polymorphic variants) in OCaml already which do require >> annotations. > > The reason is mostly wrong :-) > One can have both type classes and principal types; the problem with > principal types in Haskell is more subtle thant that. > And neither polymorphic variants nor object require type anotations in > ocaml; they just make it much more painful to understand error > messages. > Principality is only broken by optional arguments and polymorphic > methods, and there is a -principal flag that recovers some form of > principality (requiring type annotations). > > This said, type classes have a lot of common features with modules or > objects, so this would be yet another way to do some similar things. > More problematic, type classes depend on the nominality of the type > systems, while ocaml has a rich language of structural types. For > instance, it is not completely clear how one could select instances of > type classes for polymorphic variants, without introducing conflicts. > I'm afraid the combination of type classes with modules and functors > is not trivial either. > > Jacques Garrigue > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > -- Calvin: I try to make everyone's day a little more surreal. (From Calvin & Hobbes)