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=1.3 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 0FA50BC69 for ; Sat, 4 Aug 2007 05:29:02 +0200 (CEST) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.235]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l743T1WD019785 for ; Sat, 4 Aug 2007 05:29:01 +0200 Received: by hu-out-0506.google.com with SMTP id 16so715801hue for ; Fri, 03 Aug 2007 20:29:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:content-transfer-encoding:in-reply-to:user-agent:from; b=nAWUK+HDDQlajMkugYyK4uPrs+smiElaDeCV3TulqJZG+WKzBsSb1rH/M3JYj+CyKFDnp0o5iQChYmT2x+fdmCqMudICWDBkbZtB8JoPqDyBu0h5OoQDTxAUBvrYlFyGxXPjYlGoCSUAzTCt3I3PXBBmcilb5WLiUfzbvVU3jGw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:content-transfer-encoding:in-reply-to:user-agent:from; b=Gsi1omZf+oSPx3j+XUBUdKU0D2SW6FMJevi22ddZb8SMLrkWCT9XwzsUbd9RcWQvmyL8RYURx5FoXtj2Def/hst4KHjBToUR9ktLythgJ8Pz2bSA9+Khxe8ENE2djUn2qSmkLRVoNZ6DWAg230qqNOc6Rpi5OixEZGTQtTIZ9K4= Received: by 10.86.3.2 with SMTP id 2mr2705798fgc.1186198140567; Fri, 03 Aug 2007 20:29:00 -0700 (PDT) Received: from localhost ( [82.122.232.94]) by mx.google.com with ESMTPS id g8sm11912867muf.2007.08.03.20.28.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2007 20:28:58 -0700 (PDT) Received: by localhost (sSMTP sendmail emulation); Sat, 04 Aug 2007 05:28:46 +0200 Date: Sat, 4 Aug 2007 05:28:46 +0200 To: Oliver Bandel Cc: caml-list@inria.fr Subject: Re: [Caml-list] Type notation in OO-layer Message-ID: <20070804032846.GA22512@jiyu.gnu> Mail-Followup-To: Julien Moutinho , Oliver Bandel , caml-list@inria.fr References: <1186175921.46b39bb1508b1@webmail.in-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1186175921.46b39bb1508b1@webmail.in-berlin.de> User-Agent: Mutt/1.5.16 (2007-06-11) From: Julien Moutinho X-j-chkmail-Score: MSGID : 46B3F27D.001 on discorde : j-chkmail score : X : 0/20 1 0.000 -> 1 X-Miltered: at discorde with ID 46B3F27D.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; notation:01 0200,:01 bandel:01 notation:01 ocaml:01 grepping:01 camlp:01 rauglaudre:01 -function:01 runtime:01 meth:01 afaik:01 ocaml:01 runtime:01 trade-off:01 On Fri, Aug 03, 2007 at 11:18:41PM +0200, Oliver Bandel wrote: > value_as_string has type "string", but that is not completely correct, be= cause > it get's no input-value, and therefore is of type "unit -> string". Nop, this is correct, a little bit strange, at a pinch, because at first sight one could think about this as a field access (i.e. like r.contents), thus without any possibility to wrap code around it; but it may not be the case. > One could say, that this is a special notation for OO, but > if we are rigid (we should be! ... shouldn't we?!) it is not correct. Ocaml being a multi-paradigms language, I do not see any problem, even mora= l. This is just not functional at the user level, that's all. I think the main reason is to enable a clean cascading of the methods (i.e. o#m1#m2#...) coupled with a ``right-most precedence'' of '#' but since I was not around by the time the Inrians were designing it, and that my flying over [1] was as unsuccessful as my grepping at the old c= aml-list, I do not know. Long ago, I had a glance at [0]. Now, I am still wondering why it has remai= ned unanswered, but mostly if a cool Camlp(4|5) extension could easily do the same job? Will see later, unless List.exists will_spoil_us [`Mr_Pouillard; `Mr_De_Rau= glaudre; `Mr_Doe]. > As it is not a true "unit"-function, we at least should give it a > unit-like type like "message -> string" so that the type-system > make a complete annotation of type?! Don't worry, what you call ``message'' is already symbolized by the name of= the method. Roughly, at runtime the ``obj#meth_name'' notation uses the name of the met= hod and a table carried by the object to retrieve the code to be executed (cf. = [2]). Note that the name of the method appears in the type of the object. > Why is the "sending a message to the [object]" activity not > notated in the type? Don't panic, just an habit to get. > And: are both definitions correctly? AFAIK, yep. Unless you are following a coding guideline telling you to use the first way when the method does a certain kind of thing, and the second when it does an other kind. Example: no unit =3D the returned value is definitively set at the instantiation o= f the class use of unit =3D the returned value may change after the instantiation > Which to choose? Preferences in style? The unit way: +++++ the method is /easily/ extensible with optional arguments + the functional property could be helpful to delay the application of a method easily without any wrapping: instead of (fun () -> o#destroy) you just write o#destroy. -- more parentheses: instead of o#method1#method2#... you must write in vanilla Ocaml: ((o#method1 ())#method2 ())#... - perhaps a little runtime overhead, but mostly /negligible/ Therefore, in my mind I have shaped it in an easy trade-off between extensi= bility and meaning. Only simple methods, whose job and use are well known /=E0 priori/, mostly = accessors of values but also methods like #clone, #destroy, or #nocopy /=E0 la/ LablG= TK may get my agreement to avoid the added unit. Note that the same concern arises with the definition of classes. Hope this helps you a lOt to surround the "Ocaml".[0]. Oh, and by the way, here are two opinions I would have liked to know by the time I was learning Ocaml objects, and thus using them /everywhere/.= =2E. Opinion of an Inrian, who worked on this famous char [2]: "OCaml is first a functional lang[u]age so I think (I hope) that people= do not use objects as heavily as in Java, and for instance use pattern matching rather than only method calls for implementing branches." Opinion of an Academian who has worked with Ocaml [3]: "I suspect that continued exposure to OCaml will eventually induce developers to design programs that are written al- most entirely in the functional style, if only because these aspects of the language are the most mature and the most widely used. I am personally beginning to find that writing in the functional style leads to far fewer bugs, simply because most of the program data is immutable and thus there is little room for errors involving incon- sistent state." References: [0]: Mr.Boos' proposal: http://caml.inria.fr/pub/ml-archives/caml-list/1996/10/1d280be49dcb480ce0= fa1428e668e330.en.html [1]: Mr.Vouillon and Mr.Remy's paper: http://caml.inria.fr/pub/papers/remy_vouillon-objective_ml-tapos98.ps.gz [2]: Mr.Vouillon's opinion: http://gallium.inria.fr/~doligez/caml-guts/objects.txt [3]: Mr.DiBernardo's opinion: https://www.cs.ubc.ca/~kdvolder/CPSC511/submissions_06_07/mike.pdf [4]: Mr.Mottl's thoughts: http://caml.inria.fr/pub/ml-archives/caml-list/1999/06/2691901a1d99467728= 70ac5f96552341.en.html