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 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 39881BC6B for ; Tue, 8 Jan 2008 14:45:16 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAHoNg0fRVYT3kmdsb2JhbACQGQEBAQEHBAQpgRaRKYYf X-IronPort-AV: E=Sophos;i="4.24,257,1196636400"; d="scan'208";a="21018444" Received: from an-out-0708.google.com ([209.85.132.247]) by mail4-smtp-sop.national.inria.fr with ESMTP; 08 Jan 2008 14:45:14 +0100 Received: by an-out-0708.google.com with SMTP id b15so2145580ana.102 for ; Tue, 08 Jan 2008 05:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:content-type:content-transfer-encoding:content-disposition:message-id; bh=5jroCUUXVw4NC1As8TzV4hWYkB5hTihJg8kSWGbJjlA=; b=TQ9lnVs6Cs/J7JklRfVSSspElDJNoy90L+qqoGSKvwnSzusNN5IHHVtCsUSh9kjW8C3BTYP/qjjb6OeJrEnm48o6GLRi3U7bNEi+D4OJ2esd2jQhYcexAXsfV0Bc8M/yw6wUWH6gqPmJwLAbo/10IHWpHzhx5QuE8oGFG73/UWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:content-type:content-transfer-encoding:content-disposition:message-id; b=TaWHtUXqiTSHDzmlyN9sH1cp6ElKOSts9r3s7LdQw8AfgTD/QxoPc5PwIOvjaDlVltF/rlRbcq/Ay45cRGQ7tH+8pLaacd4K5RfdnK8tj8nZQiZqfv/wiNFh3YjGuTOp8GSOiPYBCwnSK3DAM0aM8Z8RCBPUC2J47Bh4GY9pAMk= Received: by 10.100.231.16 with SMTP id d16mr45291776anh.23.1199799913969; Tue, 08 Jan 2008 05:45:13 -0800 (PST) Received: from lawn-128-61-26-102.lawn.gatech.edu ( [128.61.26.102]) by mx.google.com with ESMTPS id u25sm33601946ele.13.2008.01.08.05.45.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Jan 2008 05:45:13 -0800 (PST) From: Peng Zang Reply-To: peng.zang@gmail.com To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] "OCaml gives you only monomorphic methods in classes." Date: Tue, 8 Jan 2008 08:45:05 -0500 User-Agent: KMail/1.9.7 Cc: Jon Harrop References: <200712282337.23952.jon@ffconsultancy.com> <20080108.113031.162099765.garrigue@math.nagoya-u.ac.jp> <200801080942.36566.jon@ffconsultancy.com> In-Reply-To: <200801080942.36566.jon@ffconsultancy.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801080845.08276.peng.zang@gmail.com> X-Spam: no; 0.00; ocaml:01 hash:01 params:01 params:01 functors:01 subtyping:01 milner:01 inference:01 ocaml:01 haskell:01 overloading:01 polymorphism:01 odersky:01 ocaml's:01 variants:01 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So I'll pop up here just to say I use a lot of OO in my code. I do research into different techniques of doing (essentially) the same thing. As a result I need to run a lot of benchmarks. Objects make this ideal. I will give a simple example. Suppose you have: - 4 different implementations of lists - 3 sorting algorithms - 2 parameters for generating particular types of lists you care about. Now suppose you want to find the list implementation and corresponding sorting algorithm that yields the best average performance over all the lists you care about (those generated by the params). If lists were implemented as an object, then you can do one big list comprehension to get all combinations of (list, sorting_alg, data_params). You can then map over that list running the sorting alg with the list implementation on the parameterized data. A simple fold min can then yield the best list implementation and sorting algorithm combo. Very simple and nice. If the lists were implemented via modules, then the sorting algorithms might have to be inside functors. One can imagine the extra overhead required to work with that. No more nice list comprehension + map + fold = answer. Alternatively, you might pass in the say, the 7 or so operations supported by lists in addition to the list as arguments to the sorting algorithm. That gets around the problem nicely. However it can be rather unwieldy to use those sort algorithms as they have so many arguments. One might also consider the use of records. But then I would argue you're basically already in object land and you might as well just use objects. Besides which objects gets you things like structural subtyping which is nice if for example, some of the list implementations support certain additional operations not used in this particular benchmark. Peng On Tuesday 08 January 2008 04:42:36 am Jon Harrop wrote: > On Tuesday 08 January 2008 02:30:31 Jacques Garrigue wrote: > > From: Jon Harrop > > > > > I just read this quote and I do not understand what it means: > > > > > > "In particular, the Hindley/Milner style of type inference used in > > > languages such as OCaml or Haskell is incompatible with lots of > > > assumptions of OO languages. One incompatibility is with overloading. > > > That's why OCaml does not let you write + for both integer and floating > > > point addition. Another incompatibility is with higher order > > > polymorphism. That's why OCaml gives you only monomorphic methods in > > > classes." - Martin Odersky > > > > > > In what way must methods be monomorphic in OCaml classes? > > > > They don't. With the restriction that the types of polymorphic > > methods cannot be inferred. There is also another subtle > > limitation, that object are only allowed to have regular > > types. As a result, one cannot write a polymorphic map method in > > ocaml, but this is possible in Java 2 or Scala. > > This begs a question for me: have people used this functionality in their > OCaml code? > > I personally make virtually no use of OCaml's OOP capabilities at all but I > make a lot of use of polymorphic variants. In all but a few cases, objects > seem to be very rarely used by other people in OCaml code. The only notable > exceptions I can think of are LablGTK2 and PXP. > > > I'm quite sure that Martin Odersky is aware of this. I would rather > > interpret his quote as meaning that you have to extend HM in a > > non-trivial way to allow this. He was co-author of two papers > > about extending HM with first-class polymorphism ("putting type > > annotations to work") and OO (the HM(X) framework), a long time > > ago too. All these extensions (including the one used in ocaml) have > > drawbacks, in particular they are either verbose or have bad error > > messages, or both... > > Yes, I believe I misinterpreted Martin's comments. My confusion surrounding > Scala was why someone researching computer languages would ditch widely > appreciated features in favour of adding what appear (to me) to be > seriously obscure gadgets for OO junkies. > > I think the reason Martin is focussing on OOP is partly because it is more > extreme research (whereas cloning OCaml/Haskell is not) and also because it > is potentially of great value to the huge Java ecosystem (even someone > high-up at Sun+Google touted Scala as an escape route for Java). > > That is a very different goal from trying to improve upon the current > generation of functional programming languages and is completely different > to what I was looking for when I found Scala. I'm actually looking for an > OCaml-like language implementation better suited to my needs rather than a > wholly different language. Unfortunately, I cannot imagine who, if anyone, > would build such a thing as an open source project. On the other hand, many > people have written to me describing why they also believe such a project > would be of enormous practical value... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHg35kfIRcEFL/JewRAk4cAKCtwqzxab9oA+g6rZAtzm5fca+ezQCgstPr 39l41RASeQxSX4AjSj4byF4= =tzG7 -----END PGP SIGNATURE-----