From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 5CC3FBB84 for ; Thu, 3 Aug 2006 09:29:47 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k737TkKW023820 for ; Thu, 3 Aug 2006 09:29:47 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA28315 for ; Thu, 3 Aug 2006 09:29:46 +0200 (MET DST) Received: from smtpb.mathworks.co.uk (smtpb.mathworks.co.uk [195.217.152.250]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k737Tj7T028532 for ; Thu, 3 Aug 2006 09:29:45 +0200 Received: from hadrian2.mathworks.co.uk (hadrian2.mathworks.co.uk [172.16.26.6]) by smtpb.mathworks.co.uk (8.13.6/8.12.11) with ESMTP id k737TOlu011924 for ; Thu, 3 Aug 2006 08:29:24 +0100 (BST) Received: from message-uk.ad.mathworks.com (message-uk.mathworks.co.uk [172.16.26.7]) by hadrian2.mathworks.co.uk (8.11.7/8.11.7) with ESMTP id k737SAU14023 for ; Thu, 3 Aug 2006 08:28:10 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Caml-list] strict? Date: Thu, 3 Aug 2006 08:29:23 +0100 Message-ID: Thread-Topic: [Caml-list] strict? Thread-Index: Aca2u9s3zMNnjdDvRZa2bC25VXMOcgAESrlA From: "Alexander Bottema" To: X-Miltered: at concorde with ID 44D1A5EA.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 44D1A5E9.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; encodes:01 compiler:01 o'caml:01 compiler:01 semantics:01 annotations:01 ocaml:01 beginner's:01 ocaml:01 bug:01 2006:98 1.0:98 compilers:01 heap:01 beginners:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 When writing real compilers, strictness is not that interesting. What we focus on is whether a function is side-effect free or program-effect free. Side-effect free basically practically means not doing I/O and program effect free practically means that we don't write to "unknown" locations in the heap/memory. We then allow certain transformations based on whether functions are side-effect free or program-effect free. You can probably imagine other categories as well. After all, it is what kind of optimizations/transformations that you'd like to do that gives your domain of parameters to control them. When I learned the concept of strictness it was in the context of pure functional programming. For me the definition was mostly there to distinguish non-strict functions, such as if(e,t,f) from other functions. Bottom encodes essentially two different things, non-termination or "domain error". The non-termination aspect is crucial for non-strict functions such as if, since the non-termination of 't' or 'f' may not imply that if() itself will not terminate. However, in real compiler design, the number of non-strict functions is very small and usually built-ins. However, this is of course not true if you implement lazy functional programming languages where basically everything is non-strict. Alexander -----Original Message----- From: caml-list-bounces@yquem.inria.fr [mailto:caml-list-bounces@yquem.inria.fr] On Behalf Of skaller Sent: Thursday, August 03, 2006 07:13 AM To: O'Caml Mailing List Subject: [Caml-list] strict? I'm looking for a pair of concepts such as nice function/transparent expression which allow an arbitrary choice of evaluation strategy. A nice function is basically one like 'sin' which is total, has no side effects, depends only on its arguments, and always returns a value. I think this is basically 'total, pure and strict'. A transparent expression is one which can be evaluated at any time, anywhere. For example 'sin 1.0' is the same no matter when and where it is evaluated. More or less an expression is transparent if it is a constant or application of nice functions to transparent arguments. The idea is basically to know when a compiler can choose the evaluation strategy based on performance, without worrying that this will change semantics. More precisely my translator *already* does this .. and I want to know when this is justified (so I can figure out how to give the programmer enough annotations and control to get the result they want, and be able to reason about their code). Note I use the word 'function' in the C (or Ocaml) sense here. Clearly the Wikipedia definition of strict: f(bottom) =3D bottom is rubbish when applied to a mathematical function like 'sin',=20 since bottom isn't a valid argument, but it makes sense for 'sin' in the programming language sense. --=20 John Skaller Felix, successor to C++: http://felix.sf.net _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs