From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA00995; Wed, 28 Jul 2004 09:26:24 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 JAA00166; Wed, 28 Jul 2004 09:26:23 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i6S7QMSH005330; Wed, 28 Jul 2004 09:26:22 +0200 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA01775; Wed, 28 Jul 2004 09:26:21 +0200 (MET DST) From: Pierre Weis Message-Id: <200407280726.JAA01775@pauillac.inria.fr> Subject: Re: lazyness in ocaml (was : [Caml-list] kprintf with user formatters) In-Reply-To: <1090537249.5870.168.camel@pelican.wigram> from skaller at "Jul 23, 104 09:00:49 am" To: skaller@users.sourceforge.net Date: Wed, 28 Jul 2004 09:26:21 +0200 (MET DST) Cc: pierre.weis@inria.fr, daniel.buenzli@epfl.ch, caml-list@inria.fr X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4107551E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; pierre:01 weis:01 pierre:01 weis:01 lazyness:01 caml-list:01 kprintf:01 formatters:01 lazyness:01 expr:01 expr:01 complained:01 currying:01 lazily:01 compiler:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk [...] > But this looks very dangerous! Yes: lazyness in the presence of side-effects is tricky. But don't worry, that's not the introduction of this new rule that is dangerous, it is the concept of lazy evaluation and more importantly the mixing of lazy evaluation and strict evaluation that is difficult in the presence of side effects. > Its kind of like reference parameters in C++, which make > it impossible to tell if f(expr) can modifiy expr or not > [without finding which 'f' it is and examining it] I cannot understand that one. We have that in Caml already and we had it from the very begining of Caml (1984). For instance, if I write f (expr) could you tell me ``if f(expr) can modifiy expr or not [without finding which 'f' it is and examining it]'' ? To the best of my knowledge, the answer is no. To the best of my knowledge, nobody never complained about that feature. > > In the lazy case it would destroy an important identity: > > f x <==> let x' = x in f x' > > With your rule, the LHS might not evaluate x, whereas the RHS > would. Yes, that's exactly what we want: if (f e) is a lazy application you don't know if e is evaluated or not. This is just what lazyness is about ! Also, I didn't know that such an ``important identity'' stands for Caml expressions. Except in the trivial case where ``x'' just denotes a variable in the statment. In this case, the statment still holds with the new rule :) > Of course we already have that: > > f x y <=/=> let x' = x in y' = y in f x' y' > > since the RHS guarrantees x is evaluated before y, > whilst it happens by chance in the current Ocaml implementation > the reverse is true for the LHS. So what? Is the ``important identity'' wrong after all, being wrong in this case ? Or do you suggest to suppress currying in order to restore the ``important identity'' ? > So even if your rule is sound, it might not be a good idea > because it breaks 'the substitution principle'. There is nothing such as your ``substitution principle'' in Caml, except if we restrict the language to truly trivial expressions (as soon as expressions may incoporate basic operators such as the integer addition your ``principle'' does not stand anymore). > How about sugar: > > \(expr) <==> lazy expr > > Since arguments to be lazily evaluated are never variables, Wait a minute: do you mean I cannot write f e, if e is just a variable? If the answer is yes, your suggestion breaks something important (we still want to apply a function to any expression of the suitable type); if the answer is no then you would need to write f \x as you now have to write f (lazy x) with the current compiler. Or you would have to implement something really strange to handle f e differently if the expression e is a variable or not. Best regards, Pierre Weis INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/ ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners