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-Thread: 103376,8f802583e5c84fa X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!newscon02.news.prodigy.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: String filtering Date: 04 Oct 2005 13:00:44 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1j92wa9843ylq.16j89wuqatbaj$.dlg@40tude.net> <1b54lwg8s1gk8.1t3jp1cmc2x32$.dlg@40tude.net> <1128236249.692858.50370@g14g2000cwa.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1128445244 20929 192.74.137.71 (4 Oct 2005 17:00:44 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 4 Oct 2005 17:00:44 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:5381 Date: 2005-10-04T13:00:44-04:00 List-Id: Jacob Sparre Andersen writes: > Robert A Duff wrote: > > Steve Whalen wrote: > > >> I seem to have been brainwashed into thinking that functions with > >> side effects of any kind were a "bad thing", especially in a > >> language like Ada. > > > > I think that side effects in functions are usually a bad idea. > > But not always. > > My whole understanding of the concept "a function" is that it doesn't > have side effects. - But I'm a mathematician (and physicist), not a > computer scientist. Yes, of course. But what Ada calls a "function" is not (necessarily) a maths function. (And what Ada calls "Integer" is not what a mathematician calls "integer". Ada is not the first language to misuse maths terminology.) Anyway, if you want to calculate (say) the Nth Fibonacci number, you can say: function Fib(N: ...) return ...; or: procedure Fib(N: ...; Result: out ...); Progammer's choice. They're just two different notations for doing the same thing. And they both calculate a result that is a _function_ (in the maths sense) of N. If I ran the circus, I would call both kinds of subprograms "procedures" and use the reserved word "procedure" for both syntaxes. What Ada calls "function" I would call "value-returning procedure". In many cases, there are advantages to using the value-returning notation. As I said in my previous not, these advantages _usually_ apply in side-effect-free cases, but not always (IMHO of course). Now that I think about it: one of my examples of OK side effects was reading tokens from a stream. From one point of view, that's side-effectful -- input is consumed. But from another point of view, the sequence of tokens produced is a (maths) function of the input sequence. > > I think the programmer, not the language designer, should make such > > decisions. I like restrictive rules that prevent me (as a > > programmer) from doing bad things by accident. But I don't like > > restrictive rules that try to prevent me from doing things I > > deliberately choose to do. > > The problem is then to introduce a way to make it clear if you want a > function to have side effects or not. Just coding a function with > side effects isn't the most clear way to do it (although using an "in > out" parameter is pretty close). Would it be to go too far to have to > specify functions as either: > > function Name (...) return Subtype; > > or: > > function Name with side effects (...) Subtype; Maybe, but that would require massive changes to Ada. You would need to make global variable access part of the contract of each subprogram. SPARK does that, but it has no pointers, which makes the job a lot simpler. Also, you would want a way to "cheat". My example of "Intern" should be considered a pure function, but internally, it has side effects (which are invisible to the client). Memoizing functions are another example. > > We can solve this in Ada by adding various levels of indirection, > > which is rather a pain. For example, the "Rosen trick". > > Would it be possible to tighten the rules for functions without side > effects to prevent the "Rosen trick"? Or will that workaround > effectively always be possible? Well, Dmitry gave some ideas of how to go about outlawing the Rosen trick in cases where that's desirable. Something like that might work. - Bob P.S. Ada function take time to evaluate. Maths functions do not -- they just "exist". There's no way you're going to eliminate _that_ side effect! And it matters, at least in real-time systemss.