From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 2576C7FB0C for ; Mon, 1 Dec 2014 10:49:36 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yallop@gmail.com) identity=pra; client-ip=74.125.82.45; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yallop@gmail.com"; x-sender="yallop@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yallop@gmail.com designates 74.125.82.45 as permitted sender) identity=mailfrom; client-ip=74.125.82.45; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yallop@gmail.com"; x-sender="yallop@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wg0-f45.google.com) identity=helo; client-ip=74.125.82.45; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yallop@gmail.com"; x-sender="postmaster@mail-wg0-f45.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgBAGM5fFRKfVItlGdsb2JhbABbg1dNCwSDAcNchk4CgQsHFgEBAQEBEQEBAQEHCwsJEjCEAgEBAQMBEhEEGQEbGAUBAwELBgULDQICJgICIQEBEQEFARwGEyKICAEDCQkNsEQ9MYszgWyDCooyChknDVqFFgEBAQEBAQQBAQEBAQEBFQEBBA6BII0VgWpOB4J1gVMFhHACkGCEdIIBjnWEUhgohTc/MIJHAQEB X-IPAS-Result: AvgBAGM5fFRKfVItlGdsb2JhbABbg1dNCwSDAcNchk4CgQsHFgEBAQEBEQEBAQEHCwsJEjCEAgEBAQMBEhEEGQEbGAUBAwELBgULDQICJgICIQEBEQEFARwGEyKICAEDCQkNsEQ9MYszgWyDCooyChknDVqFFgEBAQEBAQQBAQEBAQEBFQEBBA6BII0VgWpOB4J1gVMFhHACkGCEdIIBjnWEUhgohTc/MIJHAQEB X-IronPort-AV: E=Sophos;i="5.07,493,1413237600"; d="scan'208";a="91189044" Received: from mail-wg0-f45.google.com ([74.125.82.45]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 01 Dec 2014 10:51:23 +0100 Received: by mail-wg0-f45.google.com with SMTP id b13so13592098wgh.4 for ; Mon, 01 Dec 2014 01:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H3jFH1GlOMqUxw1BPT05gB07kd4M/cIVb7XND6MbMJ8=; b=idPY+K9IjHo95FzStc1fFzQGwWmAxQFCpwYiHk5lZUW0R4Jm3oF02JgZyF/y9EII9M Kkc7cWcpNOZYq/GzclX5Ko9ZFvxOv9tQazY5sUHnlt77VgfXKgxuoiBkj2uSYmaj8+Ut Lj/Gb3MByGbXuL15wu5D6lBYkGH+z8+G+MPKp3tkkO7GpRR6+ycK1cGuzVdO9Qk7BwMg ctSu4i++EA78fs9+gE7+DI/MzqnvTJuxiHEwIyiW6Yrm1spYwxrsmQHuE2IpO9ilLtTM MXO/cN9EbbFPsx6AIOCIrarWxELNL+qnP4CZym2Swshd5lObnYHmlx0nrdHYP6Qy2lXZ qcuw== MIME-Version: 1.0 X-Received: by 10.194.62.163 with SMTP id z3mr92392567wjr.74.1417427373044; Mon, 01 Dec 2014 01:49:33 -0800 (PST) Received: by 10.217.115.5 with HTTP; Mon, 1 Dec 2014 01:49:32 -0800 (PST) In-Reply-To: References: Date: Mon, 1 Dec 2014 09:49:32 +0000 Message-ID: From: Jeremy Yallop To: Jordan W Cc: Caml List Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Object Features On 30 November 2014 at 04:24, Jordan W wrote: > I understand that object punning on "functional updates" to objects was > recently added to trunk. This is a nice consistency, but I haven't found a > way to perform object punning on methods or values for object *expressions*. > > let x = 10 > let y = 20 > let o = object > method x > method y > end I wonder how far it's wise to take this idea. It would be possible to extend the approach to a lot of places where it's currently necessary to write 'x = x'. For example, we could extend module-level bindings similarly: module (F : sig val x : int val y : int end) = struct open F let x let y end (This approach breaks down for other binding forms, though: 'module type S' and 'exception E' mean different things already, and 'type t' has the wrong scoping.) For records and labels punning is a clear improvement, because it's available in both patterns and expressions. It's quite important for patterns to be succinct, and the extension to expressions is an obvious symmetry. For functional object updates things are less clear-cut, although I think there's still an argument to be made in favour of punning. The form {< a = x; b = y >} is so similar to { a = x; b = y } that there's no real reason not to support the same abbreviated form in both cases. The argument for method punning is perhaps even weaker, not least because you lose some of the power of methods with the proposed abbreviated form, since the 'self' variable is not available. > 3. Object matching. > > let myFunction delta {} = x + y + delta > > let myFunction delta o = match o with > {} -> x + y + delta > > > This may be relatively easy to implement (my reasoning is that I believe it > could even be solved at the parsing stage (not that it would be a good idea > to do so)). Right: this was one of the examples distributed with the 'patterns' framework for user-defined extensions to pattern matching: https://code.google.com/p/ocaml-patterns/#Object_patterns Without some such framework it's not entirely trivial to desugar object patterns into existing syntax, since you have to be able to both bind variables and "backtrack" (i.e. resume matching at the next pattern) when patterns don't match. Consider how you'd translate the following, for example: function Some {< x = Some y >} -> e1 | ... You might be inclined to start off like this function Some o -> (match o#x with Some y -> e1 | ... but then you need some way of returning to the next pattern in the top-level match if 'o#x' doesn't match 'Some y'. Anyway, this is a little off topic. As you say, it wouldn't be a good idea to treat object patterns during parsing.