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=0.3 required=5.0 tests=AWL 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 86683BBAF for ; Wed, 3 Sep 2008 16:38:25 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABAGQ+vkhA6bjmmmdsb2JhbACSEj4BAQEBAQgFCAcRA5w/hzYBAoMl X-IronPort-AV: E=Sophos;i="4.32,320,1217800800"; d="scan'208";a="28771876" Received: from wr-out-0506.google.com ([64.233.184.230]) by mail4-smtp-sop.national.inria.fr with ESMTP; 03 Sep 2008 16:38:24 +0200 Received: by wr-out-0506.google.com with SMTP id c55so2264333wra.11 for ; Wed, 03 Sep 2008 07:38:23 -0700 (PDT) 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=1IW9L3gOG0FzACYIIZaQXpv8Q18YIeKtzbKvSoUWarg=; b=omd2iXYoiv20NR9bwlMv5eudvxFHdnh1NQWcsFnwVaAX3/JLfEJUV7Q7B70C2y4MET JawM/goeZG2njH6kNJHbfDRpMO943tedfUVHNMdIBpQYHU76amdSAqdPTbfBaPhr85Zx UgeQlVNwOE0euWNMDhnTD5f6DdUhIEilveEaI= 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=pVTOmQ+mYmekTUy/NYxX4pCXQIFiXDgHGsdB0mFDxT4ODuxSRNIsk73OHsH6ENrKbg NRIBhZ9iXwn6t3zwPpXfTUMYOoHvMCLOodQrcAmLCHz4GUkvKe18Dxpb6cxlEQDYgR4z 2YUBUNKStsm2ybuEQJCYWg74UNKYQs8p2/o0Q= Received: by 10.90.95.18 with SMTP id s18mr5905188agb.40.1220452702584; Wed, 03 Sep 2008 07:38:22 -0700 (PDT) Received: from ?192.168.0.102? ( [24.99.180.210]) by mx.google.com with ESMTPS id s40sm7822251hsb.7.2008.09.03.07.38.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Sep 2008 07:38:21 -0700 (PDT) From: Peng Zang Reply-To: peng.zang@gmail.com To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] on polymorphic compare and objects Date: Wed, 3 Sep 2008 10:38:14 -0400 User-Agent: KMail/1.9.7 Cc: Alain Frisch References: <200809021909.35930.peng.zang@gmail.com> <48BE2F2E.5020805@frisch.fr> In-Reply-To: <48BE2F2E.5020805@frisch.fr> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809031038.18105.peng.zang@gmail.com> X-Spam: no; 0.00; hash:01 frisch:01 camlp:01 camlp:01 ocaml:01 stdlib:01 well-typed:01 subtyping:01 patching:01 compiler:01 motivating:01 compiler:01 peng:98 peng:98 polymorphic:01 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 03 September 2008 02:31:10 am Alain Frisch wrote: > Peng Zang wrote: > > For objects, we require that all objects > > implement an equal method that satisfies the semantic contract. > > How do you ensure that the method is indeed implemented and has the > correct type? Currently, I require all objects to inherit from a general "Object" class, much like in Java. If you define an object without the equals method for example, or with the wrong type, it will complain that it doesn't match the type or a method is unimplemented. However, the user must manually write the "inherit object" line. I would like to use camlp4 to make this automatic, but I have yet to learn camlp4. > A more robust approach to attaching custom generic operations to > arbitrary data would be to introduce the equivalent of custom blocks, > but for OCaml data. This probably amounts to reserving a new GC tag and > deciding on a memory layout (e.g. a block with this tag has two fields: > the underlying value and a dictionary of generic functions). Then simple > modules in stdlib could expose a well-typed interface (ensuring that the > type of the dictionary's functions is compatible with the type of the > underlying values). It would even be possible to expose the resulting > blocks as values of a private record type with two fields, so as to > preserve pattern matching on the underlying value. I like this approach too. When I first encountered the polymorphic compare issue, custom blocks looked like a great solution. I couldn't figure out how to make it work though. Even with the helpful description you provided, I'm not sure if I could figure out how to do it. I ended up making objects fit the bill because objects are all about attaching functions to data. I also like how it gives you structural subtyping which I love. I wish it were more robust, but I think proper enforcement would require patching the compiler. I want to emphasize that the implementation is not the point. It merely serves as a motivating example of the general approach: fix polymorphic compare (and similar functions) by giving it dynamic dispatch for objects. If this approach is reasonable, and it bears the trial of time, I would like to patch the compiler to properly enforce it. Peng -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFIvqFafIRcEFL/JewRAnFQAJ9lloSHWcrS/NoOrlSq4cxdxnlq5ACgnbtu kHDRxpzodXNcdd0G0aerAqY= =7XTV -----END PGP SIGNATURE-----