"functional" programming in Ada

"functional" programming in Ada

[Alejandro R. Mosteo]

In a recent project I've started using in full if/case expressions and 
expression functions... and I'm a bit scared at the amount of use I have 
for them. I'm using these constantly.

Pros: purely recursive functions are really fun to write. If/case 
expressions, used sparingly, do help a lot in having constant 
declarations in local scopes. I'm writing more code in declarative parts.

Cons: the temptation of writing function bodies in the spec is too big. 
At least I try to keep them in the private part, but I've found myself 
trying to force an expression function just to avoid a package body.

Care to share your experiences?

Álex.

Re: "functional" programming in Ada

[Dmitry A. Kazakov]

On 06/03/2018 12:34, Alejandro R. Mosteo wrote:
> In a recent project I've started using in full if/case expressions and 
> expression functions... and I'm a bit scared at the amount of use I have 
> for them. I'm using these constantly.

That is how wrong ideas become most popular ones.

> Pros: purely recursive functions are really fun to write. If/case 
> expressions, used sparingly, do help a lot in having constant 
> declarations in local scopes. I'm writing more code in declarative parts.
> 
> Cons: the temptation of writing function bodies in the spec is too big. 
> At least I try to keep them in the private part, but I've found myself 
> trying to force an expression function just to avoid a package body.
> 
> Care to share your experiences?

Better not to have any.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: "functional" programming in Ada

[Alejandro R. Mosteo]

On 06/03/18 14:09, Dmitry A. Kazakov wrote:
> On 06/03/2018 12:34, Alejandro R. Mosteo wrote:
>> In a recent project I've started using in full if/case expressions and 
>> expression functions... and I'm a bit scared at the amount of use I 
>> have for them. I'm using these constantly.
> 
> That is how wrong ideas become most popular ones.

Do you find something inherently wrong, or is this particular 
implementation you object to?

>> Pros: purely recursive functions are really fun to write. If/case 
>> expressions, used sparingly, do help a lot in having constant 
>> declarations in local scopes. I'm writing more code in declarative parts.
>>
>> Cons: the temptation of writing function bodies in the spec is too 
>> big. At least I try to keep them in the private part, but I've found 
>> myself trying to force an expression function just to avoid a package 
>> body.
>>
>> Care to share your experiences?
> 
> Better not to have any.

:-)

Re: "functional" programming in Ada

[Dmitry A. Kazakov]

On 06/03/2018 15:35, Alejandro R. Mosteo wrote:
> On 06/03/18 14:09, Dmitry A. Kazakov wrote:
>> On 06/03/2018 12:34, Alejandro R. Mosteo wrote:
>>> In a recent project I've started using in full if/case expressions 
>>> and expression functions... and I'm a bit scared at the amount of use 
>>> I have for them. I'm using these constantly.
>>
>> That is how wrong ideas become most popular ones.
> 
> Do you find something inherently wrong,

Yes, both functional programming paradigm and ways to break out of it. 
The latter is doubly wrong. If functional programming is so cool why 
would anybody wrap procedural building blocks into functional ones?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: "functional" programming in Ada

[Manuel Collado]

El 06/03/2018 a las 16:08, Dmitry A. Kazakov escribió:
> On 06/03/2018 15:35, Alejandro R. Mosteo wrote:
>>
>> Do you find something inherently wrong,
>
> Yes, both functional programming paradigm and ways to break out of it.
> The latter is doubly wrong. If functional programming is so cool why
> would anybody wrap procedural building blocks into functional ones?
>

Well, it may sound a bit heterodox, but IMHO functional programming is 
just a subset of imperative (= procedural) programming.

- Functional programming = expressions
- Imperative programming = expressions + variables + procedural actions

So why avoid the power of some functional programming expressions in the 
imperative programming world?

Just my 2c.
-- 
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado

Re: "functional" programming in Ada

[Dmitry A. Kazakov]

On 06/03/2018 17:00, Manuel Collado wrote:
> El 06/03/2018 a las 16:08, Dmitry A. Kazakov escribió:
>> On 06/03/2018 15:35, Alejandro R. Mosteo wrote:
>>>
>>> Do you find something inherently wrong,
>>
>> Yes, both functional programming paradigm and ways to break out of it.
>> The latter is doubly wrong. If functional programming is so cool why
>> would anybody wrap procedural building blocks into functional ones?
>>
> 
> Well, it may sound a bit heterodox, but IMHO functional programming is 
> just a subset of imperative (= procedural) programming.
> 
> - Functional programming = expressions
> - Imperative programming = expressions + variables + procedural actions

Imperative is in opposition to declarative. Another axis is stateless 
vs. stateful. Procedural is usually attributed to the method of 
decomposition: procedural vs. object vs. functional vs. data/event 
driven etc.

Ada used to strictly separate imperative from declarative and took care 
about the states, especially about the correspondence between the 
program state and problem domain. Then Ada supported both procedural and 
object decomposition, even Ada 83 with its abstract data types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: "functional" programming in Ada

[Manuel Collado]

El 06/03/2018 a las 17:37, Dmitry A. Kazakov escribió:
> On 06/03/2018 17:00, Manuel Collado wrote:
>>
>> Well, it may sound a bit heterodox, but IMHO functional programming is
>> just a subset of imperative (= procedural) programming.
>>
>> - Functional programming = expressions
>> - Imperative programming = expressions + variables + procedural actions
>
> Imperative is in opposition to declarative. Another axis is stateless
> vs. stateful. Procedural is usually attributed to the method of
> decomposition: procedural vs. object vs. functional vs. data/event
> driven etc.
>
> Ada used to strictly separate imperative from declarative and took care
> about the states, especially about the correspondence between the
> program state and problem domain. Then Ada supported both procedural and
> object decomposition, even Ada 83 with its abstract data types.

Did I mentioned the word "declarative"?

Functional and declarative are different axis. Fans of functional 
programming claim it is declarative "per se". Not me.

Expressions without side-effects are functional, and not necessarily 
declarative. Prolog is declarative, and not functional.

Regards.
-- 
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado

Re: "functional" programming in Ada

[Dmitry A. Kazakov]

On 06/03/2018 23:16, Manuel Collado wrote:
> El 06/03/2018 a las 17:37, Dmitry A. Kazakov escribió:
>> On 06/03/2018 17:00, Manuel Collado wrote:
>>>
>>> Well, it may sound a bit heterodox, but IMHO functional programming is
>>> just a subset of imperative (= procedural) programming.
>>>
>>> - Functional programming = expressions
>>> - Imperative programming = expressions + variables + procedural actions
>>
>> Imperative is in opposition to declarative. Another axis is stateless
>> vs. stateful. Procedural is usually attributed to the method of
>> decomposition: procedural vs. object vs. functional vs. data/event
>> driven etc.
>>
>> Ada used to strictly separate imperative from declarative and took care
>> about the states, especially about the correspondence between the
>> program state and problem domain. Then Ada supported both procedural and
>> object decomposition, even Ada 83 with its abstract data types.
> 
> Did I mentioned the word "declarative"?
> 
> Functional and declarative are different axis. Fans of functional 
> programming claim it is declarative "per se". Not me.
> 
> Expressions without side-effects are functional, and not necessarily 
> declarative.

Absence of side-effects does not make it functional:

    procedure Swap (X, Y : in out Integer);

is imperative and has no side-effects.

Stateless constructs, if that fiction exists, are functional and 
necessarily declarative.

But I would attribute "functional" rather to the decomposition method. 
Other attributes are more of less consequences of choice. Standing on 
your head, changes the gait... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: "functional" programming in Ada

[Paul Rubin]

Manuel Collado <m-collado@users.sourceforge.net> writes:
> Well, it may sound a bit heterodox, but IMHO functional programming is
> just a subset of imperative (= procedural) programming.
>
> - Functional programming = expressions
> - Imperative programming = expressions + variables + procedural actions

By that logic, typed programming is just a subset of untyped
programming.

 - (sufficiently) typed programming = expressions with well-defined values
   
 - untyped programming: expressions with well-defined values +
   expressions with undefined values + arbitrary pointers and memory
   corruption
    
> So why avoid the power of some functional programming expressions in
> the imperative programming world?

Because eliminating dangerous features from a language can increase its
safety, predicability, etc.  Whether that applies to functional vs Ada
depends on a lot of things, but the generalization you seem to suppose
(that adding more power never does harm) makes no sense.

Re: "functional" programming in Ada

[Mehdi Saada]

I so understand you Alexandro !
But I wonder why they even allowed to write these expression bodies in the specs.

Re: "functional" programming in Ada

[Alejandro R. Mosteo]

On 06/03/18 14:29, Mehdi Saada wrote:
> I so understand you Alexandro !
> But I wonder why they even allowed to write these expression bodies in the specs.

 From a compiler writer POV I may understand it for the same reasons we 
have the private part in the spec. But I'm kind of wishing that they 
were forcefully confined to the private part.

Re: "functional" programming in Ada

[Mehdi Saada]

> From a compiler writer POV I may understand it for the same reasons we 
> have the private part in the spec.
How come ? Why should the compiler handle those functions differently than normal functions whose body is forbidden to be anywhere else than in the package body ?

Re: "functional" programming in Ada

[Alejandro R. Mosteo]

On 06/03/18 15:36, Mehdi Saada wrote:
>>  From a compiler writer POV I may understand it for the same reasons we
>> have the private part in the spec.
> How come ? Why should the compiler handle those functions differently than normal functions whose body is forbidden to be anywhere else than in the package body ?
> 

I suppose they simplify distribution of specs + object code with better 
inlining, but that's just a guess.

Re: "functional" programming in Ada

[Jeffrey R. Carter]

On 03/06/2018 03:36 PM, Mehdi Saada wrote:
>>  From a compiler writer POV I may understand it for the same reasons we
>> have the private part in the spec.
> How come ? Why should the compiler handle those functions differently than normal functions whose body is forbidden to be anywhere else than in the package body ?

According to the Ada-12 Rationale, expression functions were added to help with 
contracts.

-- 
Jeff Carter
"He that hath no beard is less than a man."
Much Ado About Nothing
132

Re: "functional" programming in Ada

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:cd48925d-5cac-465c-96c3-a392f0ce4079@googlegroups.com...
>> From a compiler writer POV I may understand it for the same reasons we
>> have the private part in the spec.
> How come ? Why should the compiler handle those functions differently
> than normal functions whose body is forbidden to be anywhere else than in 
> the package body ?

It helps other (non-Ada) tools; in particular proof and analysis tools, if 
the entire details of a precondition/postcondition are available to the 
tools (and without depending on contents of bodies). This literally led to 
preconditions that were many pages long. Expression functions were 
introduced in part to allow some abstraction in contracts without hiding the 
details of thosee contracts from the tools.

Secondarily, a compiler can take advantage of these for better inlining and 
better optimization of contracts. [The real reason I was interested.] They 
also open up some other possibilities (not all taken advantage of yet): 
user-defined static expressions; default implementation of functions for 
interfaces; anonymous functions to pass for one-time use parameters.

Generally, I'd expect them to appear mainly in private parts, because the 
visible spec shouldn't include enough info to be able to usefully implement 
much -- you usually need access to the components of the central private 
type in order to write such a function.

They *are* tempting to use, especially in quick-and-dirty code (like ACATS 
tests). I've found myself having to remove them from tests that are supposed 
to work on Ada 95 or Ada 2005.

                             Randy.

Re: "functional" programming in Ada

[Alejandro R. Mosteo]

On 06/03/18 21:17, Randy Brukardt wrote:

> Generally, I'd expect them to appear mainly in private parts, because the
> visible spec shouldn't include enough info to be able to usefully implement
> much -- you usually need access to the components of the central private
> type in order to write such a function.

Unless you find yourself writing functions that depend on other 
functions (possibly even from other packages), and then you are no 
longer restricted by private components...

At least that's what's happening to me.

Álex.

"functional" programming in Ada

[Dan'l Miller]

Alejandro R. Mosteo wrote:
> Pros: purely recursive functions are really fun to write. If/case 
> expressions, used sparingly, do help a lot in having constant 
> declarations in local scopes. I'm writing more code in declarative parts. 

Be careful or else you will be yearning to write in Ada the full-fledged meta-template programming abomination that C++ has become in the past decade and a half.  If the Ada community were to ever want to have functional programming within Ada (as opposed to, say, bolting Ada & Haskell or Ada & OCaml together better), especially compile-time functional programming in Ada, then it should be overtly well-designed to walk in the front door, not sneak in the backdoor as it did in C++ when they/Alexandrescu ‘discovered’ that C++'s templates/generics were (just barely) Turing complete with syntax-as-nearly-unreadable-subtext that is perhaps even more cryptic than infinite-length tapes in a Turing machine.

Re: "functional" programming in Ada

[Alejandro R. Mosteo]

On 06/03/18 16:01, Dan'l Miller wrote:
> Alejandro R. Mosteo wrote:
>> Pros: purely recursive functions are really fun to write. If/case
>> expressions, used sparingly, do help a lot in having constant
>> declarations in local scopes. I'm writing more code in declarative parts.
> 
> Be careful or else you will be yearning to write in Ada the full-fledged meta-template programming abomination that C++ has become in the past decade and a half.  If the Ada community were to ever want to have functional programming within Ada (as opposed to, say, bolting Ada & Haskell or Ada & OCaml together better), especially compile-time functional programming in Ada, then it should be overtly well-designed to walk in the front door, not sneak in the backdoor as it did in C++ when they/Alexandrescu ‘discovered’ that C++'s templates/generics were (just barely) Turing complete with syntax-as-nearly-unreadable-subtext that is perhaps even more cryptic than infinite-length tapes in a Turing machine.
> 

There's a reason I quoted the functional in the subject ;-)

I share the feeling nonetheless, I'm no fan (to put it mildly) of C++ 
template metaprogramming,

Re: "functional" programming in Ada

[Maciej Sobczak]

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.

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?

[*] Disclaimer: current preferences become obsolete with time. I reserve full rights to change my mind in the next post.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: "functional" programming in Ada

[Mehdi Saada]

I am myself a purist in becoming, but I'm curious as to the statement of Randy, that such constructions that mix bodies and specs, like expression functions, allow better analysis from tools.
Why not writing everything in the specs then ? Maybe the original separation of specs and bodies is a mistake, in the light of recent tools requirements.
... I'm just playing devil's advocate, don't shoot.

Re: "functional" programming in Ada

[Pascal Obry]

Le mercredi 07 mars 2018 à 02:52 -0800, Mehdi Saada a écrit :
> Why not writing everything in the specs then ? Maybe the original
> separation of specs and bodies is a mistake, in the light of recent
> tools requirements.

The spec is what is exposed to other units.

The body is implementation details.

The separation is to me one of the most important point in Ada. I think
that all languages should have done that. It is an welcomed separation
for software engineer.

My 2 cents,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: "functional" programming in Ada

[Dmitry A. Kazakov]

On 07/03/2018 14:11, Pascal Obry wrote:
> Le mercredi 07 mars 2018 à 02:52 -0800, Mehdi Saada a écrit :
>> Why not writing everything in the specs then ? Maybe the original
>> separation of specs and bodies is a mistake, in the light of recent
>> tools requirements.
> 
> The spec is what is exposed to other units.
> 
> The body is implementation details.

Specification can be an implementation detail for some clients. That is 
why Ada has public and private parts.

> The separation is to me one of the most important point in Ada. I think
> that all languages should have done that. It is an welcomed separation
> for software engineer.

Yes. The principle is reducing coupling. Therefore anything the client 
does not need should be hidden from it. A related principle is having 
weakest possible preconditions. All things a client can see become 
precondition and thus strengthen it.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: "functional" programming in Ada

[Dan'l Miller]

Pascal Obry wrote:
> The •spec• is what is ••exposed to other units••. 
>
> The •body• is ••implementation•• details. 
>
> The separation is to me one of the most important point in Ada.

The separation is important in •modern Ada•.  Historically, {Rational's, Sun Microsystems'} Verdix Ada Development System (VADS) compiler had a #-prefixed compile-time subset of Ada 1) that played some role as a superduper extrapolation of what C or C++ use their preprocessor for and 2) that played some role as a source-code-reflective compile-time code generator à la OCaml's camlp4 does nowadays for OCaml.  In this alternative view, conversely:

The •spec• is what is the ••compiler•• is fully cognizant of at strictly compile-time.

The •body• is what only the ••hardware processor•• is fully cognizant of at run-time, most especially execution-time accumulated-state behaviors based on one or more execution-time inputs.

(And there might exist people who say that Pascal Obry's and Dan'l Miller's different wording there means exactly the same thing in the end.  On even-numbered days, I am one of those people.  Conversely, on odd-numbered days, I vociferously object!)

>  I think that all languages should have done that.

Some people (e.g., the Boost community over in C++ world; the users of camlp4 as a code generator in OCaml world; the a.app people in a prior Ada era; to some degree, the aspect-oriented programming [AOP] people) believe that compiled languages should have a compiler-internal compile-time ‘language’ in which poor-man's code generation/tweaking/trait-based-selection or full-fledged code generation can be expressed as imperative and/or functional code that the compiler invokes at compile-time to tailor/weave the source code to be automatedly different than what  a human being submitted as input to the compiler.  The burning question of our era is, ‘who gets to author code:  human or (multistage-)compiler or both’?  The school of thought that fully embraces this (with perhaps even more than 2 stages:  compile-time & run-time mentioned so far here) is multi-stage programming, where an app's source code may beget source-code generation may beget source-code generation may beget ... may beget source-code generation may beget compiled machine code.  (In some variants, replace at least some of those “source-code generation” phrases with ‘intermediate-representation generation’ phrases there.)

Because C++, OCaml, AOP aspect weavers for various languages, and an earlier a.app era of Ada keep reinventing this wheel (differently), apparently there exist people spanning several decades who “think all languages should have done that”, where “that” is having a compile-time language of some sort governing/tuning/tweaking/extending the compiler's ability to generate machine code from human-authored/non-generated source code.  (To varying degrees, Seed7, 1970's era Alphard ,and the ‘little languages’ subset of the OCaml community even go so far as to say that the human-being author of an app should be able to declare fresh novel syntax & semantics of the app's source code to the compiler, instead of having, say, Ada's syntax & semantics chiseled in stone by a committee.)

> It is an welcomed separation for software engineer. 

The existence of the (highly impaired) C preprocessor, Ocaml's camlp4, VADS's a.app, AOP's aspect weavers, and C++'s Boost metatemplate programming all point that compile-time-invoked source code versus run-time-invoked source code in compilers is “a[] welcomed separation for [some] software engineer[s].”

Rather than advocating all this, I am merely pointing out extant facts.  I am quite appalled at what this compile-time-code school of thought has done to C++'s readability (and perhaps a few other software-architectural -abilities regarding C++) by sneaking it in the back door via their ‘discovery’ that C++'s templates are (just barely) Turing complete.  Conversely, I am quite an admirer of full-fledged much-more-readable walk-in-the-front-door multi-stage programming's 1 or more stages of source-code generation then machine-code generation, preferably within the same language with immense amounts of reflection and self-reflection-based analysis and grinding; OCaml world (and perhaps some of the Java-based aspect weavers of AOP-of-Java) perform this much more admirably than, say, poor-man MTP in C++ does.

I mention all of this, so that Ada community is aware of slopes that they might be standing on, so as to not make them slippery, as C++ did.

Re: "functional" programming in Ada

[Robert I. Eachus]

On 3/7/2018 11:13 AM, Dan'l Miller wrote:

> I mention all of this, so that Ada community is aware of slopes that they might be standing on, so as to not make them slippery, as C++ did.
> 

There was a time when this was well accepted by the Ada community.  If 
you are designing a languages where ease of reading is considered much 
more important than ease of writing, it is obvious that having two 
distinct languages not only mixed on the page, but even on the same 
lines, and requiring the reader to parse potentially many lines to 
assign tokens to languages is not the way to go.

Yes, Ada does have modes, but they can usually be determined by looking 
at a single reserved word. A sequence of statements begins with begin, 
and a sequence of declarations begins with declare or is.

Re: "functional" programming in Ada

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1785 bytes --]


"Pascal Obry" <pascal@obry.net> wrote in message 
news:1520428274.2488.155.camel@obry.net...
Le mercredi 07 mars 2018 à 02:52 -0800, Mehdi Saada a écrit :
>> Why not writing everything in the specs then ? Maybe the original
>> separation of specs and bodies is a mistake, in the light of recent
>> tools requirements.
>
>The spec is what is exposed to other units.
>
>The body is implementation details.
>
>The separation is to me one of the most important point in Ada. I think
>that all languages should have done that. It is an welcomed separation
>for software engineer.

Right. And note that the specification has always contained elements which 
are determined at runtime (that is, executed). For instance, even in Ada 83 
you could have a subtype like:

      subtype Dyn is Natural range 1 .. Some_Function;

and to properly export Dyn, one has to execute code.

The various contracts (preconditions, postconditions, predicates, etc.) all 
contain some executable code, and it is necessary for callers to be able to 
understand those contracts. Expression functions help in this, while the 
bulk of the implementation should remain in the body.

While the line separating the specification and the implementation is very 
important, it is also a blurry line (and always has been). Also note that 
the private part is effectively part of the body (that is, the 
implementation part), and that is where 95% of expression functions end up. 
So while they are physically in the source code of the specification, they 
still belong to the body. (The private part, after all, is a hack to ease 
implementation. Expression functions are similar in a way, although it is 
not the Ada implementation that they are intended to help.)

                                          Randy.

Re: "functional" programming in Ada

[Dmitry A. Kazakov]

On 08/03/2018 04:34, Randy Brukardt wrote:
> "Pascal Obry" <pascal@obry.net> wrote in message
> news:1520428274.2488.155.camel@obry.net...
> Le mercredi 07 mars 2018 à 02:52 -0800, Mehdi Saada a écrit :
>>> Why not writing everything in the specs then ? Maybe the original
>>> separation of specs and bodies is a mistake, in the light of recent
>>> tools requirements.
>>
>> The spec is what is exposed to other units.
>>
>> The body is implementation details.
>>
>> The separation is to me one of the most important point in Ada. I think
>> that all languages should have done that. It is an welcomed separation
>> for software engineer.
> 
> Right. And note that the specification has always contained elements which
> are determined at runtime (that is, executed). For instance, even in Ada 83
> you could have a subtype like:
> 
>        subtype Dyn is Natural range 1 .. Some_Function;
> 
> and to properly export Dyn, one has to execute code.

Determined at run-time /= determined in a specific way. Even if 
evaluation of an expression is static, when that expression is an 
implementation, that thing has *nothing* to seek in the specifications. 
Specifications must be only specifications regardless when and how 
evaluated.

> The various contracts (preconditions, postconditions, predicates, etc.) all
> contain some executable code, and it is necessary for callers to be able to
> understand those contracts. Expression functions help in this, while the
> bulk of the implementation should remain in the body.

These are not contracts if have any executable code, and more 
importantly, understanding cannot be achieved by exposing 
implementation/code.

P.S. Contracts exist prior the program (programs, actuall) and surely 
prior to any execution of (any implementation of any programs under the 
contract).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: "functional" programming in Ada

[G. B.]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 08/03/2018 04:34, Randy Brukardt wrote:
>> The various contracts (preconditions, postconditions, predicates, etc.) all
>> contain some executable code, and it is necessary for callers to be able to
>> understand those contracts. Expression functions help in this, while the
>> bulk of the implementation should remain in the body.
> 
> These are not contracts if have any executable code, and more 
> importantly, understanding cannot be achieved by exposing 
> implementation/code.
> 
> P.S. Contracts exist prior the program (programs, actuall) and surely 
> prior to any execution of (any implementation of any programs under the 
> contract).
> 

If there is nothing that ever assigns a value to a contract’s
clause, then there id none. So, in order make it something,
an evaluation of clauses needs to be performed. Somewhere,
somehow. My brain is operating when doing this, or so I hope, 
and whenever it does following discipline, then it is executing 
a program.

The troublesome idea is to think that the program 
and its contract are like “x ε x”, or like recursive types.

Re: "functional" programming in Ada

[Dmitry A. Kazakov]

On 08/03/2018 23:49, G. B. wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 08/03/2018 04:34, Randy Brukardt wrote:
>>> The various contracts (preconditions, postconditions, predicates, etc.) all
>>> contain some executable code, and it is necessary for callers to be able to
>>> understand those contracts. Expression functions help in this, while the
>>> bulk of the implementation should remain in the body.
>>
>> These are not contracts if have any executable code, and more
>> importantly, understanding cannot be achieved by exposing
>> implementation/code.
>>
>> P.S. Contracts exist prior the program (programs, actuall) and surely
>> prior to any execution of (any implementation of any programs under the
>> contract).
>>
> 
> If there is nothing that ever assigns a value to a contract’s
> clause, then there id none. So, in order make it something,
> an evaluation of clauses needs to be performed. Somewhere,
> somehow. My brain is operating when doing this, or so I hope,
> and whenever it does following discipline, then it is executing
> a program.
> 
> The troublesome idea is to think that the program
> and its contract are like “x ε x”, or like recursive types.

Yes, unless the types algebra is clearly separated from the language 
enough for the recursion to start and end before it comes to any use of 
the type.

Anyway, since type contracts are most important ones, it is difficult to 
accept recursive definitions of types (as well as pattern matched types 
or templates beyond trivial) because they make it for the reader to 
understand the meaning of the contract.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: "functional" programming in Ada

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On 08/03/2018 04:34, Randy Brukardt wrote:
[...]
>> The various contracts (preconditions, postconditions, predicates,
>> etc.) all contain some executable code, and it is necessary for
>> callers to be able to understand those contracts. Expression
>> functions help in this, while the bulk of the implementation should
>> remain in the body.
>
> These are not contracts if have any executable code, and more
> importantly, understanding cannot be achieved by exposing
> implementation/code.
>
> P.S. Contracts exist prior the program (programs, actuall) and surely
> prior to any execution of (any implementation of any programs under
> the contract).

When I was taught VDM (a long time ago, and never put to actual project
use) we wrote what are essentially contracts. You'd be left to implement
the corresponding code following the contracts.

Pre/postconditions etc correspond to these contracts, in a potentially
executable form, and I'm going to call them contracts as a convenient
shorthand (as in the Rationale).

As you know, the meaning of the program mustn't depend on actually
executing the contracts, and the default GNAT behaviour is not to
generate executable code for them (I don't know whether expression
functions which are only involved in contracts actually generate object
code, but one would hope they'd be eliminated by compiler analysis).

An expression function in the spec has to help in understanding what the
contract says. I wondered whether it might correspond to a lemma? ("a
subsidiary proposition , proved for use in the proof of another
proposition").

Re: "functional" programming in Ada

[Dmitry A. Kazakov]

On 09/03/2018 09:40, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> On 08/03/2018 04:34, Randy Brukardt wrote:
> [...]
>>> The various contracts (preconditions, postconditions, predicates,
>>> etc.) all contain some executable code, and it is necessary for
>>> callers to be able to understand those contracts. Expression
>>> functions help in this, while the bulk of the implementation should
>>> remain in the body.
>>
>> These are not contracts if have any executable code, and more
>> importantly, understanding cannot be achieved by exposing
>> implementation/code.
>>
>> P.S. Contracts exist prior the program (programs, actuall) and surely
>> prior to any execution of (any implementation of any programs under
>> the contract).
> 
> When I was taught VDM (a long time ago, and never put to actual project
> use) we wrote what are essentially contracts. You'd be left to implement
> the corresponding code following the contracts.
> 
> Pre/postconditions etc correspond to these contracts, in a potentially
> executable form, and I'm going to call them contracts as a convenient
> shorthand (as in the Rationale).

Proper pre/post conditions are propositions to be used ("executed") in 
the logical inference/proof. They define the contract.

If an expression is used to define a contract, that contract is 
obviously undefined until the expression evaluated.

> As you know, the meaning of the program mustn't depend on actually
> executing the contracts, and the default GNAT behaviour is not to
> generate executable code for them (I don't know whether expression
> functions which are only involved in contracts actually generate object
> code, but one would hope they'd be eliminated by compiler analysis).

And if not?

> An expression function in the spec has to help in understanding what the
> contract says. I wondered whether it might correspond to a lemma? ("a
> subsidiary proposition , proved for use in the proof of another
> proposition").

There are propositions, theorems, lemmas. And there are algorithms, 
instructions etc. The former are never the latter and conversely. 
Expression-function can be either. That depends on the language we are 
talking about: #1 an expression of the meta-language of contracts or #2 
an expression of the object language Ada.

Now the point is that even if an expression-function were a part of the 
language of contracts, then that is still bad idea because the language 
design principles should hold for both languages. If the meta language 
of contracts becomes so complex that it would require procedural 
decomposition, then that must be done in a sane way, with separating 
interfaces and implementations. The contract-function would have bodies 
defined elsewhere rather than clumped together with specification.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: "functional" programming in Ada

[Alejandro R. Mosteo]

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

Re: "functional" programming in Ada

[Alejandro R. Mosteo]

On 07/03/18 16:03, Alejandro R. Mosteo wrote:
> 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).

I when to write some code and quickly realized why the declare-begin is 
so handy for proper scoping ;)

Re: "functional" programming in Ada

[Robert A Duff]

"Alejandro R. Mosteo" <alejandro@mosteo.com> writes:

> Recommendations for current functional languages? I know only of Haskell
> (and only by name).

OCaml

- Bob

Re: "functional" programming in Ada

[Jeffrey R. Carter]

On 03/07/2018 04:03 PM, Alejandro R. Mosteo wrote:
> 
> Recommendations for current functional languages? I know only of Haskell (and 
> only by name).

Erlang is interesting for an Ada person because it has concurrency in the 
language. Elixir is a similar language that targets the Erlang VM, IIRC.

-- 
Jeff Carter
"I snapped my chin down onto some guy's fist and
hit another one in the knee with my nose."
Play It Again, Sam
129

Re: "functional" programming in Ada

[Shark8]

On Wednesday, March 7, 2018 at 8:03:29 AM UTC-7, Alejandro R. Mosteo wrote:
> 
> Recommendations for current functional languages? I know only of Haskell 
> (and only by name).

Erlang.

Re: "functional" programming in Ada

[Paul Rubin]

"Alejandro R. Mosteo" <alejandro@mosteo.com> writes:
> Recommendations for current functional languages? I know only of
> Haskell (and only by name).

If you want to get a deep understanding of what FP is about as a
programming language topic, I'd go with Haskell.  Be aware that Haskell
does things the way mathematicians do things: very rigorous and precise
at the actual logical level, but more casual and relaxed at the
organizational level.

If you want something more like Ada, i.e. designed with attention to
large-scale engineering features like separating spec from
implementation, try Standard ML or the somewhat looser OCaml.  Either of
these will be a less mathematically rigorous than Haskell at the value
and expression level, but have a much more serious module system,
something like Ada's.

Erlang and Elixir are more like Lisp or Python: they give a very quick
and productive way to get simple things done, without much help for
larger-scale rigor.  The interesting thing about them is their
concurrency system implements what the programmer sees as isolated
lightweight processes communicating by message passing.  That means you
can split a big problem into smaller ones, so you can use low-tech
methods on the small problems, letting the process isolation keep the
subproblem solutions from interfering with each other too much.

FWIW you can think of Erlang as a concurrent Lisp system with a front
end for a funky Prolog-like syntax.  Elixir is the same thing except the
surface syntax is designed to look like Ruby.  There's also LFE
(Lisp-flavored Erlang), same idea except it looks like actual Lisp.

Re: "functional" programming in Ada

[Alejandro R. Mosteo]

On 08/03/18 01:45, Paul Rubin wrote:
> "Alejandro R. Mosteo" <alejandro@mosteo.com> writes:
>> Recommendations for current functional languages? I know only of
>> Haskell (and only by name).

Wow, thank you everybody for the suggestions and explanations. That's a 
bunch of interesting possibilities.

In another life I was proficient in Lisp and Prolog, but now I'm doing 
Ada when not scripting... so there's something attractive in every choice.

I guess I'll wait for some outward influence to push me in an avoidable 
direction ;-)

Álex.

> 
> If you want to get a deep understanding of what FP is about as a
> programming language topic, I'd go with Haskell.  Be aware that Haskell
> does things the way mathematicians do things: very rigorous and precise
> at the actual logical level, but more casual and relaxed at the
> organizational level.
> 
> If you want something more like Ada, i.e. designed with attention to
> large-scale engineering features like separating spec from
> implementation, try Standard ML or the somewhat looser OCaml.  Either of
> these will be a less mathematically rigorous than Haskell at the value
> and expression level, but have a much more serious module system,
> something like Ada's.
> 
> Erlang and Elixir are more like Lisp or Python: they give a very quick
> and productive way to get simple things done, without much help for
> larger-scale rigor.  The interesting thing about them is their
> concurrency system implements what the programmer sees as isolated
> lightweight processes communicating by message passing.  That means you
> can split a big problem into smaller ones, so you can use low-tech
> methods on the small problems, letting the process isolation keep the
> subproblem solutions from interfering with each other too much.
> 
> FWIW you can think of Erlang as a concurrent Lisp system with a front
> end for a funky Prolog-like syntax.  Elixir is the same thing except the
> surface syntax is designed to look like Ruby.  There's also LFE
> (Lisp-flavored Erlang), same idea except it looks like actual Lisp.
> 

Re: "functional" programming in Ada

[G. B.]

Alejandro R. Mosteo <alejandro@mosteo.com> wrote:
> I've found myself 
> trying to force an expression function just to avoid a package body.
> 
> Care to share your experiences?

It all breaks down when I need to “see”
the computation, like when tracing.

Re: "functional" programming in Ada

[Alejandro R. Mosteo]

On 08/03/18 19:24, G. B. wrote:
> Alejandro R. Mosteo <alejandro@mosteo.com> wrote:
>> I've found myself
>> trying to force an expression function just to avoid a package body.
>>
>> Care to share your experiences?
> 
> It all breaks down when I need to “see”
> the computation, like when tracing.

This is something I've experienced too.