Re: "functional" programming in Ada

["Alejandro R. Mosteo" <alejandro@mosteo.com>]

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 ;)