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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d1df6bc3799debed X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: Not intended for use in medical, Date: 1997/05/20 Message-ID: <01bc6562$cb02f3e0$LocalHost@xhv46.dial.pipex.com>#1/1 X-Deja-AN: 242770864 References: <3.0.32.19970423164855.00746db8@mail.4dcomm.com><01bc6006$c13cf880$LocalHost@xhv46.dial.pipex.com><01bc6182$30e3a7c0$LocalHost@xhv46.dial.pipex.com> <01bc63a2$e3e1a940$LocalHost@xhv46.dial.pipex.com> Organization: UUNet PIPEX server (post doesn't reflect views of UUNet PIPEX) Newsgroups: comp.lang.ada Date: 1997-05-20T00:00:00+00:00 List-Id: Matthew Heaney wrote in article ... [...] > Robert Dewar is definately correct on this one: we need functions with in > out mode parameters, in spite of what the pundits say. If function Random > had had an in out parameter, I would have known at compile time that a > protected function was illegal (and wouldn't work). > > Functions without side effect look great on paper, until you try to do real > programming with that restriction. Robert's painful experience > implementing the random number generator in GNAT is all the proof one needs > to justify side-effect producing functions, and modifying the syntax to > call out that fact. And my own experience - innocently calling Random from > a protected function (compiles fine, but doesn't work) - is yet more > evidence. > > The whole point of Ada is to detect "the things that won't work" at compile > time. So now, before implementing a protected function, I have to make > sure that any functions I call aren't causing side effect. With the > current syntax, I can't determine that without reading the body of the > function! The other extreme would be to totally disallow side effects in functions (by not allowing them to write to outside variables, or to do I/O, or to call other subprograms which have (or may have) side-effects). For most functions (Sin, Cos, Tan, etc.) this would be no problem. For a function such as Random, it would be impossible (a procedure would have to be used instead). I'm not really advocating this idea: I recognise that it would be just too impractical in some situations. (R. D. would presumably burst a blood vessel! :-) However, note that the widespread compiler-evaluation of functions would be possible, if they could all be guaranteed not to have side-effects (and provided their evaluation did not take too long). Does anyone know of any Ada compiler which performs this optimisation for subprograms which can be deduced to be 'independent' (definitely having no side-effects)? Would such an optimisation be useful? Would it be practicable? Wouldn't it be helpful if the compiler gave a warning whenever a non-independent function was declared inside a protected object? Comments invited! Nick.