From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA15470 for caml-red; Fri, 22 Dec 2000 15:08:58 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA28626 for ; Fri, 22 Dec 2000 10:30:28 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id eBM9UM918400; Fri, 22 Dec 2000 10:30:23 +0100 (MET) Received: from localhost (mikan.kurims.kyoto-u.ac.jp [130.54.16.202]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id SAA21888; Fri, 22 Dec 2000 18:30:20 +0900 (JST) To: Pierre.Weis@inria.fr Cc: caml-list@inria.fr Subject: Re: Ref syntax In-Reply-To: <200012220907.KAA16920@pauillac.inria.fr> References: <20001222122938T.garrigue@kurims.kyoto-u.ac.jp> <200012220907.KAA16920@pauillac.inria.fr> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001222183020R.garrigue@kurims.kyoto-u.ac.jp> Date: Fri, 22 Dec 2000 18:30:20 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: weis@pauillac.inria.fr From: Pierre Weis > I consider the ``| simple_expr0 LESSMINUS expr'' rule as perfectly > acceptable, but I decided to keep this syntactic construct ident <- > expr for ``variables'' assignment, i.e. for a future reintroduction of > good old letref lvalues of the original ML (alias your ``references > certified not to be returned or passed to functions. Easy.'', wish No > 1 of your presonal wish list). In fact they are already here, with fields in objects. Just that you can only use them inside objects. So you were clever to keep it :-) > > So here is also my wishlist for Santa Xavier. > > > > * addition of let mutable ... in > > let mutable x = 0 in > > for i = 1 to do x <- x + i done; > > x > > The idea is to have references which are certified not to be > > returned or passed to functions. Easy. > > Makes lots of thing clearer, but it might be a good idea to allow > > only the let ... in form, since toplevel let mutable is rather > > opposed to functional programming. > > You forgot to mentioned that this feature also adds a lot of > complexity: as a kind of witness of this extra difficulty, we can > observe that you immediately suggest to restrict the construct to > local forms. I suppose that this is not for the vague philosophical > reason you mentioned (``let mutable is rather opposed to functional > programming''), but more seriously to avoid real difficulties, such as > complex typechecking problems (with value polymorphism restriction ?), > or even compilation and semantics problems. Really, I don't think it would be useful at toplevel. I view let mutable .. in as a way to provide some state, but immediately cleanly wrapped, either by only being used locally, or in exported functions. This is completely similar to mutable object fields; both the goal and the method. > For instance, what do we > do if such a letref variable is assigned to, from within the body of a > function (that could be exported) ? This is just syntactic sugar for references, which is why I said it was easy. Similarly typing is just the typing of references. > Furthermore, this construct would add an entirely > new notion to Caml: lvalues. As stated above: they are already here, object fields. You may think of it as a good or bad idea, but the distinction between it and the fact a.x behaves differently when there is a <- and when there is none is subtle. But well, this was only first in my wish list because I was answering to a message related to that. My personal priority is much lower. > > * addition of let open ... in > > module P2d = struct type t = {x:int;y:int} end > > module P3d = struct type t = {x:int;y:int;z:int} end > > let f2d p1 p2 = > > let open P2d in > > {x = p1.x + p2.x; y = p1.y + p2.y} > > Extremely easy. > > I hope it is ``Extremely easy''. Remember that Pascal has been > criticised for its ``with'' construct that locally introduces new > names in programs in a completely silent way. Are you sure this is a > desirable feature ? I think this is different: modules are already a way to organize the namespace, and this allows you to do it more locally. You can already do it with camlp4, so what? > > * have a notation to abbreviate the OCAMLLIB directory in include > > paths. One could write > > ocamlc -c -I +labltk -I +lablGL gears.ml > > rather than > > ocamlc -c -I `ocamlc -where`/labltk -I `ocamlc -where`/lablgGL gears.ml > > > > I would be already satisfied with only one of these... > > So you are already satisfied, since you can write > > ocamlc -c -I +camltk -I +camlimages ocaml_unreal_t.ml > > in the current development version! Great! I had seen the introduction of -where, but didn't catch this one. Thanks, Papa Weis ! Jacques