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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: "Alejandro R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: "functional" programming in Ada Date: Wed, 7 Mar 2018 16:03:27 +0100 Organization: A noiseless patient Spider Message-ID: References: <896b83c6-83d4-4ffc-8c56-1481802ea8fd@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 7 Mar 2018 15:03:27 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="2be4ab457d552c4d2afda3fc1fe39c2c"; logging-data="29175"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18PGHTHC/lb/kRah1ydXelI" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 In-Reply-To: <896b83c6-83d4-4ffc-8c56-1481802ea8fd@googlegroups.com> Content-Language: en-US Cancel-Lock: sha1:ubyo9VhNnEcZvYPVRe03cQHgqWc= Xref: reader02.eternal-september.org comp.lang.ada:50878 Date: 2018-03-07T16:03:27+01:00 List-Id: On 07/03/18 11:07, Maciej Sobczak wrote: > On Tuesday, March 6, 2018 at 12:34:32 PM UTC+1, Alejandro R. Mosteo wrote: > >> I'm writing more code in declarative parts. > > It is interesting how language evolution leads to mixing of ideas or even dropping of original values. > If you write code in declarative parts (which also includes calling functions and using complex expressions to initialize variables at the point of declaration), then Ada might as well abandon the whole concept of dividing the code into declarative and imperative parts. If you can implement your whole system in the declarative part, then this division does not make sense any longer. That's an interesting point. I'm not sure the declare - begin part is that critical, since scopes are defined between begin - end anyway (which is frustrating for exceptions sometimes, when you want to ensure a subprogram won't raise from its declarative part). Yet I wouldn't say that the new features are fundamentally tipping the scales; as you say you could always use functions in initializations, and I don't like writing complex expressions anyway (a single if/then/else or case at most; once nesting is needed it usually is reason enough to stop to think about what I'm doing). At the moment my personal opinion is that the discussed features make writing Ada considerably more comfortable [*], with only a small additional risk of bad style, but not inherently unsafer code. My only reservation, as I said, is allowing expression function bodies (not pre/post conditions) in public parts. Could this restriction have been enforced, or was it even on the table at some point? Probably I'm missing some reason for why it is not. [*] Then only exception is that current gnat won't warn you about a missing body in a spec, when there is no body file yet. So you write a declaration for a function that you know is going to be an expression, forget to write it in the private part, and when compilation fails you have no idea of what function is missing, unless you create an empty body just to check. In files with many declarations it's bitten me a couple of times. > The argument about tools using these expressions (in contracts, for example) is interesting as well, because tools also benefit from simpler grammar and strict code structure. Apparently there is no single formula for a perfect language! > > My (current[*]) own preference is to avoid mixing programming styles in a single language and instead mix languages in a single system. In addition to forcing me to put more thought into the design, it also makes language purists happy. :-) If you find it funny to write in functional style, why not compose your system from parts written in Ada with parts written in [put your *other* favorite language here]? Why abuse a single language to do what it was not originally supposed to do? He, I'm not a purist so I'll take what I'm given. That said, my old and limited experience with Lisp was that its easier to do some functional-like things in an imperative language, whereas when going fully functional you sorely miss some imperative facilities sooner than later. But this is probably that my first languages were imperative so I'm biased. Recommendations for current functional languages? I know only of Haskell (and only by name). > [*] Disclaimer: current preferences become obsolete with time. I reserve full rights to change my mind in the next post. Duly noted ;)