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,f3437064e1091fec X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-15 01:16:52 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!sn-xit-04!sn-xit-01!sn-xit-06!sn-xit-08!supernews.com!small1.nntp.aus1.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!in.100proofnews.com!in.100proofnews.com!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: What evil would happen? Date: Tue, 15 Jul 2003 10:06:04 +0200 Message-ID: References: <1LEPa.9034$nP.7178@newsfep4-winn.server.ntli.net> <5ad0dd8a.0307120426.226775f1@posting.google.com> <5ad0dd8a.0307130417.41548778@posting.google.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1058256288 10049021 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:40281 Date: 2003-07-15T10:06:04+02:00 List-Id: On Mon, 14 Jul 2003 13:44:26 -0400, "Chad R. Meiners" wrote: >"Dmitry A. Kazakov" wrote in message >news:o9s4hvofb2mtn8ga9ahf7uu530pfacald8@4ax.com... >> 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. Exactly, this is why I'd prefer procedures with a result and functions enforced (as much as possible) to be pure. Then a code reader could easily figure out from the declaration what to expect, rather than searching for some obscure pragmas or inspecting the bodies. I believe that code purity is important enough to deserve extra syntax sugar. Then we are already going this way - the functions of a protected object may not change its state, which influences the implementation. Similarly, function calls could be implemented differently from calls to procedures. For example, the language could require the exact call order for procedures. I mean nasty pitfalls like: Character'Pos (Read (Socket)) * 256 + Character'Pos (Read (Socket)) --- Regards, Dmitry Kazakov www.dmitry-kazakov.de