* Ada syntax questions @ 2020-12-17 22:39 DrPi 2020-12-17 23:18 ` Gabriele Galeotti ` (6 more replies) 0 siblings, 7 replies; 35+ messages in thread From: DrPi @ 2020-12-17 22:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-17 22:39 Ada syntax questions DrPi @ 2020-12-17 23:18 ` Gabriele Galeotti 2020-12-18 8:26 ` Jeffrey R. Carter ` (5 subsequent siblings) 6 siblings, 0 replies; 35+ messages in thread From: Gabriele Galeotti @ 2020-12-17 23:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-17 22:39 Ada syntax questions DrPi 2020-12-17 23:18 ` Gabriele Galeotti @ 2020-12-18 8:26 ` Jeffrey R. Carter 2020-12-18 9:18 ` Dmitry A. Kazakov ` (4 subsequent siblings) 6 siblings, 0 replies; 35+ messages in thread From: Jeffrey R. Carter @ 2020-12-18 8:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-17 22:39 Ada syntax questions DrPi 2020-12-17 23:18 ` Gabriele Galeotti 2020-12-18 8:26 ` Jeffrey R. Carter @ 2020-12-18 9:18 ` Dmitry A. Kazakov 2020-12-18 16:55 ` Mart van de Wege ` (3 subsequent siblings) 6 siblings, 0 replies; 35+ messages in thread From: Dmitry A. Kazakov @ 2020-12-18 9:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-17 22:39 Ada syntax questions DrPi ` (2 preceding siblings ...) 2020-12-18 9:18 ` Dmitry A. Kazakov @ 2020-12-18 16:55 ` Mart van de Wege 2020-12-18 17:38 ` Björn Lundin ` (2 subsequent siblings) 6 siblings, 0 replies; 35+ messages in thread From: Mart van de Wege @ 2020-12-18 16:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-17 22:39 Ada syntax questions DrPi ` (3 preceding siblings ...) 2020-12-18 16:55 ` Mart van de Wege @ 2020-12-18 17:38 ` Björn Lundin 2020-12-18 19:35 ` Niklas Holsti 2020-12-18 23:09 ` Stephen Leake 6 siblings, 0 replies; 35+ messages in thread From: Björn Lundin @ 2020-12-18 17:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-17 22:39 Ada syntax questions DrPi ` (4 preceding siblings ...) 2020-12-18 17:38 ` Björn Lundin @ 2020-12-18 19:35 ` Niklas Holsti 2020-12-20 21:59 ` Keith Thompson 2020-12-20 21:59 ` Keith Thompson 2020-12-18 23:09 ` Stephen Leake 6 siblings, 2 replies; 35+ messages in thread From: Niklas Holsti @ 2020-12-18 19:35 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-18 19:35 ` Niklas Holsti @ 2020-12-20 21:59 ` Keith Thompson 2020-12-22 1:04 ` Randy Brukardt 2020-12-20 21:59 ` Keith Thompson 1 sibling, 1 reply; 35+ messages in thread From: Keith Thompson @ 2020-12-20 21:59 UTC (permalink / raw) 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 */ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-20 21:59 ` Keith Thompson @ 2020-12-22 1:04 ` Randy Brukardt 2020-12-22 8:00 ` Dmitry A. Kazakov 2020-12-22 13:48 ` AdaMagica 0 siblings, 2 replies; 35+ messages in thread From: Randy Brukardt @ 2020-12-22 1:04 UTC (permalink / raw) "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. . ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-22 1:04 ` Randy Brukardt @ 2020-12-22 8:00 ` Dmitry A. Kazakov 2020-12-23 1:23 ` Randy Brukardt 2020-12-22 13:48 ` AdaMagica 1 sibling, 1 reply; 35+ messages in thread From: Dmitry A. Kazakov @ 2020-12-22 8:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-22 8:00 ` Dmitry A. Kazakov @ 2020-12-23 1:23 ` Randy Brukardt 2020-12-23 8:59 ` Dmitry A. Kazakov 0 siblings, 1 reply; 35+ messages in thread From: Randy Brukardt @ 2020-12-23 1:23 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-23 1:23 ` Randy Brukardt @ 2020-12-23 8:59 ` Dmitry A. Kazakov 2020-12-24 4:06 ` Randy Brukardt 0 siblings, 1 reply; 35+ messages in thread From: Dmitry A. Kazakov @ 2020-12-23 8:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-23 8:59 ` Dmitry A. Kazakov @ 2020-12-24 4:06 ` Randy Brukardt 2020-12-24 9:37 ` Dmitry A. Kazakov 0 siblings, 1 reply; 35+ messages in thread From: Randy Brukardt @ 2020-12-24 4:06 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-24 4:06 ` Randy Brukardt @ 2020-12-24 9:37 ` Dmitry A. Kazakov 0 siblings, 0 replies; 35+ messages in thread From: Dmitry A. Kazakov @ 2020-12-24 9:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-22 1:04 ` Randy Brukardt 2020-12-22 8:00 ` Dmitry A. Kazakov @ 2020-12-22 13:48 ` AdaMagica 1 sibling, 0 replies; 35+ messages in thread From: AdaMagica @ 2020-12-22 13:48 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-18 19:35 ` Niklas Holsti 2020-12-20 21:59 ` Keith Thompson @ 2020-12-20 21:59 ` Keith Thompson 2020-12-21 8:08 ` Dmitry A. Kazakov 1 sibling, 1 reply; 35+ messages in thread From: Keith Thompson @ 2020-12-20 21:59 UTC (permalink / raw) 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 */ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-20 21:59 ` Keith Thompson @ 2020-12-21 8:08 ` Dmitry A. Kazakov 0 siblings, 0 replies; 35+ messages in thread From: Dmitry A. Kazakov @ 2020-12-21 8:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-17 22:39 Ada syntax questions DrPi ` (5 preceding siblings ...) 2020-12-18 19:35 ` Niklas Holsti @ 2020-12-18 23:09 ` Stephen Leake 2020-12-19 11:50 ` DrPi 6 siblings, 1 reply; 35+ messages in thread From: Stephen Leake @ 2020-12-18 23:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-18 23:09 ` Stephen Leake @ 2020-12-19 11:50 ` DrPi 2020-12-19 12:40 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: DrPi @ 2020-12-19 11:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-19 11:50 ` DrPi @ 2020-12-19 12:40 ` Dmitry A. Kazakov 2020-12-19 17:13 ` Andreas ZEURCHER 2020-12-19 17:01 ` AdaMagica 2020-12-19 21:51 ` Stephen Leake 2 siblings, 1 reply; 35+ messages in thread From: Dmitry A. Kazakov @ 2020-12-19 12:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-19 12:40 ` Dmitry A. Kazakov @ 2020-12-19 17:13 ` Andreas ZEURCHER 2020-12-19 17:49 ` Dmitry A. Kazakov 0 siblings, 1 reply; 35+ messages in thread From: Andreas ZEURCHER @ 2020-12-19 17:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-19 17:13 ` Andreas ZEURCHER @ 2020-12-19 17:49 ` Dmitry A. Kazakov 2020-12-19 18:40 ` Andreas ZEURCHER 0 siblings, 1 reply; 35+ messages in thread From: Dmitry A. Kazakov @ 2020-12-19 17:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-19 17:49 ` Dmitry A. Kazakov @ 2020-12-19 18:40 ` Andreas ZEURCHER 2020-12-19 19:37 ` Dmitry A. Kazakov 0 siblings, 1 reply; 35+ messages in thread From: Andreas ZEURCHER @ 2020-12-19 18:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-19 18:40 ` Andreas ZEURCHER @ 2020-12-19 19:37 ` Dmitry A. Kazakov 2020-12-19 22:11 ` Andreas ZEURCHER 0 siblings, 1 reply; 35+ messages in thread From: Dmitry A. Kazakov @ 2020-12-19 19:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-19 19:37 ` Dmitry A. Kazakov @ 2020-12-19 22:11 ` Andreas ZEURCHER 2020-12-20 8:47 ` Dmitry A. Kazakov 0 siblings, 1 reply; 35+ messages in thread From: Andreas ZEURCHER @ 2020-12-19 22:11 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-19 22:11 ` Andreas ZEURCHER @ 2020-12-20 8:47 ` Dmitry A. Kazakov 2020-12-20 16:53 ` Andreas ZEURCHER 0 siblings, 1 reply; 35+ messages in thread From: Dmitry A. Kazakov @ 2020-12-20 8:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-20 8:47 ` Dmitry A. Kazakov @ 2020-12-20 16:53 ` Andreas ZEURCHER 2020-12-22 0:58 ` Randy Brukardt ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Andreas ZEURCHER @ 2020-12-20 16:53 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-20 16:53 ` Andreas ZEURCHER @ 2020-12-22 0:58 ` Randy Brukardt 2020-12-22 2:39 ` Andreas ZEURCHER 2020-12-22 10:05 ` Stéphane Rivière 2020-12-25 9:34 ` G.B. 2 siblings, 1 reply; 35+ messages in thread From: Randy Brukardt @ 2020-12-22 0:58 UTC (permalink / raw) "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! ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-22 0:58 ` Randy Brukardt @ 2020-12-22 2:39 ` Andreas ZEURCHER 0 siblings, 0 replies; 35+ messages in thread From: Andreas ZEURCHER @ 2020-12-22 2:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-20 16:53 ` Andreas ZEURCHER 2020-12-22 0:58 ` Randy Brukardt @ 2020-12-22 10:05 ` Stéphane Rivière 2020-12-25 9:34 ` G.B. 2 siblings, 0 replies; 35+ messages in thread From: Stéphane Rivière @ 2020-12-22 10:05 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-20 16:53 ` Andreas ZEURCHER 2020-12-22 0:58 ` Randy Brukardt 2020-12-22 10:05 ` Stéphane Rivière @ 2020-12-25 9:34 ` G.B. 2 siblings, 0 replies; 35+ messages in thread From: G.B. @ 2020-12-25 9:34 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-19 11:50 ` DrPi 2020-12-19 12:40 ` Dmitry A. Kazakov @ 2020-12-19 17:01 ` AdaMagica 2020-12-19 21:51 ` Stephen Leake 2 siblings, 0 replies; 35+ messages in thread From: AdaMagica @ 2020-12-19 17:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-19 11:50 ` DrPi 2020-12-19 12:40 ` Dmitry A. Kazakov 2020-12-19 17:01 ` AdaMagica @ 2020-12-19 21:51 ` Stephen Leake 2020-12-19 22:20 ` Andreas ZEURCHER 2020-12-20 14:10 ` DrPi 2 siblings, 2 replies; 35+ messages in thread From: Stephen Leake @ 2020-12-19 21:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-19 21:51 ` Stephen Leake @ 2020-12-19 22:20 ` Andreas ZEURCHER 2020-12-20 14:10 ` DrPi 1 sibling, 0 replies; 35+ messages in thread From: Andreas ZEURCHER @ 2020-12-19 22:20 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Ada syntax questions 2020-12-19 21:51 ` Stephen Leake 2020-12-19 22:20 ` Andreas ZEURCHER @ 2020-12-20 14:10 ` DrPi 1 sibling, 0 replies; 35+ messages in thread From: DrPi @ 2020-12-20 14:10 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2020-12-25 9:34 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-17 22:39 Ada syntax questions DrPi 2020-12-17 23:18 ` Gabriele Galeotti 2020-12-18 8:26 ` Jeffrey R. Carter 2020-12-18 9:18 ` Dmitry A. Kazakov 2020-12-18 16:55 ` Mart van de Wege 2020-12-18 17:38 ` Björn Lundin 2020-12-18 19:35 ` Niklas Holsti 2020-12-20 21:59 ` Keith Thompson 2020-12-22 1:04 ` Randy Brukardt 2020-12-22 8:00 ` Dmitry A. Kazakov 2020-12-23 1:23 ` Randy Brukardt 2020-12-23 8:59 ` Dmitry A. Kazakov 2020-12-24 4:06 ` Randy Brukardt 2020-12-24 9:37 ` Dmitry A. Kazakov 2020-12-22 13:48 ` AdaMagica 2020-12-20 21:59 ` Keith Thompson 2020-12-21 8:08 ` Dmitry A. Kazakov 2020-12-18 23:09 ` Stephen Leake 2020-12-19 11:50 ` DrPi 2020-12-19 12:40 ` Dmitry A. Kazakov 2020-12-19 17:13 ` Andreas ZEURCHER 2020-12-19 17:49 ` Dmitry A. Kazakov 2020-12-19 18:40 ` Andreas ZEURCHER 2020-12-19 19:37 ` Dmitry A. Kazakov 2020-12-19 22:11 ` Andreas ZEURCHER 2020-12-20 8:47 ` Dmitry A. Kazakov 2020-12-20 16:53 ` Andreas ZEURCHER 2020-12-22 0:58 ` Randy Brukardt 2020-12-22 2:39 ` Andreas ZEURCHER 2020-12-22 10:05 ` Stéphane Rivière 2020-12-25 9:34 ` G.B. 2020-12-19 17:01 ` AdaMagica 2020-12-19 21:51 ` Stephen Leake 2020-12-19 22:20 ` Andreas ZEURCHER 2020-12-20 14:10 ` DrPi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox