Re: [Caml-list] Object Features

Re: [Caml-list] Object Features

[Damien Guichard]

[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]

Hello, 

May be i misunderstand something with point n°1. 
Otherwise it seems pretty easy to me : 

    let x = 10 
    let y = 20 
    let o = 
    begin 
      object 
        method x = x 
        method y = y 
      end 
    end 


Le 30/11/2014 à 05:24:32, Jordan W <jordojw@gmail.com> à écrit : 
Hello, 


I've encountered several situations where I would have benefited from the
following features. I am curious what some of the OCaml core developers think
about them.


1. Object punning:
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


Which would create an object with two methods x, y that return x and y
respectively. It may be easy to apply the same convention to object values.


2. Object extension: I believe that OCaml immediate objects are fairly
under-appreciated, and most people could find useful applications for them (at
least) in the form of row polymorphic records. However, there are several
features that would make them even more powerful. The feature I long for the
most is object extension (on immediate objects). OCaml has support for
extending objects (inheritance), but only via classes. I understand that
implementing this may complicate dynamic dispatch and/or use of `self`, but
perhaps some compromise could be reached - something like a limited form of
`inherit`, that is allowed to have different semantics and works on immediate
objects (at least in the case when objects are being used as row-polymorphic
records).


    let oldObj = object method x = 20 method greet = "hi" end
    let newObj = {<oldObj with method x = 10 >}


This is similar to Andreas Rossberg's Record Extensions in SuccessorML.


New languages are picking up these extensible record features as described in
Daan Leijen's paper [Extensible Records With Scoped Labels] and I suspect this
feature will be of interest to many others.


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)).




Thanks for listening. I'm curious if anyone's given thought to implementing
these, and eager to hear thoughts/suggestions.


Jordan

[-- Attachment #2: Type: text/html, Size: 4372 bytes --]

Re: [Caml-list] Object Features

[Jordo]

Yes, this is primarily what I'm looking to do. The only question I have is whether or not the type annotation is required. Ideally, it would not be. This, along with some basic pattern matching ability would allow objects to be treated as a lightweight structurally subtyped records. Even if the use of "self" is limited or prohibited, I would still find tremendous use for them. OCaml objects are already so close to fulfilling this role, aside from these relatively small features. The presence of more advanced class features needn't add friction to using objects as more flexible records (at least that's the hope).

Have you taken a look at SuccessorML's extensible records? Also, Elm's records work in similar ways to what I'm describing (pattern matching and extension without requiring annotation). I've seen many new languages gain traction recently, many of them treating records as extensible, pattern matched and structurally subtyped. I realized that OCaml may have had something very close for a long time, but is missing a little bit of polish.

Sent from my iPhone

> On Dec 1, 2014, at 2:09 AM, Alain Frisch <alain@frisch.fr> wrote:
> 
>> On 11/30/2014 04:49 PM, Gerd Stolpmann wrote:
>> What could in deed be useful is a more light-weight construction that
>> layers objects, i.e. you define a new object around an existing one:
> 
> Indeed, being able to define an object by extending an existing one would be quite useful (perhaps overriding some methods, being understood that this doesn't affect late-bound calls from that object to itself).
> 
> I'd rather see that as a new kind of class expressions, say "of object <expr>", where <expr> could be an object expression (with a fixed type)
> so that you could write:
> 
> let new_object old_object =
>   object
>     inherit of object (old_object : t)
> 
>     method foo = ...
> 
>     method! bar = ...
>   end
> 
> This would also allow to merge two existing objects into one.
> 
> If <expr> has type < m1:t1; ...; mn: tn >, "of object <expr>" would be equivalent to
> 
>  let o = <expr> in
>  object
>    method m1 = o # m1
>    ...
>    method mn = o # mn
>  end
> 
> 
> 
> -- Alain

Re: [Caml-list] Object Features

[Gabriel Scherer]

[-- Attachment #1: Type: text/plain, Size: 4903 bytes --]

> let myFunction delta {<x; y; ..>} = x + y + delta

> let myFunction delta o = o#(x + y + delta)

Calling methods is an effectful operation, so you need to specify when (and
how many time) the methods are called for those local-open or
pattern-matching syntax.

It is intuitively clear to me that the semantics of
  let {< x; y; ... }> = obj in body
should be equivalent to
  let x = obj#x and y = obj#y in body
(notice that the other methods of the same object are not forced)

I don't think there is a reasonable semantics for obj#(x + y):
- you really don't want to reason on the free variables that are inside the
parentheses
- you may not know what the type of `obj` is yet (let foo obj = obj#(x +
y)), so you don't know what its methods are.

On Mon, Dec 8, 2014 at 10:34 AM, Goswin von Brederlow <goswin-v-b@web.de>
wrote:

> On Sun, Nov 30, 2014 at 02:45:19PM +0100, Philippe Wang wrote:
> > Hi,
> >
> > Just some quick thoughts about 3.: it's not object matching! It looks
> > a little like it, but it's not at all, in the sense that it's not at
> > all like the rest of OCaml's pattern matching stuff.
> > I would somewhat find it useful, but probably too misleading and
> > confusing to encourage having this feature.
> >
> > I was going to say it's not shorter or easier to write it this way, but
> actually
> >     let myFunction delta {<x; y; ..>} = x + y + delta
> > is a little shorter than something like
> >     let myFunction delta (o: <x:'a; y:'b; ..>) = o#x + o#y + delta
> > but, still, I don't really see something good in there.
> >
> > Cheers,
> > Philippe Wang
>
> How about this syntax (similar to local open of modules):
>
> let myFunction delta o = o#(x + y + delta)
>
> MfG
>         Goswin
>
>
> > On Sun, Nov 30, 2014 at 5:24 AM, Jordan W <jordojw@gmail.com> wrote:
> > > Hello,
> > >
> > > I've encountered several situations where I would have benefited from
> the
> > > following features. I am curious what some of the OCaml core developers
> > > think about them.
> > >
> > > 1. Object punning:
> > > 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
> > >
> > > Which would create an object with two methods x, y that return x and y
> > > respectively. It may be easy to apply the same convention to object
> values.
> > >
> > > 2. Object extension: I believe that OCaml immediate objects are fairly
> > > under-appreciated, and most people could find useful applications for
> them
> > > (at least) in the form of row polymorphic records. However, there are
> > > several features that would make them even more powerful. The feature
> I long
> > > for the most is object extension (on immediate objects). OCaml has
> support
> > > for extending objects (inheritance), but only via classes. I
> understand that
> > > implementing this may complicate dynamic dispatch and/or use of
> `self`, but
> > > perhaps some compromise could be reached - something like a limited
> form of
> > > `inherit`, that is allowed to have different semantics and works on
> > > immediate objects (at least in the case when objects are being used as
> > > row-polymorphic records).
> > >
> > >     let oldObj = object method x = 20 method greet = "hi" end
> > >     let newObj = {<oldObj with method x = 10 >}
> > >
> > > This is similar to Andreas Rossberg's Record Extensions in SuccessorML.
> > >
> > > New languages are picking up these extensible record features as
> described
> > > in Daan Leijen's paper [Extensible Records With Scoped Labels] and I
> suspect
> > > this feature will be of interest to many others.
> > >
> > > 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)).
> > >
> > >
> > > Thanks for listening. I'm curious if anyone's given thought to
> implementing
> > > these, and eager to hear thoughts/suggestions.
> > >
> > > Jordan
> >
> > --
> > Caml-list mailing list.  Subscription management and archives:
> > https://sympa.inria.fr/sympa/arc/caml-list
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 7178 bytes --]

Re: [Caml-list] Object Features

[Goswin von Brederlow]

On Mon, Dec 01, 2014 at 09:49:32AM +0000, Jeremy Yallop wrote:
> 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

struct
  include F
end

MfG
	Goswin

Re: [Caml-list] Object Features

[Goswin von Brederlow]

On Sun, Nov 30, 2014 at 02:45:19PM +0100, Philippe Wang wrote:
> Hi,
> 
> Just some quick thoughts about 3.: it's not object matching! It looks
> a little like it, but it's not at all, in the sense that it's not at
> all like the rest of OCaml's pattern matching stuff.
> I would somewhat find it useful, but probably too misleading and
> confusing to encourage having this feature.
> 
> I was going to say it's not shorter or easier to write it this way, but actually
>     let myFunction delta {<x; y; ..>} = x + y + delta
> is a little shorter than something like
>     let myFunction delta (o: <x:'a; y:'b; ..>) = o#x + o#y + delta
> but, still, I don't really see something good in there.
> 
> Cheers,
> Philippe Wang

How about this syntax (similar to local open of modules):

let myFunction delta o = o#(x + y + delta)

MfG
	Goswin

 
> On Sun, Nov 30, 2014 at 5:24 AM, Jordan W <jordojw@gmail.com> wrote:
> > Hello,
> >
> > I've encountered several situations where I would have benefited from the
> > following features. I am curious what some of the OCaml core developers
> > think about them.
> >
> > 1. Object punning:
> > 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
> >
> > Which would create an object with two methods x, y that return x and y
> > respectively. It may be easy to apply the same convention to object values.
> >
> > 2. Object extension: I believe that OCaml immediate objects are fairly
> > under-appreciated, and most people could find useful applications for them
> > (at least) in the form of row polymorphic records. However, there are
> > several features that would make them even more powerful. The feature I long
> > for the most is object extension (on immediate objects). OCaml has support
> > for extending objects (inheritance), but only via classes. I understand that
> > implementing this may complicate dynamic dispatch and/or use of `self`, but
> > perhaps some compromise could be reached - something like a limited form of
> > `inherit`, that is allowed to have different semantics and works on
> > immediate objects (at least in the case when objects are being used as
> > row-polymorphic records).
> >
> >     let oldObj = object method x = 20 method greet = "hi" end
> >     let newObj = {<oldObj with method x = 10 >}
> >
> > This is similar to Andreas Rossberg's Record Extensions in SuccessorML.
> >
> > New languages are picking up these extensible record features as described
> > in Daan Leijen's paper [Extensible Records With Scoped Labels] and I suspect
> > this feature will be of interest to many others.
> >
> > 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)).
> >
> >
> > Thanks for listening. I'm curious if anyone's given thought to implementing
> > these, and eager to hear thoughts/suggestions.
> >
> > Jordan
> 
> -- 
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Object Features

[Alain Frisch]

On 11/30/2014 04:49 PM, Gerd Stolpmann wrote:
> What could in deed be useful is a more light-weight construction that
> layers objects, i.e. you define a new object around an existing one:

Indeed, being able to define an object by extending an existing one 
would be quite useful (perhaps overriding some methods, being understood 
that this doesn't affect late-bound calls from that object to itself).

I'd rather see that as a new kind of class expressions, say "of object 
<expr>", where <expr> could be an object expression (with a fixed type)
so that you could write:

  let new_object old_object =
    object
      inherit of object (old_object : t)

      method foo = ...

      method! bar = ...
    end

This would also allow to merge two existing objects into one.

If <expr> has type < m1:t1; ...; mn: tn >, "of object <expr>" would be 
equivalent to

   let o = <expr> in
   object
     method m1 = o # m1
     ...
     method mn = o # mn
   end



-- Alain

Re: [Caml-list] Object Features

[Jeremy Yallop]

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.

Re: [Caml-list] Object Features

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 2364 bytes --]

Am Samstag, den 29.11.2014, 20:24 -0800 schrieb Jordan W:

> 2. Object extension: I believe that OCaml immediate objects are fairly
> under-appreciated,

I wouldn't say so. As I'm not a big fan of inheritance immediate objects
are the simpler and more expressive of dealing with objects.

>  and most people could find useful applications for them (at least) in
> the form of row polymorphic records. However, there are several
> features that would make them even more powerful. The feature I long
> for the most is object extension (on immediate objects). OCaml has
> support for extending objects (inheritance), but only via classes.

Basically, the availability of inheritance is the big difference between
classes and functions returning immediate objects. As of now, you need
to define classes if you want extensibility. But inheritance is of
course more than that; in particular you can also override existing
methods (and that's what I in particular don't like about it, as this
leads to hard to understand program flows).

What could in deed be useful is a more light-weight construction that
layers objects, i.e. you define a new object around an existing one:
Something like

let new_object (old_object : t) =
  object
    (* Define some new methods: *)
    method foo = ...

    (* And make all methods of old_object also available *)
    method _ = old_object # _

    (* This notation shall mean that we define all methods x as
       method x = old_object # x
       and do this for all methods from t that haven't been defined
       otherwise
    *)
  end

This is very different from inheritance, because you have an outer
object and an inner, and the interface of the inner object is respected
(i.e. if another method of old_object calls foo, it is sure it calls the
version of foo in old_object, and not the new definition in new_object).
And this layering or wrapping construction is of course compatible with
immediate objects.

Gerd

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Caml-list] Object Features

[Philippe Wang]

Hi,

Just some quick thoughts about 3.: it's not object matching! It looks
a little like it, but it's not at all, in the sense that it's not at
all like the rest of OCaml's pattern matching stuff.
I would somewhat find it useful, but probably too misleading and
confusing to encourage having this feature.

I was going to say it's not shorter or easier to write it this way, but actually
    let myFunction delta {<x; y; ..>} = x + y + delta
is a little shorter than something like
    let myFunction delta (o: <x:'a; y:'b; ..>) = o#x + o#y + delta
but, still, I don't really see something good in there.

Cheers,
Philippe Wang


On Sun, Nov 30, 2014 at 5:24 AM, Jordan W <jordojw@gmail.com> wrote:
> Hello,
>
> I've encountered several situations where I would have benefited from the
> following features. I am curious what some of the OCaml core developers
> think about them.
>
> 1. Object punning:
> 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
>
> Which would create an object with two methods x, y that return x and y
> respectively. It may be easy to apply the same convention to object values.
>
> 2. Object extension: I believe that OCaml immediate objects are fairly
> under-appreciated, and most people could find useful applications for them
> (at least) in the form of row polymorphic records. However, there are
> several features that would make them even more powerful. The feature I long
> for the most is object extension (on immediate objects). OCaml has support
> for extending objects (inheritance), but only via classes. I understand that
> implementing this may complicate dynamic dispatch and/or use of `self`, but
> perhaps some compromise could be reached - something like a limited form of
> `inherit`, that is allowed to have different semantics and works on
> immediate objects (at least in the case when objects are being used as
> row-polymorphic records).
>
>     let oldObj = object method x = 20 method greet = "hi" end
>     let newObj = {<oldObj with method x = 10 >}
>
> This is similar to Andreas Rossberg's Record Extensions in SuccessorML.
>
> New languages are picking up these extensible record features as described
> in Daan Leijen's paper [Extensible Records With Scoped Labels] and I suspect
> this feature will be of interest to many others.
>
> 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)).
>
>
> Thanks for listening. I'm curious if anyone's given thought to implementing
> these, and eager to hear thoughts/suggestions.
>
> Jordan

[Caml-list] Object Features

[Jordan W]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

Hello,

I've encountered several situations where I would have benefited from the
following features. I am curious what some of the OCaml core developers
think about them.

1. Object punning:
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

Which would create an object with two methods x, y that return x and y
respectively. It may be easy to apply the same convention to object values.

2. Object extension: I believe that OCaml immediate objects are fairly
under-appreciated, and most people could find useful applications for them
(at least) in the form of row polymorphic records. However, there are
several features that would make them even more powerful. The feature I
long for the most is object extension (on immediate objects). OCaml has
support for extending objects (inheritance), but only via classes. I
understand that implementing this may complicate dynamic dispatch and/or
use of `self`, but perhaps some compromise could be reached - something
like a limited form of `inherit`, that is allowed to have different
semantics and works on immediate objects (at least in the case when objects
are being used as row-polymorphic records).

    let oldObj = object method x = 20 method greet = "hi" end
    let newObj = {<oldObj with method x = 10 >}

This is similar to Andreas Rossberg's Record Extensions in SuccessorML.

New languages are picking up these extensible record features as described
in Daan Leijen's paper [Extensible Records With Scoped Labels] and I
suspect this feature will be of interest to many others.

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)).


Thanks for listening. I'm curious if anyone's given thought to implementing
these, and eager to hear thoughts/suggestions.

Jordan

[-- Attachment #2: Type: text/html, Size: 2786 bytes --]