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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f3437064e1091fec X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-14 10:45:07 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!msunews!not-for-mail From: "Chad R. Meiners" Newsgroups: comp.lang.ada Subject: Re: What evil would happen? Date: Mon, 14 Jul 2003 13:44:26 -0400 Organization: Michigan State University Message-ID: References: <5ad0dd8a.0307111151.4a08f95a@posting.google.com> <1LEPa.9034$nP.7178@newsfep4-winn.server.ntli.net> <5ad0dd8a.0307120426.226775f1@posting.google.com> <5ad0dd8a.0307130417.41548778@posting.google.com> NNTP-Posting-Host: arctic.cse.msu.edu X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Xref: archiver1.google.com comp.lang.ada:40262 Date: 2003-07-14T13:44:26-04:00 List-Id: "Dmitry A. Kazakov" wrote in message news:o9s4hvofb2mtn8ga9ahf7uu530pfacald8@4ax.com... > On Sun, 13 Jul 2003 13:28:54 -0400, "Chad R. Meiners" > wrote: > > >"Wojtek Narczynski" wrote in message > >news:5ad0dd8a.0307130417.41548778@posting.google.com... > >> Preben Randhol wrote in message > >news:... > >> > >> > Well then functions with side effects should be more resonable > >> > >> "Functions" with side effects can only inject their side effect into > >> where they have been hardcoded to. > >This is wrong. Function have the capability to randomly introduce side > >effects just like any other section of code. > > So what is the point? The point is that the statement was wrong. It was a statement of fact. > >>This is a serious limitation. > >If it were true, I doubt it. In my experience, functions are more useful > >when they are pure. Sure there are times when a function cannot be pure, > >but sub-routine with a side-effect should be made a procedure in most cases. > > It is also my view. But I see rather other consecuences from this: > > 1. All functions are pure. So no access parameters allowed, no access > to global data from the body is allowed etc. > > 2. But procedures are allowed to have a result. > > This would be perfectly consistent and as safe as possible. I prefer SPARK's rules on functions, but I think that we should just allow in out parameters for our unpure functions since passing access parameters can be ugly. I really do not see the harm in allowing unpure functions because good modularity usually nudges the programmer towards writing pure functions. However, when an exception is needed being able to write unpure function should be straight forward and easy to detect at the specification level. > >In mathematics, functions only return single elements, which may be a > >composite of some sort. > > In mathematics you can encapsulate all side effects in objects of > unlimited complexity. It is not the case for programming languages. > Especially ones with weak type inference capability. True, I was only stating inspiration for using records to return multiple values. > --- > Regards, > Dmitry Kazakov > www.dmitry-kazakov.de -CRM