Ada syntax questions

Ada syntax questions

[DrPi]

Hi,

Ada claims to have a better syntax than other languages.
I'm fine with with, but...

1) What about array indexing ?
In some other languages, arrays are indexed using square brackets. In 
Ada, parentheses are used for function calls and for array indexing.
In the code "status := NewStatus(some_var);", you can't tell if 
NewStatus is a function or an array.

2) In Ada, a function without arguments is called without any parentheses.
In the code "status := NewStatus;", you can't tell if NewStatus is a 
function or a variable.


For my knowledge, are there good reasons for these syntaxes ?

Nicolas

Re: Ada syntax questions

[Gabriele Galeotti]

On Thursday, December 17, 2020 at 11:39:47 PM UTC+1, DrPi wrote:
> Hi, 
> 
> Ada claims to have a better syntax than other languages. 
> I'm fine with with, but... 
> 
> 1) What about array indexing ? 
> In some other languages, arrays are indexed using square brackets. In 
> Ada, parentheses are used for function calls and for array indexing. 
> In the code "status := NewStatus(some_var);", you can't tell if 
> NewStatus is a function or an array. 
> 
> 2) In Ada, a function without arguments is called without any parentheses. 
> In the code "status := NewStatus;", you can't tell if NewStatus is a 
> function or a variable. 
> 
> 
> For my knowledge, are there good reasons for these syntaxes ? 
> 
> Nicolas

1)
This allows you to replace your array with a function with the same name,
which takes the subscript as an argument and returns a value, without touching your client code.
Think about an expensive lookup table -vs- a simple function which computes your data.
Do not see this as an ambiguity but rather a nice uniformity of calling something for a value.

2)
Nearly the same, but in another context and without an argument.
"NewStatus" could be, e.g., a constant, as long as types match.

G

Re: Ada syntax questions

[Jeffrey R. Carter]

On 12/17/20 11:39 PM, DrPi wrote:
> 
> 1) What about array indexing ?
> In some other languages, arrays are indexed using square brackets. In Ada, 
> parentheses are used for function calls and for array indexing.
> In the code "status := NewStatus(some_var);", you can't tell if NewStatus is a 
> function or an array.

The requirements for the language included a restricted set of characters for 
source code that did not include brackets. So that is the primary reason 
parentheses are used.

However, both arrays and functions are often used as maps, and so an 
after-the-fact rationalization is that using the same syntax for both array 
indexing and function calls makes it easy to switch between the two.

> 2) In Ada, a function without arguments is called without any parentheses.
> In the code "status := NewStatus;", you can't tell if NewStatus is a function or 
> a variable.

That's because Newstatus is a terrible name. If you'd used New_Status there 
would be no confusion.

Seriously: Ada 80 required empty parentheses for a subprogram call with no 
explicit parameters. During the review process that resulted in Ada 83, these 
were universally reviled and so were eliminated.

-- 
Jeff Carter
"I didn't squawk about the steak, dear. I
merely said I didn't see that old horse
that used to be tethered outside here."
Never Give a Sucker an Even Break
103

Re: Ada syntax questions

[Dmitry A. Kazakov]

On 2020-12-17 23:39, DrPi wrote:

> Ada claims to have a better syntax than other languages.
> I'm fine with with, but...
> 
> 1) What about array indexing ?
> In some other languages, arrays are indexed using square brackets. In 
> Ada, parentheses are used for function calls and for array indexing.
> In the code "status := NewStatus(some_var);", you can't tell if 
> NewStatus is a function or an array.
> 
> 2) In Ada, a function without arguments is called without any parentheses.
> In the code "status := NewStatus;", you can't tell if NewStatus is a 
> function or a variable.
> 
> 
> For my knowledge, are there good reasons for these syntaxes ?

1. Separation of interface and implementation. Being array or function 
is an implementation detail of a map or a named entity.

Another example is pointer dereferencing. In Ada X.A is same as P.A. In 
C you have X.A vs P->A.

Yet another one. All instances of parametrisation in Ada deploy () 
parentheses. In C++ it would be <>, [], (), depending on semantically 
irrelevant context.

2. Languages that like C use bottom-up matching are forced to 
distinguish certain things prematurely on the syntax level. This is also 
the reason why you cannot use the result type to distinguish signatures 
in C++, but you can in Ada. Thus in C++ you would have something as 
disgusting as

    123ull

while in Ada it is just

    123

Long time ago anything but strictly bottom-up matching was considered 
too complicated or impossible. So artificial distinctions like () vs [] 
were invented and then promoted into orthodoxy.

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

Re: Ada syntax questions

[Mart van de Wege]

DrPi <314@drpi.fr> writes:

> Hi,
>
> Ada claims to have a better syntax than other languages.
> I'm fine with with, but...
>
> 1) What about array indexing ?
> In some other languages, arrays are indexed using square brackets. In
> Ada, parentheses are used for function calls and for array indexing.
> In the code "status := NewStatus(some_var);", you can't tell if
> NewStatus is a function or an array.
>
Why would you care? It is obvious that NewStatus will return something
based on the value of some_var. How it does that, by array dereference
or function call should make no difference to the caller; they are only
interested in the final value of status.

Or another look at it: array indexing is effectively a function call
anyway. It is "return value of array_base + index".

> 2) In Ada, a function without arguments is called without any parentheses.
> In the code "status := NewStatus;", you can't tell if NewStatus is a
> function or a variable.
>
Again, why would you care how NewStatus returns a value? Either by
returning the value of a function or by dereferencing a variable, all
you're interested in is the value assigned to status.

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: Ada syntax questions

[Björn Lundin]

Den 2020-12-17 kl. 23:39, skrev DrPi:
> Hi,
> 
> Ada claims to have a better syntax than other languages.
> I'm fine with with, but...
...
> 
> 2) In Ada, a function without arguments is called without any parentheses.
> In the code "status := NewStatus;", you can't tell if NewStatus is a 
> function or a variable.

As others have stated, why do you care?
I often mock up a function with a constant,
add a pragma compile_time_warning/error ("fix implementation later")
and only later write the body of the function. And that is the only code 
change - I don't need to add an useless empty pair of () just because it 
is a function to all the callers

> For my knowledge, are there good reasons for these syntaxes ?
Yes

-- 
Björn

Re: Ada syntax questions

[Niklas Holsti]

On 2020-12-18 0:39, DrPi wrote:
> Hi,
> 
> Ada claims to have a better syntax than other languages.


I would say the claim is that the Ada syntax was rationally designed to 
have certain properties, which are desired by certain users (us Ada 
programmers) so it is "better" for us, although some aspects are 
subjective for sure.

In addition to what others have said, here are some further comments on 
the examples you gave:


> 1) What about array indexing ?
> In some other languages, arrays are indexed using square brackets. In 
> Ada, parentheses are used for function calls and for array indexing.


There are proposals to allow [] as well as (), mainly to increase 
familiarity for new Ada users.


> 2) In Ada, a function without arguments is called without any parentheses.


Parameterless functions are rare, and properly so.

Parameterless procedures are much more common. Writing

    Frobnicate_Widget();

is longer than

    Frobnicate_Widget;

and seems to have no advantages over the shorter form.

Re: Ada syntax questions

[Keith Thompson]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> On 2020-12-18 0:39, DrPi wrote:
>> Ada claims to have a better syntax than other languages.
>
> I would say the claim is that the Ada syntax was rationally designed
> to have certain properties, which are desired by certain users (us Ada
> programmers) so it is "better" for us, although some aspects are
> subjective for sure.
>
> In addition to what others have said, here are some further comments
> on the examples you gave:
>
>> 1) What about array indexing ?
>> In some other languages, arrays are indexed using square
>> brackets. In Ada, parentheses are used for function calls and for
>> array indexing.

I've never found any of the arguments in favor of using parentheses
for array indexing convincing, and I've never liked the way Ada
does it.  But of course the decision was made in the early 1980s,
and it can't be changed now.

At least part of the reason was that Ada needed to be used on
systems that didn't have '[' and ']' in their character sets.
I don't know to what extent that necessity has been used as an
after the fact rationalization.

Function calls and array indexing can be substituted for one another
in *some* circumstances, but not it all.  But they really are very
different things.  A function call executes user-written code,
and may have side effects; an array indexing expression refers to
an object.  An array indexing expression can appear on the LHS of
an assignment; a function call can't.

If Ada had originally used '[' and ']' for array indexing, I doubt
that anyone would be complaining that it would have been better to
use '(' and ')' (other than some Fortran programmers, I suppose).

Why not use parentheses for record components, Object(Component)
rather than Object.Component?  Doesn't the same argument apply?

> There are proposals to allow [] as well as (), mainly to increase
> familiarity for new Ada users.

Ick.  The only thing more confusing than using () for array indexing
would be allowing either () or [] at the programmer's whim.  (Well,
not the only thing; I'm sure I could come up with something even
worse.)

>> 2) In Ada, a function without arguments is called without any parentheses.
>
> Parameterless functions are rare, and properly so.
>
> Parameterless procedures are much more common. Writing
>
>    Frobnicate_Widget();
>
> is longer than
>
>    Frobnicate_Widget;
>
> and seems to have no advantages over the shorter form.

I wouldn't have expected the designers of Ada to be concerned about
saving two characters.

I see your point about procedure calls.  A statement consisting
of an identifier followed by a semicolon can only be a procedure
call (I think), so there's no ambiguity.  My mild dislike for the
function call syntax is that it needlessly treats the zero-parameter
case as special.

There could also be some potential ambiguities, though I'm not aware
of any actual ambiguous cases in Ada.  In some languages, the name
of a function not followed by parentheses refers to the function
itself (or its address) and does not call it.  I can easily imagine
an attribute for which Func'Attribute could sensibly refer either
to the function Func itself or to the value returned by calling it.

Again, if Ada 83 had required empty parentheses on parameterless
procedure and function calls, I'm skeptical that anyone would now
be arguing that it was a bad decision.

And again, it would be impossible to change it without breaking
existing code.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Re: Ada syntax questions

[Randy Brukardt]

"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message 
news:87r1nkb0lj.fsf@nosuchdomain.example.com...
...
> Function calls and array indexing can be substituted for one another
> in *some* circumstances, but not it all.  But they really are very
> different things.  A function call executes user-written code,
> and may have side effects; an array indexing expression refers to
> an object.  An array indexing expression can appear on the LHS of
> an assignment; a function call can't.

This is false in modern languages with user-defined indexing (Ada and C++ 
included), since what looks like array indexing can actually be implemented 
with a function call.

Not having variable returning functions is a flaw in Ada, IMHO. These days, 
I think there are still too many special cases in Ada. If I was starting 
today, () would be a function call, and . would be selection/dereferencing, 
and there would not be anything else (which means getting rid of type 
conversions, array indexing and slicing, and anything else I've forgotten 
about). Compilers are smart enough to generate better code when they know 
something about the function involved (including if it is that of a 
predefined container). Doing that would allow overloading to be more general 
and to allow for the complication of variable returning functions.

                            Randy.
. 

Re: Ada syntax questions

[Dmitry A. Kazakov]

On 2020-12-22 02:04, Randy Brukardt wrote:

> If I was starting
> today, () would be a function call, and . would be selection/dereferencing,
> and there would not be anything else (which means getting rid of type
> conversions, array indexing and slicing, and anything else I've forgotten
> about).

But you cannot rid of X(...) syntax, where X is an object. It is not 
only indexing, e.g. in declarations:

    X : T (Y);

Then what is wrong with indexing? It should simply apply to all types 
[from some predefined class]:

    X (...) ::= CALL (<index-operation>, X, ...)

    (...) ::= CALL (<aggregate-operation>, ...)

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

Re: Ada syntax questions

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:rrs92d$1pfi$1@gioia.aioe.org...
...
>But you cannot rid of X(...) syntax, where X is an object.

That's a prefixed view, of course. No one would want to get rid of that.

>It is not only indexing, e.g. in declarations:
>    X : T (Y);

That's not an expression and is not resolved (that is, there is no possible 
overloading).

...
> Then what is wrong with indexing?

Nothing is "wrong" with it, it is just redundant. As others have noted here, 
both indexes and function calls represent a mapping. What's the point of 
having two ways to represent a mapping? In an Ada-like language, there's no 
syntax nor semantic difference.

Ada (and most other languages) are full of redundant stuff. Simpilfy the 
basics and then one has more room for interesting stuff (static analysis, 
parallel execution, etc.).

                            Randy.

Re: Ada syntax questions

[Dmitry A. Kazakov]

On 2020-12-23 02:23, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:rrs92d$1pfi$1@gioia.aioe.org...
> ...
>> But you cannot rid of X(...) syntax, where X is an object.
> 
> That's a prefixed view, of course. No one would want to get rid of that.

Hmm, where is the operation? A prefixed view is

    <expression>.<operation>(...)

Indexing is

    <expression>(...)

In particular:

    "abc"(1)

>> It is not only indexing, e.g. in declarations:
>>     X : T (Y);
> 
> That's not an expression and is not resolved (that is, there is no possible
> overloading).

I see no fundamental difference between "first-class" expressions and 
type-expressions.

> ...
>> Then what is wrong with indexing?
> 
> Nothing is "wrong" with it, it is just redundant. As others have noted here,
> both indexes and function calls represent a mapping. What's the point of
> having two ways to represent a mapping? In an Ada-like language, there's no
> syntax nor semantic difference.

Both are mappings, but unless you make functions first-class citizens 
there exist language level difference between a function and a container 
object.

> Ada (and most other languages) are full of redundant stuff. Simpilfy the
> basics and then one has more room for interesting stuff (static analysis,
> parallel execution, etc.).

Yes, but I would rather keep all this stuff in the language making it 
overridable primitive operations.

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

Re: Ada syntax questions

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:rrv0u2$102i$1@gioia.aioe.org...
> On 2020-12-23 02:23, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:rrs92d$1pfi$1@gioia.aioe.org...
>> ...
>>> But you cannot rid of X(...) syntax, where X is an object.
>>
>> That's a prefixed view, of course. No one would want to get rid of that.
>
> Hmm, where is the operation? A prefixed view is
>
>    <expression>.<operation>(...)
>
> Indexing is
>
>    <expression>(...)

I neglected to mention that what Ada calls objects are also function calls 
in this proposed generalization. (Much like enumeration literals are in 
Ada.) So for static semantics (that is, compile-time), pretty much 
everything is a function call. This gets rid of the anomalies associated 
with constants (which don't overload and thus hide more than a parameterless 
function - which is otherwise the same thing); combined with 
variable-returning functions, everything is overloadable and treated the 
same in expressions. Almost no special cases (operators still require some 
special casing, but we can make them always visible which would eliminate 
more issues).

Clearly a compiler for this language (which can't be Ada, unfortunately, way 
too incompatible) would special-case some kinds of built-in functions for 
things like objects and indexing. But that doesn't need to hair up the 
semantic model, just the implementations.

...
>> Ada (and most other languages) are full of redundant stuff. Simpilfy the
>> basics and then one has more room for interesting stuff (static analysis,
>> parallel execution, etc.).
>
> Yes, but I would rather keep all this stuff in the language making it 
> overridable primitive operations.

Yeah, you don't plan to formally describe nor implement this language, so 
you don't really care about how complex it gets. :-) Well, at least not 
until performance suffers. Ada is reaching the limit of what can be done 
without substantial incompatibility. If we're going to allow that, we need 
to start with a cleaner base, and part of that is getting rid of 
redundancies.

                                  Randy.

Re: Ada syntax questions

[Dmitry A. Kazakov]

On 2020-12-24 05:06, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:rrv0u2$102i$1@gioia.aioe.org...
>> On 2020-12-23 02:23, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:rrs92d$1pfi$1@gioia.aioe.org...
>>> ...
>>>> But you cannot rid of X(...) syntax, where X is an object.
>>>
>>> That's a prefixed view, of course. No one would want to get rid of that.
>>
>> Hmm, where is the operation? A prefixed view is
>>
>>     <expression>.<operation>(...)
>>
>> Indexing is
>>
>>     <expression>(...)
> 
> I neglected to mention that what Ada calls objects are also function calls
> in this proposed generalization.

Well, you must stop the recursion somewhere. It is fine to treat access 
to objects as calls, e.g. to getter/setter, or to indexation, or to 
dereferencing, but you must finish at some point with something spelled 
as a call to a subprogram. In the case of a subprogram call you are 
already there. With "objects" you need a few hops to get there.

  (Much like enumeration literals are in
> Ada.) So for static semantics (that is, compile-time), pretty much
> everything is a function call. This gets rid of the anomalies associated
> with constants (which don't overload and thus hide more than a parameterless
> function - which is otherwise the same thing); combined with
> variable-returning functions, everything is overloadable and treated the
> same in expressions. Almost no special cases (operators still require some
> special casing, but we can make them always visible which would eliminate
> more issues).

Yes, resolving overloading/hiding issues in a uniform way must help.

> Clearly a compiler for this language (which can't be Ada, unfortunately, way
> too incompatible) would special-case some kinds of built-in functions for
> things like objects and indexing. But that doesn't need to hair up the
> semantic model, just the implementations.
> 
> ...
>>> Ada (and most other languages) are full of redundant stuff. Simpilfy the
>>> basics and then one has more room for interesting stuff (static analysis,
>>> parallel execution, etc.).
>>
>> Yes, but I would rather keep all this stuff in the language making it
>> overridable primitive operations.
> 
> Yeah, you don't plan to formally describe nor implement this language, so
> you don't really care about how complex it gets. :-) Well, at least not
> until performance suffers.

Well, if that becomes a part of a library, why should I care?

I would definitely get of generics, and clarify overloading in some way.

> Ada is reaching the limit of what can be done
> without substantial incompatibility. If we're going to allow that, we need
> to start with a cleaner base, and part of that is getting rid of
> redundancies.

We see that differently. So far new features were added on top which 
naturally leads to the mess we observe. The problem is lack of 
generalization not inconsistency. If the new Ada cannot express the old 
messy, but consistent Ada, then this new Ada is not general enough and 
it will arrive at the same amount of mess sooner or later.

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

Re: Ada syntax questions

[AdaMagica]

Randy Brukardt schrieb am Dienstag, 22. Dezember 2020 um 02:04:46 UTC+1:
> "Keith Thompson" <Keith.S.T...@gmail.com> wrote in message 
> news:87r1nkb...@nosuchdomain.example.com... 
> ...
> > Function calls and array indexing can be substituted for one another 
> > in *some* circumstances, but not it all. But they really are very 
> > different things. A function call executes user-written code, 
> > and may have side effects; an array indexing expression refers to 
> > an object. An array indexing expression can appear on the LHS of 
> > an assignment; a function call can't.
> This is false in modern languages with user-defined indexing (Ada and C++ 
> included), since what looks like array indexing can actually be implemented 
> with a function call. 

See http://www-staging.eu.adacore.com/adaanswers/gems/gem-123-implicit-dereferencing-in-ada-2012/

Here the LHS is a function call, looking like container Cont is indexed as an array:
Cont (My_Key) := Some_Element_Value;

Re: Ada syntax questions

[Keith Thompson]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> On 2020-12-18 0:39, DrPi wrote:
>> Ada claims to have a better syntax than other languages.
>
> I would say the claim is that the Ada syntax was rationally designed
> to have certain properties, which are desired by certain users (us Ada
> programmers) so it is "better" for us, although some aspects are
> subjective for sure.
>
> In addition to what others have said, here are some further comments
> on the examples you gave:
>
>> 1) What about array indexing ?
>> In some other languages, arrays are indexed using square
>> brackets. In Ada, parentheses are used for function calls and for
>> array indexing.

I've never found any of the arguments in favor of using parentheses
for array indexing convincing, and I've never liked the way Ada
does it.  But of course the decision was made in the early 1980s,
and it can't be changed now.

At least part of the reason was that Ada needed to be used on
systems that didn't have '[' and ']' in their character sets.
I don't know to what extent that necessity has been used as an
after the fact rationalization.

Function calls and array indexing can be substituted for one another
in *some* circumstances, but not it all.  But they really are very
different things.  A function call executes user-written code,
and may have side effects; an array indexing expression refers to
an object.  An array indexing expression can appear on the LHS of
an assignment; a function call can't.

If Ada had originally used '[' and ']' for array indexing, I doubt
that anyone would be complaining that it would have been better to
use '(' and ')' (other than some Fortran programmers, I suppose).

Why not use parentheses for record components, Object(Component)
rather than Object.Component?  Doesn't the same argument apply?

> There are proposals to allow [] as well as (), mainly to increase
> familiarity for new Ada users.

Ick.  The only thing more confusing than using () for array indexing
would be allowing either () or [] at the programmer's whim.  (Well,
not the only thing; I'm sure I could come up with something even
worse.)

>> 2) In Ada, a function without arguments is called without any parentheses.
>
> Parameterless functions are rare, and properly so.
>
> Parameterless procedures are much more common. Writing
>
>    Frobnicate_Widget();
>
> is longer than
>
>    Frobnicate_Widget;
>
> and seems to have no advantages over the shorter form.

I wouldn't have expected the designers of Ada to be concerned about
saving two characters.

I see your point about procedure calls.  A statement consisting
of an identifier followed by a semicolon can only be a procedure
call (I think), so there's no ambiguity.  My mild dislike for the
function call syntax is that it needlessly treats the zero-parameter
case as special.

There could also be some potential ambiguities, though I'm not aware
of any actual ambiguous cases in Ada.  In some languages, the name
of a function not followed by parentheses refers to the function
itself (or its address) and does not call it.  I can easily imagine
an attribute for which Func'Attribute could sensibly refer either
to the function Func itself or to the value returned by calling it.

Again, if Ada 83 had required empty parentheses on parameterless
procedure and function calls, I'm skeptical that anyone would now
be arguing that it was a bad decision.

And again, it would be impossible to change it without breaking
existing code.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Re: Ada syntax questions

[Dmitry A. Kazakov]

On 2020-12-20 22:59, Keith Thompson wrote:

> Function calls and array indexing can be substituted for one another
> in *some* circumstances, but not it all.

IMO the only circumstances violating this substitutability are language 
design bugs and deficiencies:

- Passing array elements in in-out mode
- Assigning array elements
- Multidimensional indices
- Slices

all these must be substituable with user-defined subprograms.

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

Re: Ada syntax questions

[Stephen Leake]

DrPi <314@drpi.fr> writes:

> 1) What about array indexing ?
> In some other languages, arrays are indexed using square brackets. In
> Ada, parentheses are used for function calls and for array indexing.
> In the code "status := NewStatus(some_var);", you can't tell if
> NewStatus is a function or an array.

This is true. 

You seem to be implying this is bad; why?

> 2) In Ada, a function without arguments is called without any parentheses.
> In the code "status := NewStatus;", you can't tell if NewStatus is a
> function or a variable.

This is true. 

You seem to be implying this is bad; why?

> For my knowledge, are there good reasons for these syntaxes ?

Yes. See the Ada Rationale: http://ada-auth.org/standards/rationale12.html

-- 
-- Stephe

Re: Ada syntax questions

[DrPi]

Thanks all for your answers.


 > Why would you care?

Calling a function can have side effects. Accessing an array or a 
variable can't have side effects.


> You seem to be implying this is bad; why?

Reading the code can't tell you the writer's intentions.

Re: Ada syntax questions

[Dmitry A. Kazakov]

On 2020-12-19 12:50, DrPi wrote:

>  > Why would you care?
> 
> Calling a function can have side effects. Accessing an array or a 
> variable can't have side effects.

Untrue. Both array and variable access have side effects on the 
registers, on the cache, on the process memory paging, in the form of 
exception propagation etc. Even direct effects on the outside world are 
possible when using machine memory load instructions. E.g. on some 
hardware reading memory at the specific address location means physical 
serial input.

All these effects are either desired parts of the implementation or else 
bugs to be fixed. If desired, why do you care?

>> You seem to be implying this is bad; why?
> 
> Reading the code can't tell you the writer's intentions.

What intentions? Unless you are talking about the intention to deploy a 
specific machine instruction, function or array gives you no clue. But 
even then. PDP-11 FORTRAN IV used subprogram calls to implement 
basically everything, elementary arithmetic operations. If the function 
is inlined, where is any call? Functions can be tabulated into lookup 
tables. Arrays can be compressed into functions.

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

Re: Ada syntax questions

[Andreas ZEURCHER]

On Saturday, December 19, 2020 at 6:40:28 AM UTC-6, Dmitry A. Kazakov wrote:
> On 2020-12-19 12:50, DrPi wrote: 
> 
> > > Why would you care? 
> > 
> > Calling a function can have side effects. Accessing an array or a 
> > variable can't have side effects.
>
> Untrue. Both array and variable access have side effects on the 
> registers, on the cache, on the process memory paging, in the form of 
> exception propagation etc. Even direct effects on the outside world are 
> possible when using machine memory load instructions. E.g. on some 
> hardware reading memory at the specific address location means physical 
> serial input. 

Dmitry, DrPi here is referring to side-effects as viewed from the functional-programming paradigm's perspective.  Some programming languages have a "pure" designator (usually the keyword: pure) that assures that this subroutine and all invoked subroutines therein are pure (i.e., have no FP side effects).  

The side effects of which you speak are at the machine-code level:  e.g., setting/clearing comparison flag(s), setting/clearing carry flag, setting/clearing overflow/underflow flag(s), evictions from L1/L2/L3 cache, (on RISC processors) latching an address in preparation of a load/store, and so forth.  None of these are externally observable side effects from FP's perspective above the machine-code level.  DrPi's FP goals are valid.

> All these effects are either desired parts of the implementation or else 
> bugs to be fixed. If desired, why do you care?
> >> You seem to be implying this is bad; why? 
> > 
> > Reading the code can't tell you the writer's intentions.
> What intentions?

The intentions of the Ada programmer to design an overtly FP-pure or either an overtly FP-impure subroutine or an FP-impure subroutine by happenstance.  Subroutine here is preferably a function, preferably at that a single-parameter function (for ability to utilize over a century of mathematical-analysis techniques).  Ada is showing its 1970s vintage by unfortunately omitting overtly expressing FP pureness as a fundamental principle (among a few other FP features).  DrPi's FP goals are valid.

> Unless you are talking about the intention to deploy a 
> specific machine instruction, function or array gives you no clue. But 
> even then. PDP-11 FORTRAN IV used subprogram calls to implement 
> basically everything, elementary arithmetic operations. If the function 
> is inlined, where is any call? Functions can be tabulated into lookup 
> tables. Arrays can be compressed into functions.
> -- 
> Regards, 
> Dmitry A. Kazakov 
> http://www.dmitry-kazakov.de

Re: Ada syntax questions

[Dmitry A. Kazakov]

On 2020-12-19 18:13, Andreas ZEURCHER wrote:
> On Saturday, December 19, 2020 at 6:40:28 AM UTC-6, Dmitry A. Kazakov wrote:
>> On 2020-12-19 12:50, DrPi wrote:
>>
>>>> Why would you care?
>>>
>>> Calling a function can have side effects. Accessing an array or a
>>> variable can't have side effects.
>>
>> Untrue. Both array and variable access have side effects on the
>> registers, on the cache, on the process memory paging, in the form of
>> exception propagation etc. Even direct effects on the outside world are
>> possible when using machine memory load instructions. E.g. on some
>> hardware reading memory at the specific address location means physical
>> serial input.
> 
> Dmitry, DrPi here is referring to side-effects as viewed from the functional-programming paradigm's perspective.  Some programming languages have a "pure" designator (usually the keyword: pure) that assures that this subroutine and all invoked subroutines therein are pure (i.e., have no FP side effects).
> 
> The side effects of which you speak are at the machine-code level:  e.g., setting/clearing comparison flag(s), setting/clearing carry flag, setting/clearing overflow/underflow flag(s), evictions from L1/L2/L3 cache, (on RISC processors) latching an address in preparation of a load/store, and so forth.  None of these are externally observable side effects from FP's perspective above the machine-code level.  DrPi's FP goals are valid.

Memory paging is pretty much observable.

What you are saying is a question of contracts. The contract must 
include all effects the user may rely on. The contract of a function may 
include observable effects or have none (to some extent).

If contracts were indeed relevant to the syntax then functions without 
contracted side effects must have been called using [] instead of ().

No? Then it is not about the contracts.

>> All these effects are either desired parts of the implementation or else
>> bugs to be fixed. If desired, why do you care?
>>>> You seem to be implying this is bad; why?
>>>
>>> Reading the code can't tell you the writer's intentions.
>> What intentions?
> 
> The intentions of the Ada programmer to design an overtly FP-pure or either an overtly FP-impure subroutine or an FP-impure subroutine by happenstance.

Intentions are constraints expressed by contracts. Everything else is 
implementation details.

Ada programmers are not motivated by pureness of a subroutine. These are 
totally irrelevant. What is relevant is the strength of the contract. 
Functions without side effects are preferable just because they have 
weakest preconditions and strongest postconditions. Side effects weaken 
postconditions.

For the clients these are of no interest, even less to deserve a 
different syntax. The user must simply obey the contract whatever it be, 
ignoring the implementation as much as possible.

Ada's unified syntax is a great help here. I quite often replace arrays 
and variables with functions. It would be great if literals were fully 
equivalent to parameterless functions.

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

Re: Ada syntax questions

[Andreas ZEURCHER]

On Saturday, December 19, 2020 at 11:49:12 AM UTC-6, Dmitry A. Kazakov wrote:
> On 2020-12-19 18:13, Andreas ZEURCHER wrote: 
> > On Saturday, December 19, 2020 at 6:40:28 AM UTC-6, Dmitry A. Kazakov wrote: 
> >> On 2020-12-19 12:50, DrPi wrote: 
> >> 
> >>>> Why would you care? 
> >>> 
> >>> Calling a function can have side effects. Accessing an array or a 
> >>> variable can't have side effects. 
> >> 
> >> Untrue. Both array and variable access have side effects on the 
> >> registers, on the cache, on the process memory paging, in the form of 
> >> exception propagation etc. Even direct effects on the outside world are 
> >> possible when using machine memory load instructions. E.g. on some 
> >> hardware reading memory at the specific address location means physical 
> >> serial input. 
> > 
> > Dmitry, DrPi here is referring to side-effects as viewed from the functional-programming paradigm's perspective. Some programming languages have a "pure" designator (usually the keyword: pure) that assures that this subroutine and all invoked subroutines therein are pure (i.e., have no FP side effects). 
> > 
> > The side effects of which you speak are at the machine-code level: e.g., setting/clearing comparison flag(s), setting/clearing carry flag, setting/clearing overflow/underflow flag(s), evictions from L1/L2/L3 cache, (on RISC processors) latching an address in preparation of a load/store, and so forth. None of these are externally observable side effects from FP's perspective above the machine-code level. DrPi's FP goals are valid.
> Memory paging is pretty much observable. 
> 
> What you are saying is a question of contracts. The contract must 
> include all effects the user may rely on. The contract of a function may 
> include observable effects or have none (to some extent). 
> 
> If contracts were indeed relevant to the syntax then functions without 
> contracted side effects must have been called using [] instead of (). 
> 
> No? Then it is not about the contracts.

As witnessed by your final sentence quoted below and multiple other replies along this thread, the key tactical advantage of Ada's usage parentheses for array indexing is to accomplish a switcheroo days, weeks, months, years, or decades later:  to substitute a function invocation later for what was formerly an array index.  Cute trick.  Advantageous in some situations.  But for people like DrPi who seek contractual assurance of FP-purity of (all?) invoked functions (and overt declaration of impurity of other functions), Ada's 1) implicit switcheroo there in unfortunate combination with Ada's 2) lack of flamboyantly advertising impurity in the replacement function does in fact violate the purity portion of the contract that the mere offset-into-array implementation had—and indeed •overtly• declared in its specification as a mere offset-into-array operation-of-unquestionable-purity.  It is okay for a 1970s Ada to not foresee this, because FP was not a mainstream programming practice back then.  (But, btw, it is not as okay for there to be a lack of HOLWGn each decade since the 1980s to revisit whether HOLWG1 forgot anything, where n>1, n∈ℤ.)  This 1970s faux pas in letting a silent slip-streamed switcheroo into the core contract-definition declaration mechanism of Ada (not comments! btw, tisk tisk) is merely some tarnish that an AdaNG (next-generation Ada) would fix: e.g., by mandating that all functions (and procedures?) shall be overtly declared & enforced to be pure or impure, which would then mean that only pure functions could substitute for array indexing is the ()-based switcheroo on which so many replies in this thread hang their hat.  And DrPi would enjoy seeing the compile-time errors emerge when some cavalier programmer over yonder changed an array index to an •impure• function invocation as contract violation.  The cute implicit switcheroo isn't evil, but the lack of compile-time detection of impurity in the switcherooed function is what is evil.

(While drinking tea as none of my business as the meme goes,) I actually claim that Ada's usage of parentheses for array indexing was merely happenstance copying the Fortran-PL/I-PL/1-Simula-PL/P-PL/M/CHILL heritage popular in the 1970s*, which itself mimicked mathematics' usage of parentheses around each matrix.  Because there was no way to represent mathematics' subscripts as the notation for indexing, the next best punctuation for matrix/vector indexing was borrowed:  parentheses.

* as opposed to the ALGOL58's, ALGOL60's, ALGOL68's, BCPL's, C's square brackets, so the big split was somewhere around 1957 for FORTRAN (and whichever predecessor languages influenced it) and 1958 for ALGOL58 (and whichever predecessor languages influenced it), as opposed to APL's ⍳ iota which uses neither parentheses nor square brackets to pull out an element since 1966

> >> All these effects are either desired parts of the implementation or else 
> >> bugs to be fixed. If desired, why do you care? 
> >>>> You seem to be implying this is bad; why? 
> >>> 
> >>> Reading the code can't tell you the writer's intentions. 
> >> What intentions? 
> > 
> > The intentions of the Ada programmer to design an overtly FP-pure or either an overtly FP-impure subroutine or an FP-impure subroutine by happenstance.
> Intentions are constraints expressed by contracts. Everything else is 
> implementation details. 
> 
> Ada programmers are not motivated by pureness of a subroutine. These are 
> totally irrelevant. What is relevant is the strength of the contract. 
> Functions without side effects are preferable just because they have 
> weakest preconditions and strongest postconditions. Side effects weaken 
> postconditions. 
> 
> For the clients these are of no interest, even less to deserve a 
> different syntax. The user must simply obey the contract whatever it be, 
> ignoring the implementation as much as possible. 
> 
> Ada's unified syntax is a great help here. I quite often replace arrays 
> and variables with functions. It would be great if literals were fully 
> equivalent to parameterless functions.
> -- 
> Regards, 
> Dmitry A. Kazakov 
> http://www.dmitry-kazakov.de

Re: Ada syntax questions

[Dmitry A. Kazakov]

On 2020-12-19 19:40, Andreas ZEURCHER wrote:
> On Saturday, December 19, 2020 at 11:49:12 AM UTC-6, Dmitry A. Kazakov wrote:
>> On 2020-12-19 18:13, Andreas ZEURCHER wrote:
>>> On Saturday, December 19, 2020 at 6:40:28 AM UTC-6, Dmitry A. Kazakov wrote:
>>>> On 2020-12-19 12:50, DrPi wrote:

>> If contracts were indeed relevant to the syntax then functions without
>> contracted side effects must have been called using [] instead of ().
>>
>> No? Then it is not about the contracts.
> 
> As witnessed by your final sentence quoted below and multiple other replies along this thread, the key tactical advantage of Ada's usage parentheses for array indexing is to accomplish a switcheroo days, weeks, months, years, or decades later:  to substitute a function invocation later for what was formerly an array index.

Not substitute, but to provide whatever implementation necessary. In 
fact Ada is limited in terms of abstractions. There still exist things 
which cannot be implemented by user-defined subprograms. Ideally there 
should be none. Whatever syntax sugar, there should be always a 
possibility to back it by a user-provided primitive operation.

> But for people like DrPi who seek contractual assurance of FP-purity of (all?) invoked functions (and overt declaration of impurity of other functions),

If they are unsatisfied with the higher abstraction level of Ada, they 
can switch to lower-level languages where implementation details are 
exposed in syntax. The best we can do is to explain why such exposure is 
a bad idea.

[ Conceptually Ada has nothing to do with FP and I sincerely hope it 
never will. ]

> This 1970s faux pas in letting a silent slip-streamed switcheroo into the core contract-definition declaration mechanism of Ada (not comments! btw, tisk tisk) is merely some tarnish that an AdaNG (next-generation Ada) would fix: e.g., by mandating that all functions (and procedures?) shall be overtly declared & enforced to be pure or impure, which would then mean that only pure functions could substitute for array indexing is the ()-based switcheroo on which so many replies in this thread hang their hat.

This would be highly undesired. On the contrary impure array 
implementations are all OK to implement various heuristics and caching 
schemes on the container side. In fact, Ada moved in that direction 
already by providing crude user-defined array indexing. Clearly as 
hardware evolves towards parallel architectures with partitioned memory, 
low-level arrays will be less frequently exposed in interfaces. 
Comparing older and newer Ada code we can see that trend of moving away 
from plain arrays.

Furthermore, purity of implementation is not contract, per definition 
of. Purity is a non-functional requirement.

There is only few areas of interest for such:

1. Compile-time evaluation/initialization of static objects and constraints.

2. Optimization, especially in the cases fine grained parallelism.

In any case there is no reason to reflect that in the syntax, whatsoever.

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

Re: Ada syntax questions

[Andreas ZEURCHER]

On Saturday, December 19, 2020 at 1:37:32 PM UTC-6, Dmitry A. Kazakov wrote:
> On 2020-12-19 19:40, Andreas ZEURCHER wrote: 
> > On Saturday, December 19, 2020 at 11:49:12 AM UTC-6, Dmitry A. Kazakov wrote: 
> >> On 2020-12-19 18:13, Andreas ZEURCHER wrote: 
> >>> On Saturday, December 19, 2020 at 6:40:28 AM UTC-6, Dmitry A. Kazakov wrote: 
> >>>> On 2020-12-19 12:50, DrPi wrote: 
> 
> >> If contracts were indeed relevant to the syntax then functions without 
> >> contracted side effects must have been called using [] instead of (). 
> >> 
> >> No? Then it is not about the contracts. 
> > 
> > As witnessed by your final sentence quoted below and multiple other replies along this thread, the key tactical advantage of Ada's usage parentheses for array indexing is to accomplish a switcheroo days, weeks, months, years, or decades later: to substitute a function invocation later for what was formerly an array index.
> Not substitute, but to provide whatever implementation necessary. In 
> fact Ada is limited in terms of abstractions. There still exist things 
> which cannot be implemented by user-defined subprograms. Ideally there 
> should be none. Whatever syntax sugar, there should be always a 
> possibility to back it by a user-provided primitive operation.
> > But for people like DrPi who seek contractual assurance of FP-purity of (all?) invoked functions (and overt declaration of impurity of other functions),
> If they are unsatisfied with the higher abstraction level of Ada, they 
> can switch to lower-level languages where implementation details are 
> exposed in syntax. The best we can do is to explain why such exposure is 
> a bad idea. 

No, Dmitry, that is where you are wrong.  In this regard, Ada is the lower-level, grungier, cruder, uncouther programming language, closer to assembly language or ALGOL60.  Languages that have a pure keyword (or equivalent elective designator for compile-time purity enforcement throughout a call-tree of subroutines) are the ones that are high-level, cleaner, more-sophisticated, more-refined programming languages, closer to the lofty heaven of mathematics.  This is actually a sad commentary on software engineering as a professed practice that we cannot even agree which programming-language feature-sets are higher-level versus lower-level, grungier versus cleaner, cruder versus more sophisticated, and uncouther versus more refined.

There is no good reason for Ada to lack all of the mechanisms to support FP (other than historical happenstance, then being substantially frozen in a Steelman mindset without any follow-on Stainlessman (arguably Ada95's, Ada2005's, Ada2012's would-be set of requirements that they have incrementally grown into) then Silverman (arguably SPARK's would-be set of requirements that is an ever-closer-to-finished work-in-progress) then Iridiumman then Goldman then Palladiummand then Platinumman evermore sophisticated requirements for a best-practices programming language to live up to as humankind's understanding of programming, system engineering, software engineering, and mathematics advances over time).

> [ Conceptually Ada has nothing to do with FP and I sincerely hope it 
> never will. ]
> > This 1970s faux pas in letting a silent slip-streamed switcheroo into the core contract-definition declaration mechanism of Ada (not comments! btw, tisk tisk) is merely some tarnish that an AdaNG (next-generation Ada) would fix: e.g., by mandating that all functions (and procedures?) shall be overtly declared & enforced to be pure or impure, which would then mean that only pure functions could substitute for array indexing is the ()-based switcheroo on which so many replies in this thread hang their hat.
> This would be highly undesired. On the contrary impure array 
> implementations are all OK to implement various heuristics and caching 
> schemes on the container side. In fact, Ada moved in that direction 
> already by providing crude user-defined array indexing. Clearly as 
> hardware evolves towards parallel architectures with partitioned memory, 
> low-level arrays will be less frequently exposed in interfaces. 
> Comparing older and newer Ada code we can see that trend of moving away 
> from plain arrays. 
> 
> Furthermore, purity of implementation is not contract, per definition 
> of. Purity is a non-functional requirement. 

So is all of Ada's rich typing/subtypes.  Ada is simply capable expressing some categories of nonfunctional requirements of the design (e.g., rich typing) but not other more-modern categories of nonfunctional requirement (e.g., a pure keyword).

Re: Ada syntax questions

[Dmitry A. Kazakov]

On 2020-12-19 23:11, Andreas ZEURCHER wrote:
> On Saturday, December 19, 2020 at 1:37:32 PM UTC-6, Dmitry A. Kazakov wrote:
>> On 2020-12-19 19:40, Andreas ZEURCHER wrote:

>> If they are unsatisfied with the higher abstraction level of Ada, they
>> can switch to lower-level languages where implementation details are
>> exposed in syntax. The best we can do is to explain why such exposure is
>> a bad idea.
> 
> No, Dmitry, that is where you are wrong.  In this regard, Ada is the lower-level, grungier, cruder, uncouther programming language, closer to assembly language or ALGOL60.

Then we are disagree on the definition of higher level. Mine is the 
level of abstraction away from calculus toward the problem space entities.

[...]

>> Furthermore, purity of implementation is not contract, per definition
>> of. Purity is a non-functional requirement.
> 
> So is all of Ada's rich typing/subtypes.  Ada is simply capable expressing some categories of nonfunctional requirements of the design (e.g., rich typing) but not other more-modern categories of nonfunctional requirement (e.g., a pure keyword).

The abstract datatype (in its original sense, rather than as abstract 
type in Ada) is meant to be a part of abstraction expressing the problem 
space. Purity of whatever implementation has nothing to do with the 
problem space. It is a design artifact.

Moreover, from the standpoint of programming paradigm, the whole 
procedural decomposition is lower level than OO decomposition done in 
terms of types and sets of types.

FP sits firmly in the procedural world. Even ignoring all fundamental 
flaws of FP concept, you will find no interest in FP from my side.

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

Re: Ada syntax questions

[Andreas ZEURCHER]

On Sunday, December 20, 2020 at 2:47:54 AM UTC-6, Dmitry A. Kazakov wrote:
> On 2020-12-19 23:11, Andreas ZEURCHER wrote: 
> > On Saturday, December 19, 2020 at 1:37:32 PM UTC-6, Dmitry A. Kazakov wrote: 
> >> On 2020-12-19 19:40, Andreas ZEURCHER wrote: 
> 
> >> If they are unsatisfied with the higher abstraction level of Ada, they 
> >> can switch to lower-level languages where implementation details are 
> >> exposed in syntax. The best we can do is to explain why such exposure is 
> >> a bad idea. 
> > 
> > No, Dmitry, that is where you are wrong. In this regard, Ada is the lower-level, grungier, cruder, uncouther programming language, closer to assembly language or ALGOL60.
> Then we are disagree on the definition of higher level. Mine is the 
> level of abstraction away from calculus toward the problem space entities. 

Ada's inexpressiveness of imprecision of vagueness of misrepresenting design intent in this regard (of inability to compile-time enforce purity of subroutines) is clearly not abstraction.  It is mere self-imposed blindness, ignoring the purity-enforcement topic altogether.  Assembly language and Ada have the same inability to overtly express and enforce a declaration of FP-purity.  Other languages have a pure keyword or equivalent for subroutines (i.e., functions, procedures, lambdas, coroutines, generators) to overtly express compile-time-enforced purity of the subroutine not making modifications to any data outside of its parameter data and callstack-based transient data.  Clearly when a programming language (i.e., Ada) and assembly language share the same lack of feature, they are the more-primitive.  Clearly when other pure-keyword-equipped programming languages can facilitate & enforce a higher civilization to capture the finer points of a mathematical description of the problem domain via a rule-declaration & compile-time enforcement that assembly language lacks, they are higher-order and less primitive.  There is no valid definition of “higher-order programming language” that permits assembly language's lack of a pure keyword (or equivalent purity-enforcement mechanism) to be a higher-order language than, say, Scala with a pure keyword.  Dmitry, your line of reasoning here of what constitutes a higher-order language is preposterous!

Re: Ada syntax questions

[Randy Brukardt]

"Andreas ZEURCHER" <ZUERCHER_Andreas@outlook.com> wrote in message 
news:bfaef8db-8f57-4a06-b2b4-be091bbfbd11n@googlegroups.com...
.
>Ada's inexpressiveness of imprecision of vagueness of misrepresenting
>design intent in this regard (of inability to compile-time enforce purity 
>of subroutines) ...

Which Ada? Ada 202x has Global aspects specifically for this purpose, and 
they are compile-time enforced. Methinks are you simply looking to troll Ada 
rather than any serious intent.

There's no implementation of Global yet, sadly. Hopefully coming soon.

                                    Randy.




 is clearly not abstraction.



  It is mere self-imposed blindness, ignoring the purity-enforcement topic 
altogether.  Assembly language and Ada have the same inability to overtly 
express and enforce a declaration of FP-purity.  Other languages have a pure 
keyword or equivalent for subroutines (i.e., functions, procedures, lambdas, 
coroutines, generators) to overtly express compile-time-enforced purity of 
the subroutine not making modifications to any data outside of its parameter 
data and callstack-based transient data.  Clearly when a programming 
language (i.e., Ada) and assembly language share the same lack of feature, 
they are the more-primitive.  Clearly when other pure-keyword-equipped 
programming languages can facilitate & enforce a higher civilization to 
capture the finer points of a mathematical description of the problem domain 
via a rule-declaration & compile-time enforcement that assembly language 
lacks, they are higher-order and less primitive.  There is no valid 
definition of "higher-order programming language" that permits assembly 
language's lack of a pure keyword (or equivalent purity-enforcement 
mechanism) to be a higher-order language than, say, Scala with a pure 
keyword.  Dmitry, your line of reasoning here of what constitutes a 
higher-order language is preposterous! 

Re: Ada syntax questions

[Andreas ZEURCHER]

On Monday, December 21, 2020 at 6:58:54 PM UTC-6, Randy Brukardt wrote:
> "Andreas ZEURCHER" wrote in message 
> news:bfaef8db-8f57-4a06...@googlegroups.com...
> . 
> >Ada's inexpressiveness of imprecision of vagueness of misrepresenting 
> >design intent in this regard (of inability to compile-time enforce purity
> >of subroutines) ... 
> 
> Which Ada? Ada 202x has Global aspects specifically for this purpose, and 
> they are compile-time enforced.

This is very good news.  I will need to investigate those AIs further.  I take it from your wording that Global aspects are a general mechanism that a codebase could use to implement e.g. the purity check that FP seeks.  If a general mechanism, it will be interesting to foresee what other categories of axioms can be enforced/assured beyond purity.  Btw, I botched my example of extant programming languages in a prior comment that has a purity check on a call tree.  D has it currently, but it is has been proposed but not yet incorporated into Scala.

> Methinks are you simply looking to troll Ada rather than any serious intent. 

No, absolutely not, at least not in the pejorative that your wording implies.  As a system-engineer •critic• of finding the flaws in the system at large, I am always performing gap analysis on current Ada versus desired state of a universal programming language, using a technique not unlike FMEA.  At some level you are coincidentally correct:  I am negatively disappointed with Ada as much as C++ as much as Scala as much as D as much as Kotlin as much as Swift as much as C# as much as OCaml, but in different ways and to different degrees for each language.  For example, I admire so many portions of Ada, especially its declarative rich typing expressivity and its 35-year lead in accomplishing much of what C++20 will finally get with their oft-pursued concept feature.  Conversely, it is sad that few people realize that Ada has had much of the new whizbang C++20 concept feature for 35 years.  It is as if Ada is a mostly superior product whose salesmen don't consummate as many sales contracts as they ought.  It is useful to study in depth precisely why the superior product partially fails to achieve its potential glory.  One of the most interesting successes of Ada is that its user community seems to have fairly consistently utilized the vast majority of the features of the language on a regular basis.  Despite C++'s perceived popularity by comparison, each C++ codebase utilizes 10% of C++, but worse it is a different 10% of C++ utilized for each different codebase with vast rivalry between codebases regarding which portions of C++ are God's gift to humankind and which portions of C++ are uncouth.  Hence, C++'s perceived popularity is more of a mirage than it first appears because there is no one C++ that is popular, but rather a hundred subsets of C++, 75 of which are intensely unpopular to each of the others and 24 of which are eye-rollingly barely tolerable to each of the others.  As no small achievement, Ada achieves Scott McNealy's “all the wood behind one arrow” vastly more than, say, C++'s or D's everything-and-the-kitchen-sink pandering to me-too-isms.  Scala/JVM, Scala/Native, Scala/OO, and Scala/FP are constantly in a multi-way tug-of-war of sorts (actually 2 orthogonal tugs-of-wars at 2 different ontological levels) that again isn't “all the wood behind one arrow” that Ada better achieves than Scala (so far).

> There's no implementation of Global yet, sadly. Hopefully coming soon. 

It will be interesting to see the furthest push-the-limits extent of applicability of Global aspects.

Re: Ada syntax questions

[Stéphane Rivière]

> Ada's inexpressiveness of imprecision of vagueness of misrepresenting design intent in this regard (of inability to .../...

Thanks for your message. It makes my day. I'm not fluent as you in
english, nor in Ada concepts (I just use it with joy), but let me
express my admiration for assertions such as :

---
Assembly language and Ada have the same inability to overtly express and
enforce a declaration of FP-purity.
---

Although this thought also plunges me into an abyss of reflection.

---
Ada's inexpressiveness of imprecision of vagueness of misrepresenting
design intent in this regard (of inability to compile-time enforce
purity of subroutines) is clearly not abstraction.
---

There remains a mystery.

Why your message reminds me this scene from another genius, Stanley
Kubrick ? https://www.youtube.com/watch?v=iAHJCPoWCC8

No need to answer me, I don't have your skills to debate it. Just be
assured that this post is not mocking and more expressing amazement.

-- 
Be Seeing You
Number Six

Re: Ada syntax questions

[G.B.]

On 20.12.20 17:53, Andreas ZEURCHER wrote:
> On Sunday, December 20, 2020 at 2:47:54 AM UTC-6, Dmitry A. Kazakov wrote:
>> On 2020-12-19 23:11, Andreas ZEURCHER wrote:
>>> On Saturday, December 19, 2020 at 1:37:32 PM UTC-6, Dmitry A. Kazakov wrote:
>>>> On 2020-12-19 19:40, Andreas ZEURCHER wrote:
>>
>>>> If they are unsatisfied with the higher abstraction level of Ada, they
>>>> can switch to lower-level languages where implementation details are
>>>> exposed in syntax. The best we can do is to explain why such exposure is
>>>> a bad idea.
>>>
>>> No, Dmitry, that is where you are wrong. In this regard, Ada is the lower-level, grungier, cruder, uncouther programming language, closer to assembly language or ALGOL60.
>> Then we are disagree on the definition of higher level. Mine is the
>> level of abstraction away from calculus toward the problem space entities.
> 
> (...) Assembly language and Ada have the same inability to overtly express and enforce a declaration of FP-purity. 

Could we drop the Victorian adjectives, though?

Re: Ada syntax questions

[AdaMagica]

DrPi schrieb am Samstag, 19. Dezember 2020 um 12:50:45 UTC+1:
> Calling a function can have side effects. Accessing an array or a 
> variable can't have side effects.
The declaration of the function is a contract about pre and post conditions,
albeit in Ada incomplete. In SPARK, the contract is firm.
As a user of the function, you have to believe the programmer that he follows the contract.
If the implementation needs a side effect, so be it.

If on the other hand you are a maintainer or are chasing a bug,
you have to check the requirements first,
not the body of the function. This comes later.

> > You seem to be implying this is bad; why?
> Reading the code can't tell you the writer's intentions.

The intentions are in the requirements (or in the accompanying comments, you hope
they up to date and not wrong).
If there are none, good luck.

Re: Ada syntax questions

[Stephen Leake]

DrPi <314@drpi.fr> writes:

> Reading the code can't tell you the writer's intentions.

That's what comments and design documents are for.

-- 
-- Stephe

Re: Ada syntax questions

[Andreas ZEURCHER]

On Saturday, December 19, 2020 at 3:51:42 PM UTC-6, Stephen Leake wrote:
> DrPi writes: 
> 
> > Reading the code can't tell you the writer's intentions.
> That's what comments and design documents are for. 

For decades, assembly-language programmers said the same thing about structured-programming feature-set as being representable in mere comments & design documents.  For decades, C programmers said the same thing about Ada's and C++'s and now Rust's feature-sets as being representable in mere comments & design documents.  Arguably, the entire history of programming from Fortran (1957) and ALGOL (1958) forward is to encode the designer's intentions in source code that is vetted by a compiler instead of merely letting comments and design documents bit-rot as the declarative & imperative source code marches onward in the flow of time during initial greenfield completion (after all the “then a miracle occurs” on the blackboard sketches become rubber meeting road) and then during maintenance (as the design incrementally changes).

Re: Ada syntax questions

[DrPi]

Le 19/12/2020 à 22:51, Stephen Leake a écrit :
> DrPi <314@drpi.fr> writes:
> 
>> Reading the code can't tell you the writer's intentions.
> 
> That's what comments and design documents are for.
> 

A good IDE with code analysis showing you object declaration/use is very 
useful. Especially when comments are out of sync with the code.

I'm surprised that no modern tool/language allows the programmer to 
embed a "complete" documentation in source files.
I'm not talking about comments formatted to suit a specific tool 
convention, like Python or Perl doc-strings.
I' talking about embedding schematics, drawings, bitmaps, mathematical 
equations, etc directly in the source code.
Or maybe the reverse : embed source code in standard document. Like 
javascript in SVG files.
Why not a .odt file with code sections ? Ok, a specific file format 
would be better.
Of course, the editor should be specific. Not more a simple text editor.