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 BA8AC7FB30 for ; Mon, 8 Dec 2014 11:07:34 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.218.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.218.49 as permitted sender) identity=mailfrom; client-ip=209.85.218.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@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-oi0-f49.google.com) identity=helo; client-ip=209.85.218.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-oi0-f49.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsBAKR3hVTRVdoxm2dsb2JhbABagkOBFVgEgwGzDo4hgWqGEwKBIQcWAQEBAQERAQEBAQEGCwsJFC6EAgEBAQMBEhEEGQEbEgYFAQMBCwYDAgsNDR0CAiEBAREBBQEKEgYTEhCIAwEDCQkNoXGQST0xiy+BbIMFiksKGScDChVEhRwBAQEBAQUBAQEBAQEBARQBBQ6OFIFVVAQHgm+BRwWEUgaObHaDADyBaYEwJotYhCMSJYENhBo+MIEDgUABAQE X-IPAS-Result: AlsBAKR3hVTRVdoxm2dsb2JhbABagkOBFVgEgwGzDo4hgWqGEwKBIQcWAQEBAQERAQEBAQEGCwsJFC6EAgEBAQMBEhEEGQEbEgYFAQMBCwYDAgsNDR0CAiEBAREBBQEKEgYTEhCIAwEDCQkNoXGQST0xiy+BbIMFiksKGScDChVEhRwBAQEBAQUBAQEBAQEBARQBBQ6OFIFVVAQHgm+BRwWEUgaObHaDADyBaYEwJotYhCMSJYENhBo+MIEDgUABAQE X-IronPort-AV: E=Sophos;i="5.07,537,1413237600"; d="scan'208";a="92348523" Received: from mail-oi0-f49.google.com ([209.85.218.49]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Dec 2014 11:07:33 +0100 Received: by mail-oi0-f49.google.com with SMTP id i138so3148002oig.22 for ; Mon, 08 Dec 2014 02:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nMJDoxKpBVE4KEy6QH9Pb8qYFDHZ+eRh9OQT5bVZoa4=; b=UaPa1QZFhujN6+l6RpiTthrrMS8b9cDzD5lPVyeD81s4ifgJPipBNrrGD/0TVUlGIU UuyQRsIUOt/TaOBaeJI3l5EZxCDRm4i3bSaGzn+ArYqTcFoXeGUaA/xjHfYRgtyUj9a2 KmzBTuPkMBQONNhkfl1/gQfvBZujOll19rUFisfcTfhVBL70Af159eovoAX/aZDXf5a+ s+ZEsAvtFLETD3Qig6OXd9MgYPAnlV1b3SLhFbu4uSfiZQeRDepTq9R9M9mr75uHDXRq oNw8yYFVlDkp7wff2qKXG0TrakO6NV5WByjl/VayGJzvGqB5KDpCaOsINOMS07U8G2oF fOfg== X-Received: by 10.202.49.131 with SMTP id x125mr6145385oix.17.1418033252484; Mon, 08 Dec 2014 02:07:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.90.197 with HTTP; Mon, 8 Dec 2014 02:06:52 -0800 (PST) In-Reply-To: <20141208093447.GA25411@frosties> References: <20141208093447.GA25411@frosties> From: Gabriel Scherer Date: Mon, 8 Dec 2014 11:06:52 +0100 Message-ID: To: Goswin von Brederlow Cc: caml users Content-Type: multipart/alternative; boundary=001a113cd9f04b52c70509b19850 Subject: Re: [Caml-list] Object Features --001a113cd9f04b52c70509b19850 Content-Type: text/plain; charset=UTF-8 > let myFunction delta {} = 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 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 + delta > > is a little shorter than something like > > let myFunction delta (o: ) = 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 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 = {} > > > > > > 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 + 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)). > > > > > > > > > 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 > --001a113cd9f04b52c70509b19850 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0let myFunction delta {<x; y; ..>} =3D x + y + delta

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

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

It is intuitively clear to me that the semantics of
<= div class=3D"gmail_extra">=C2=A0 let {< x; y; ... }> =3D obj in body<= /div>
should be equivalent to
=C2=A0 let x =3D obj#x and y =3D 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):
<= div class=3D"gmail_extra">- 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 =3D obj#(x + = y)), so you don't know what its methods are.

On Mo= n, Dec 8, 2014 at 10:34 AM, Goswin von Brederlow <goswin-v-b@web.de>= ; wrote:
On Sun, Nov 30, 2014 a= t 02:45:19PM +0100, Philippe Wang wrote:
> Hi,
>
> Just some quick thoughts about 3.: it's not object matching! It lo= oks
> 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
>=C2=A0 =C2=A0 =C2=A0let myFunction delta {<x; y; ..>} =3D x + y += delta
> is a little shorter than something like
>=C2=A0 =C2=A0 =C2=A0let myFunction delta (o: <x:'a; y:'b; ..= >) =3D 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 =3D o#(x + y + delta)

MfG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 benefi= ted from the
> > following features. I am curious what some of the OCaml core deve= lopers
> > 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&= #39;t found a
> > way to perform object punning on methods or values for object *ex= pressions*.
> >
> >=C2=A0 =C2=A0 =C2=A0let x =3D 10
> >=C2=A0 =C2=A0 =C2=A0let y =3D 20
> >=C2=A0 =C2=A0 =C2=A0let o =3D object
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0method x
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0method y
> >=C2=A0 =C2=A0 =C2=A0end
> >
> > 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 obje= ct values.
> >
> > 2. Object extension: I believe that OCaml immediate objects are f= airly
> > 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 fea= ture I long
> > for the most is object extension (on immediate objects). OCaml ha= s support
> > for extending objects (inheritance), but only via classes. I unde= rstand that
> > implementing this may complicate dynamic dispatch and/or use of `= self`, but
> > perhaps some compromise could be reached - something like a limit= ed form of
> > `inherit`, that is allowed to have different semantics and works = on
> > immediate objects (at least in the case when objects are being us= ed as
> > row-polymorphic records).
> >
> >=C2=A0 =C2=A0 =C2=A0let oldObj =3D object method x =3D 20 method g= reet =3D "hi" end
> >=C2=A0 =C2=A0 =C2=A0let newObj =3D {<oldObj with method x =3D 1= 0 >}
> >
> > This is similar to Andreas Rossberg's Record Extensions in Su= ccessorML.
> >
> > 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.
> >
> >=C2=A0 =C2=A0 =C2=A0let myFunction delta {<x; y; ..>} =3D x = + y + delta
> >
> >=C2=A0 =C2=A0 =C2=A0let myFunction delta o =3D match o with
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{<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 thoug= ht to implementing
> > these, and eager to hear thoughts/suggestions.
> >
> > Jordan
>
> --
> Caml-list mailing list.=C2=A0 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.=C2=A0 Subscription management and archives:
ht= tps://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

--001a113cd9f04b52c70509b19850--