From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 80461BB9C for ; Fri, 21 Oct 2005 20:54:02 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j9LIs2Xs004900 for ; Fri, 21 Oct 2005 20:54:02 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA29609 for ; Fri, 21 Oct 2005 20:54:01 +0200 (MET DST) Received: from cgpsrv2.cis.mcmaster.ca (univmail.CIS.mcmaster.ca [130.113.64.46]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j9LIs0ck022197 for ; Fri, 21 Oct 2005 20:54:01 +0200 Received: from [130.113.68.27] (account carette@univmail.cis.mcmaster.ca [130.113.68.27] verified) by cgpsrv2.cis.mcmaster.ca (CommuniGate Pro SMTP 4.1.8) with ESMTP id 107349537 for caml-list@inria.fr; Fri, 21 Oct 2005 14:53:59 -0400 Message-ID: <4359394B.1070201@mcmaster.ca> Date: Fri, 21 Oct 2005 14:54:03 -0400 From: Jacques Carette User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: caml-list@inria.fr Subject: Relating parts of ML and Haskell Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 4359394A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 43593948.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; haskell:01 caml-list:01 oleg:01 haskell:01 functors:01 applicative:01 functors:01 ocaml:01 literate:01 hugs:01 sed:01 ocaml:01 quantified:01 functor:01 functor:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 [I am posting this message to caml-list on behalf of Oleg, who is not a subscriber. I asked him to compose this, as the messages he points to are just as relevant to Caml programmers as to Haskell programmers to understand 'the other side' -- Jacques] Correspondence between ML structures and functors and Haskell type classes is described in a message: Applicative translucent functors in Haskell http://www.haskell.org/pipermail/haskell/2004-August/014463.html The message is based on a draft paper by Chung-chieh Shan, who showed the complete translation of Dreyer-Crary-Harper module language into System Fw. The message attempted to interpret some of Shan's results in idiomatic Haskell with the full use of type classes. That message is both Haskell and OCaml literate code. It can be loaded in GHCi or Hugs -98, and (after some sed filtering) into OCaml. The upshot of the correspondence between type classes and ML modules is as follows: ML signatures correspond to Haskell type classes, and their implementations to the instances Abstract types in ML correspond to either uninstantiated or explicitly quantified type variables in Haskell Type sharing is expressed via type variable name sharing Functor (signatures or structures) correspond to Haskell (class declarations or instances) with type class constraints The argument of functors is expressed via types, with additional labels when needed for finer differentiation Functor applications are done by instance selection based on types at hand plus the additional labels OCaml signature attribution operation -- casting the module or the result of the functor into a desired signature and hiding the extras -- sometimes involves additional tagging/untagging tricks (cf. SetESet). This tagging, done via newtype, is syntactic only and has no run-time effect. Hiding of information (`sealing', in ML-speak) is done by existential quantification. To gain applicativity, we quantify over a higher-ranked type variable (Skolem function proper). A follow-up message (written together with Chung-chieh Shan) Applicative translucent functors in Haskell http://www.haskell.org/pipermail/haskell/2004-September/014515.html is devoted to the problem of sharing constraints and exponential explosion and brittleness of ``sharing by construction'' (or positional sharing). The message translates Harper and Pierce's example into Haskell, using only the most common Haskell extensions to give type-equality constraints by name and avoid an exponential blowup. This exercise suggests that, while type-level records may be convenient to have in Haskell, they may not be strictly necessary to express sharing by specification. As shown below, we can indeed refer to type parameters "by name", taking advantage of the ability of a Haskell compiler to unify type expressions and bind type variables. Our technique may be generalizable to encode all sharing by specification. We hope this message helps clarify the difference between the two sharing styles, and relate the ML and Haskell orthodoxies.