Re: [Caml-list] Object Features

[Jeremy Yallop <yallop@gmail.com>]

On 30 November 2014 at 04:24, Jordan W <jordojw@gmail.com> 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; ..>} = x + y + delta
>
>     let myFunction delta o = match o with
>         {<x; y; .. >} -> 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.