* "functional" programming in Ada
@ 2018-03-06 11:34 Alejandro R. Mosteo
2018-03-06 13:09 ` Dmitry A. Kazakov
` (4 more replies)
0 siblings, 5 replies; 39+ messages in thread
From: Alejandro R. Mosteo @ 2018-03-06 11:34 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 11:34 "functional" programming in Ada Alejandro R. Mosteo
@ 2018-03-06 13:09 ` Dmitry A. Kazakov
2018-03-06 14:35 ` Alejandro R. Mosteo
2018-03-06 13:29 ` Mehdi Saada
` (3 subsequent siblings)
4 siblings, 1 reply; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-03-06 13:09 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 11:34 "functional" programming in Ada Alejandro R. Mosteo
2018-03-06 13:09 ` Dmitry A. Kazakov
@ 2018-03-06 13:29 ` Mehdi Saada
2018-03-06 14:34 ` Alejandro R. Mosteo
2018-03-06 15:01 ` Dan'l Miller
` (2 subsequent siblings)
4 siblings, 1 reply; 39+ messages in thread
From: Mehdi Saada @ 2018-03-06 13:29 UTC (permalink / raw)
I so understand you Alexandro !
But I wonder why they even allowed to write these expression bodies in the specs.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 13:29 ` Mehdi Saada
@ 2018-03-06 14:34 ` Alejandro R. Mosteo
2018-03-06 14:36 ` Mehdi Saada
0 siblings, 1 reply; 39+ messages in thread
From: Alejandro R. Mosteo @ 2018-03-06 14:34 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 13:09 ` Dmitry A. Kazakov
@ 2018-03-06 14:35 ` Alejandro R. Mosteo
2018-03-06 15:08 ` Dmitry A. Kazakov
0 siblings, 1 reply; 39+ messages in thread
From: Alejandro R. Mosteo @ 2018-03-06 14:35 UTC (permalink / raw)
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.
:-)
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 14:34 ` Alejandro R. Mosteo
@ 2018-03-06 14:36 ` Mehdi Saada
2018-03-06 15:27 ` Alejandro R. Mosteo
` (2 more replies)
0 siblings, 3 replies; 39+ messages in thread
From: Mehdi Saada @ 2018-03-06 14:36 UTC (permalink / raw)
> 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 ?
^ permalink raw reply [flat|nested] 39+ messages in thread
* "functional" programming in Ada
2018-03-06 11:34 "functional" programming in Ada Alejandro R. Mosteo
2018-03-06 13:09 ` Dmitry A. Kazakov
2018-03-06 13:29 ` Mehdi Saada
@ 2018-03-06 15:01 ` Dan'l Miller
2018-03-06 15:25 ` Alejandro R. Mosteo
2018-03-07 10:07 ` Maciej Sobczak
2018-03-08 18:24 ` G. B.
4 siblings, 1 reply; 39+ messages in thread
From: Dan'l Miller @ 2018-03-06 15:01 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 14:35 ` Alejandro R. Mosteo
@ 2018-03-06 15:08 ` Dmitry A. Kazakov
2018-03-06 16:00 ` Manuel Collado
0 siblings, 1 reply; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-03-06 15:08 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 15:01 ` Dan'l Miller
@ 2018-03-06 15:25 ` Alejandro R. Mosteo
0 siblings, 0 replies; 39+ messages in thread
From: Alejandro R. Mosteo @ 2018-03-06 15:25 UTC (permalink / raw)
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,
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 14:36 ` Mehdi Saada
@ 2018-03-06 15:27 ` Alejandro R. Mosteo
2018-03-06 16:26 ` Jeffrey R. Carter
2018-03-06 20:17 ` Randy Brukardt
2 siblings, 0 replies; 39+ messages in thread
From: Alejandro R. Mosteo @ 2018-03-06 15:27 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 15:08 ` Dmitry A. Kazakov
@ 2018-03-06 16:00 ` Manuel Collado
2018-03-06 16:37 ` Dmitry A. Kazakov
2018-03-07 4:46 ` Paul Rubin
0 siblings, 2 replies; 39+ messages in thread
From: Manuel Collado @ 2018-03-06 16:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 14:36 ` Mehdi Saada
2018-03-06 15:27 ` Alejandro R. Mosteo
@ 2018-03-06 16:26 ` Jeffrey R. Carter
2018-03-06 20:17 ` Randy Brukardt
2 siblings, 0 replies; 39+ messages in thread
From: Jeffrey R. Carter @ 2018-03-06 16:26 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 16:00 ` Manuel Collado
@ 2018-03-06 16:37 ` Dmitry A. Kazakov
2018-03-06 22:16 ` Manuel Collado
2018-03-07 4:46 ` Paul Rubin
1 sibling, 1 reply; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-03-06 16:37 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 14:36 ` Mehdi Saada
2018-03-06 15:27 ` Alejandro R. Mosteo
2018-03-06 16:26 ` Jeffrey R. Carter
@ 2018-03-06 20:17 ` Randy Brukardt
2018-03-07 14:30 ` Alejandro R. Mosteo
2 siblings, 1 reply; 39+ messages in thread
From: Randy Brukardt @ 2018-03-06 20:17 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 16:37 ` Dmitry A. Kazakov
@ 2018-03-06 22:16 ` Manuel Collado
2018-03-07 8:41 ` Dmitry A. Kazakov
0 siblings, 1 reply; 39+ messages in thread
From: Manuel Collado @ 2018-03-06 22:16 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 16:00 ` Manuel Collado
2018-03-06 16:37 ` Dmitry A. Kazakov
@ 2018-03-07 4:46 ` Paul Rubin
1 sibling, 0 replies; 39+ messages in thread
From: Paul Rubin @ 2018-03-07 4:46 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 22:16 ` Manuel Collado
@ 2018-03-07 8:41 ` Dmitry A. Kazakov
0 siblings, 0 replies; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-03-07 8:41 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 11:34 "functional" programming in Ada Alejandro R. Mosteo
` (2 preceding siblings ...)
2018-03-06 15:01 ` Dan'l Miller
@ 2018-03-07 10:07 ` Maciej Sobczak
2018-03-07 10:52 ` Mehdi Saada
2018-03-07 15:03 ` Alejandro R. Mosteo
2018-03-08 18:24 ` G. B.
4 siblings, 2 replies; 39+ messages in thread
From: Maciej Sobczak @ 2018-03-07 10:07 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-07 10:07 ` Maciej Sobczak
@ 2018-03-07 10:52 ` Mehdi Saada
2018-03-07 13:11 ` Pascal Obry
2018-03-07 15:03 ` Alejandro R. Mosteo
1 sibling, 1 reply; 39+ messages in thread
From: Mehdi Saada @ 2018-03-07 10:52 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-07 10:52 ` Mehdi Saada
@ 2018-03-07 13:11 ` Pascal Obry
2018-03-07 13:53 ` Dmitry A. Kazakov
` (2 more replies)
0 siblings, 3 replies; 39+ messages in thread
From: Pascal Obry @ 2018-03-07 13:11 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-07 13:11 ` Pascal Obry
@ 2018-03-07 13:53 ` Dmitry A. Kazakov
2018-03-07 16:13 ` Dan'l Miller
2018-03-08 3:34 ` Randy Brukardt
2 siblings, 0 replies; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-03-07 13:53 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 20:17 ` Randy Brukardt
@ 2018-03-07 14:30 ` Alejandro R. Mosteo
0 siblings, 0 replies; 39+ messages in thread
From: Alejandro R. Mosteo @ 2018-03-07 14:30 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-07 10:07 ` Maciej Sobczak
2018-03-07 10:52 ` Mehdi Saada
@ 2018-03-07 15:03 ` Alejandro R. Mosteo
2018-03-07 15:16 ` Alejandro R. Mosteo
` (4 more replies)
1 sibling, 5 replies; 39+ messages in thread
From: Alejandro R. Mosteo @ 2018-03-07 15:03 UTC (permalink / raw)
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 ;)
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-07 15:03 ` Alejandro R. Mosteo
@ 2018-03-07 15:16 ` Alejandro R. Mosteo
2018-03-07 20:34 ` Robert A Duff
` (3 subsequent siblings)
4 siblings, 0 replies; 39+ messages in thread
From: Alejandro R. Mosteo @ 2018-03-07 15:16 UTC (permalink / raw)
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 ;)
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-07 13:11 ` Pascal Obry
2018-03-07 13:53 ` Dmitry A. Kazakov
@ 2018-03-07 16:13 ` Dan'l Miller
2018-03-12 0:13 ` Robert I. Eachus
2018-03-08 3:34 ` Randy Brukardt
2 siblings, 1 reply; 39+ messages in thread
From: Dan'l Miller @ 2018-03-07 16:13 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-07 15:03 ` Alejandro R. Mosteo
2018-03-07 15:16 ` Alejandro R. Mosteo
@ 2018-03-07 20:34 ` Robert A Duff
2018-03-07 22:47 ` Jeffrey R. Carter
` (2 subsequent siblings)
4 siblings, 0 replies; 39+ messages in thread
From: Robert A Duff @ 2018-03-07 20:34 UTC (permalink / raw)
"Alejandro R. Mosteo" <alejandro@mosteo.com> writes:
> Recommendations for current functional languages? I know only of Haskell
> (and only by name).
OCaml
- Bob
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-07 15:03 ` Alejandro R. Mosteo
2018-03-07 15:16 ` Alejandro R. Mosteo
2018-03-07 20:34 ` Robert A Duff
@ 2018-03-07 22:47 ` Jeffrey R. Carter
2018-03-08 0:26 ` Shark8
2018-03-08 0:45 ` Paul Rubin
4 siblings, 0 replies; 39+ messages in thread
From: Jeffrey R. Carter @ 2018-03-07 22:47 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-07 15:03 ` Alejandro R. Mosteo
` (2 preceding siblings ...)
2018-03-07 22:47 ` Jeffrey R. Carter
@ 2018-03-08 0:26 ` Shark8
2018-03-08 0:45 ` Paul Rubin
4 siblings, 0 replies; 39+ messages in thread
From: Shark8 @ 2018-03-08 0:26 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-07 15:03 ` Alejandro R. Mosteo
` (3 preceding siblings ...)
2018-03-08 0:26 ` Shark8
@ 2018-03-08 0:45 ` Paul Rubin
2018-03-08 11:07 ` Alejandro R. Mosteo
4 siblings, 1 reply; 39+ messages in thread
From: Paul Rubin @ 2018-03-08 0:45 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-07 13:11 ` Pascal Obry
2018-03-07 13:53 ` Dmitry A. Kazakov
2018-03-07 16:13 ` Dan'l Miller
@ 2018-03-08 3:34 ` Randy Brukardt
2018-03-08 8:23 ` Dmitry A. Kazakov
2 siblings, 1 reply; 39+ messages in thread
From: Randy Brukardt @ 2018-03-08 3:34 UTC (permalink / raw)
[-- 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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-08 3:34 ` Randy Brukardt
@ 2018-03-08 8:23 ` Dmitry A. Kazakov
2018-03-08 22:49 ` G. B.
2018-03-09 8:40 ` Simon Wright
0 siblings, 2 replies; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-03-08 8:23 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-08 0:45 ` Paul Rubin
@ 2018-03-08 11:07 ` Alejandro R. Mosteo
0 siblings, 0 replies; 39+ messages in thread
From: Alejandro R. Mosteo @ 2018-03-08 11:07 UTC (permalink / raw)
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.
>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-06 11:34 "functional" programming in Ada Alejandro R. Mosteo
` (3 preceding siblings ...)
2018-03-07 10:07 ` Maciej Sobczak
@ 2018-03-08 18:24 ` G. B.
2018-03-09 14:41 ` Alejandro R. Mosteo
4 siblings, 1 reply; 39+ messages in thread
From: G. B. @ 2018-03-08 18:24 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-08 8:23 ` Dmitry A. Kazakov
@ 2018-03-08 22:49 ` G. B.
2018-03-09 8:38 ` Dmitry A. Kazakov
2018-03-09 8:40 ` Simon Wright
1 sibling, 1 reply; 39+ messages in thread
From: G. B. @ 2018-03-08 22:49 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-08 22:49 ` G. B.
@ 2018-03-09 8:38 ` Dmitry A. Kazakov
0 siblings, 0 replies; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-03-09 8:38 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-08 8:23 ` Dmitry A. Kazakov
2018-03-08 22:49 ` G. B.
@ 2018-03-09 8:40 ` Simon Wright
2018-03-09 13:39 ` Dmitry A. Kazakov
1 sibling, 1 reply; 39+ messages in thread
From: Simon Wright @ 2018-03-09 8:40 UTC (permalink / raw)
"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").
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-09 8:40 ` Simon Wright
@ 2018-03-09 13:39 ` Dmitry A. Kazakov
0 siblings, 0 replies; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-03-09 13:39 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-08 18:24 ` G. B.
@ 2018-03-09 14:41 ` Alejandro R. Mosteo
0 siblings, 0 replies; 39+ messages in thread
From: Alejandro R. Mosteo @ 2018-03-09 14:41 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: "functional" programming in Ada
2018-03-07 16:13 ` Dan'l Miller
@ 2018-03-12 0:13 ` Robert I. Eachus
0 siblings, 0 replies; 39+ messages in thread
From: Robert I. Eachus @ 2018-03-12 0:13 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2018-03-12 0:13 UTC | newest]
Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-06 11:34 "functional" programming in Ada Alejandro R. Mosteo
2018-03-06 13:09 ` Dmitry A. Kazakov
2018-03-06 14:35 ` Alejandro R. Mosteo
2018-03-06 15:08 ` Dmitry A. Kazakov
2018-03-06 16:00 ` Manuel Collado
2018-03-06 16:37 ` Dmitry A. Kazakov
2018-03-06 22:16 ` Manuel Collado
2018-03-07 8:41 ` Dmitry A. Kazakov
2018-03-07 4:46 ` Paul Rubin
2018-03-06 13:29 ` Mehdi Saada
2018-03-06 14:34 ` Alejandro R. Mosteo
2018-03-06 14:36 ` Mehdi Saada
2018-03-06 15:27 ` Alejandro R. Mosteo
2018-03-06 16:26 ` Jeffrey R. Carter
2018-03-06 20:17 ` Randy Brukardt
2018-03-07 14:30 ` Alejandro R. Mosteo
2018-03-06 15:01 ` Dan'l Miller
2018-03-06 15:25 ` Alejandro R. Mosteo
2018-03-07 10:07 ` Maciej Sobczak
2018-03-07 10:52 ` Mehdi Saada
2018-03-07 13:11 ` Pascal Obry
2018-03-07 13:53 ` Dmitry A. Kazakov
2018-03-07 16:13 ` Dan'l Miller
2018-03-12 0:13 ` Robert I. Eachus
2018-03-08 3:34 ` Randy Brukardt
2018-03-08 8:23 ` Dmitry A. Kazakov
2018-03-08 22:49 ` G. B.
2018-03-09 8:38 ` Dmitry A. Kazakov
2018-03-09 8:40 ` Simon Wright
2018-03-09 13:39 ` Dmitry A. Kazakov
2018-03-07 15:03 ` Alejandro R. Mosteo
2018-03-07 15:16 ` Alejandro R. Mosteo
2018-03-07 20:34 ` Robert A Duff
2018-03-07 22:47 ` Jeffrey R. Carter
2018-03-08 0:26 ` Shark8
2018-03-08 0:45 ` Paul Rubin
2018-03-08 11:07 ` Alejandro R. Mosteo
2018-03-08 18:24 ` G. B.
2018-03-09 14:41 ` Alejandro R. Mosteo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox