From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 40F53BB81 for ; Fri, 10 Dec 2004 03:30:56 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iBA2UtlK020374 for ; Fri, 10 Dec 2004 03:30:55 +0100 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 DAA20192 for ; Fri, 10 Dec 2004 03:30:54 +0100 (MET) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iBA2Uq63024445 for ; Fri, 10 Dec 2004 03:30:54 +0100 Received: from [192.168.1.200] (ppp203-65.lns1.syd3.internode.on.net [203.122.203.65]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id iBA2Um7D019191; Fri, 10 Dec 2004 13:00:49 +1030 (CST) Subject: Re: [Caml-list] environment idiom From: skaller Reply-To: skaller@users.sourceforge.net To: Jacques Garrigue Cc: caml-list In-Reply-To: <20041210.081159.105772440.garrigue@math.nagoya-u.ac.jp> References: <20041209.134735.79249569.garrigue@math.nagoya-u.ac.jp> <877e9a170412082202790e2cfb@mail.gmail.com> <20041210.081159.105772440.garrigue@math.nagoya-u.ac.jp> Content-Type: text/plain Message-Id: <1102645847.2611.417.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 10 Dec 2004 13:30:48 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 41B90A5F.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41B90A5C.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 wrote:01 ocaml:01 ocaml:01 pointless:01 compiler:01 semantics:01 bug:01 globals:01 stack:01 posix:01 globals:01 struct:01 compilation:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: On Fri, 2004-12-10 at 10:11, Jacques Garrigue wrote: > But you're right that in practice global variables are in general > sufficient to solve this problem, and they are often used in ocaml for > that. They have of course one disadvantage: they are not reentrant. Yes but global/local is a relative thing in sane languages like Ocaml which support nested scopes. One might even say it is one of *the* fundamental software engineering design problems, to try to make variables as local as possible without pointless explicit passing. Since software changes, this may not be the theoretically optimal position. A simple example is an array search in C where the loop variable needs to be external to the loop to actually return the desired result. For Ocaml I find often, I have repeated code handling match cases which share variables and that when I lifted the common code into a subroutine, I often want to make it slightly more global than the scope containing the match, and in doing so I have to now explicitly pass extra variables. I often don't actually know what they are -- the compiler reports unbound variables and I add paramaters until it compiles, thus discovering something previously hidden. Occasionally this procedure fails .. in one case I had used the common Ocaml trick of hiding a more global variable with a more local one .. and in lifting the code outside the scope of the local one but still within the scope of the more global one, I inadvertantly changed the semantics of the code without breaking it, as my lifting procedure required.. that bug took hours to find. The lack of re-entrany Jacques mentions is thus not limited to absolutely global variables as in C statics. It not only applies to *all* variables in functional languages .. it is particularly applicable in Ocaml which is not referentially transparent. One final point of some interest is that even 'absolutely' global variables may not be. In Pascal, globals are actually just elements of the deepest stack frame. In Posix C, some variables can be designated thread local, such as 'errno'. In Felix, all globals may be microthread local, since they're collected into a single struct which is passed explicitly to all functions or stored in a C static, depending on a compilation time switch. I guess in Haskell with monads, global has yet another meaning, as indeed it does in with classes in OO languages, which provide explicit object construction. I would argue that data and code are categorical duals concepts, and localistion is *the* principal engineering issue of software design. Indeed, it is central to lambda calculus where lambda abstraction is the fundamental operation, and is nothing more than a way of moving between a local and global variable -- here the relativity of the local/global distinction in manifest directly as a fundamental principle. Indeed one may say 'languages' lacking abstraction, such as C, aren't even candidates for consideration as 'programming' languages -- because it is impossible to exercise the very design judgements a programmer must make about locality. Interestingly, I think Object Orientation -- which as a complete paradigm I despise -- has made one of the most important steps forward in language design. This is because it provides a second construction for expressing localisation which expands considerably the programmers choices compared to the localisation available merely from lambda abstraction (ie. function closures/stack frames). This is because it allows one to localise *code* with groups of data, whereas closures allow one to localise data within a code structure -- so given the duality of code and data this capability seems somehow fundamental. The fact that in Ocaml these two dual constructions are not syntactically symmetric is an indication of how poorly this duality is understood. Compared to functions/lexical scoping classes in Ocaml seem too 'heavy' -- I think I mean that the simplicity of changing the the locality of variables with functions is not present with classes .. but I don't understand how locality could be better represented: Ocaml inheritance is somehow just tricky sugar instead of being fundamental, as the duality principle says it should be. BTW: I think it is a fault to emphasise entirely the typing theory, which somehow seems more advanced than the theory of that which it is typing! -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net