From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ce0900b60ca3f616 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-06 14:48:36 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!t-online.de!newsfeed.r-kom.de!fu-berlin.de!uni-berlin.de!ppp-1-166.cvx5.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Side-Effects in Functions [Rosen Trick] Date: Tue, 6 Nov 2001 22:48:42 -0000 Message-ID: <9s9pc2$125kn6$1@ID-25716.news.dfncis.de> References: <9rti6v$hcu$1@news.huji.ac.il> <1EyE7.10050$xS6.13527@www.newsranger.com> <9rue9f$j4t$1@nh.pace.co.uk> <9ruiet$kqg$1@nh.pace.co.uk> <3BE3235D.E292B890@boeing.com> <3BE35498.9F6381A2@acm.org> <9s230d$107b5a$2@ID-25716.news.dfncis.de> <5ee5b646.0111040507.5ca7ea23@posting.google.com> <9s3tl3$111hco$1@ID-25716.news.dfncis.de> <5ee5b646.0111041846.93f3e07@posting.google.com> <9s5eub02j61@drn.newsguy.com> <3be666fe.6426140@News.CIS.DFN.DE> <9s7bfb$11boa1$1@ID-25716.news.dfncis.de> <87itcn8xxx.fsf@deneb.enyo.de> NNTP-Posting-Host: ppp-1-166.cvx5.telinco.net (212.1.152.166) X-Trace: fu-berlin.de 1005086915 35836646 212.1.152.166 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:15955 Date: 2001-11-06T22:48:42+00:00 List-Id: "Florian Weimer" wrote in message news:87itcn8xxx.fsf@deneb.enyo.de... > "Nick Roberts" writes: > > > From a pedagogical point of view, care needs to be taken not to give the > > impression that a function in a procedural programming language (most > > programming languages, really) is the same thing as a mathematical function. > > Clearly it isn't: a mathematical function is a kind of relation called a > > 'bijection' (and is nowadays specifically defined as such, I think); > > A function f : M -> N are two sets M, N and a subset G_f of the > Cartesian product M x N with the following property: for all m in M, > there exists exactly one n in N such that (m, n) in G_f. That actually sounds like an injection to me (1 to 1), whereas I get the impression mathematicians (discrete ones anyway ;-) tend to insist nowadays on the definition of a function as a bijection (both 1 to 1 and 'onto', i.e. both an injection and a surjection, so that f' is also a bijection). However IANAM. > > a programming function is really just an encapsulated computation. > > Yes, such functions take an additional implicit argument (the machine > state before execution) and have an invisible result (the machine > state after execution). Neatly put. Of course, if the (programming) function might perform I/O, we are potentially talking about 'world state' (or even 'universe state') rather than just machine state! (And then we have the problem with enthalpy, but that, as they say, is a different game of banana and clotted cream.) > However, there are programming languages which use only mathematical > functions, and a special construct for I/O, Haskell for example. I'm not a Haskell expert, but functional languages in general do fix the order of evaluation of their functions (or some of their functions) precisely because of the side-effect problem. I presume lazy evaluation can be a serious hazard, if used without care, nevertheless. -- Nick Roberts