Latest suggestion for 202x

Latest suggestion for 202x

[Micah Waddoups]

Following is my comment of appreciation AND my suggestion that is a very basic and important level of support for Unicode.

Frankly, the former rules for directly specifying the contents of an array were perfect, when you can only use parenthesis.  Being able to use square brackets to improve the readability of an array is brilliant because it is familiar to those who use other languages and it does very little to change what is already part of the language definition (square brackets are already use in a way that does not conflict).  Therefore, it is not confusing, just new.

As for the other uses, I can't fully wrap my head around it, because I don't have time to study that part yet.

I have a suggestion, and I am sorry I haven't searched thoroughly to see if someone has suggested this already, though I don't believe they have.  Unicode and UTF are supported very well, however, the support is simply limited to the packages starting at Ada.Strings.UTF_Encoding.  There is no connection to Character_Set found in Maps.  Since many lines of code are designed around the traditional Character_Set in Ada.Strings, the categories of UTF should be conveyable as a (Wide_+)Character_Set so that the much existing code does not have to be fundamentally or completely redesigned in order to use the support to Unicode.  Please consider making Unicode categories available as character_sets (obviously omitting any characters from a category that are out of the range of the string, such as String, sans block drawing, vs. Wide_String, with block drawing).

If the character_set support for Unicode is not included in the pre-built standard libraries, then it will be much elaboration and unnecessary code to try to implement it correctly.

Does anybody agree or disagree with this very simple, but very impactful suggestion?

Re: Latest suggestion for 202x

[Jerry]

On Saturday, June 15, 2019 at 4:59:41 PM UTC-7, Micah Waddoups wrote:
> Following is my comment of appreciation AND my suggestion that is a very basic and important level of support for Unicode.
> 
> Frankly, the former rules for directly specifying the contents of an array were perfect, when you can only use parenthesis.  Being able to use square brackets to improve the readability of an array is brilliant because it is familiar to those who use other languages and it does very little to change what is already part of the language definition (square brackets are already use in a way that does not conflict).  Therefore, it is not confusing, just new.

I agree strongly about using square brackets for arrays. It is such an obvious use considering standard mathematical notation that I have never understood why it is not allowed. Readability and an obvious abstraction related to the real world--it's a no-brainer as far as I know. But I'll bet the gurus will show me to be wrong. One problem at this late date is that you would have to allow both [] and () and so you're going to forget to use [] sometimes and then you have a mixed mini-mess.

Jerry

Re: Latest suggestion for 202x

[Dmitry A. Kazakov]

On 2019-06-16 01:59, Micah Waddoups wrote:

> I have a suggestion, and I am sorry I haven't searched thoroughly to see if someone has suggested this already, though I don't believe they have.  Unicode and UTF are supported very well, however, the support is simply limited to the packages starting at Ada.Strings.UTF_Encoding.  There is no connection to Character_Set found in Maps.  Since many lines of code are designed around the traditional Character_Set in Ada.Strings, the categories of UTF should be conveyable as a (Wide_+)Character_Set so that the much existing code does not have to be fundamentally or completely redesigned in order to use the support to Unicode.  Please consider making Unicode categories available as character_sets (obviously omitting any characters from a category that are out of the range of the string, such as String, sans block drawing, vs. Wide_String, with block drawing).
> 
> If the character_set support for Unicode is not included in the pre-built standard libraries, then it will be much elaboration and unnecessary code to try to implement it correctly.

You may find an implementation of Unicode sets, maps, categorization here:

http://www.dmitry-kazakov.de/ada/strings_edit.htm#7.6

> Does anybody agree or disagree with this very simple, but very impactful suggestion?

Sets and maps have very infrequent use. With Unicode they require sparse 
representation and thus less efficient than Latin-1 variants.

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

Re: Latest suggestion for 202x

[Egil H H]

On Sunday, June 16, 2019 at 1:59:41 AM UTC+2, Micah Waddoups wrote:
<snip>
> Frankly, the former rules for directly specifying the contents of an array were perfect, when you can only use parenthesis.  Being able to use square brackets to improve the readability of an array is brilliant because it is familiar to those who use other languages and it does very little to change what is already part of the language definition (square brackets are already use in a way that does not conflict).  Therefore, it is not confusing, just new.
> 

The brackets are proposed as a syntax for aggregates, and should not be confused with array indexing, which of course will remain as highly readable as ever, not to mention maintainable; An array can be easily swapped for a function without requiring major changes all over the place, as array indexing and function calls have the same syntax.



-- 
~egilhh

Re: Latest suggestion for 202x

[Maciej Sobczak]

> An array can be easily swapped for a function without requiring major changes all over the place, as array indexing and function calls have the same syntax.

A(I) := 7;

Swap(A(I), A(J));

Sort_Subarray(A(1..10));

...

Not really.

Arrays are *not* exchangeable with function calls. Therefore, the fact that they have similar syntax is more a source for confusion than any genuine advantage. Also, the bracketing used is different from any other popular programming language, which further adds to confusion. Also, it cannot be easily found by text-based tools without complete semantic capability (grep, etc.).

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

Re: Latest suggestion for 202x

[Optikos]

On Saturday, June 15, 2019 at 6:59:41 PM UTC-5, Micah Waddoups wrote:
> Following is my comment of appreciation AND my suggestion that is a very basic and important level of support for Unicode.
> 
> Frankly, the former rules for directly specifying the contents of an array were perfect, when you can only use parenthesis.  Being able to use square brackets to improve the readability of an array is brilliant because it is familiar to those who use other languages

1) Fortran and Ada are the mainstream languages that utilize parentheses () for array indexing, following the reason #3 below.
2) Algol-family languages (especially the widely-influential Algol60 and the otherwise-influential-on-Ada Algol68) utilize brackets [] for array indexing.  Nearly all other programming languages (which often are little more than Algol60 rejiggered a little bit) have followed Algol's lead on array indexing via bracket [] syntax.
3) Mathematics utilizes subscripts on variables for the customary equivalent of array indexing, although mathematics could be said to also permit modeling array indexing as a narrower application of the generalized function-parenthesis notation f(i), just like Ada emulates.  Hence, Fortran & Ada are more true to mathematics' f(i) notation for representing array indexing as a function-invocation syntax.

> and it does very little to change what is already part of the language definition (square brackets are already use in a way that does not conflict).  Therefore, it is not confusing, just new.
> 
> As for the other uses, I can't fully wrap my head around it, because I don't have time to study that part yet.
> 
> I have a suggestion, and I am sorry I haven't searched thoroughly to see if someone has suggested this already, though I don't believe they have.  Unicode and UTF are supported very well, however, the support is simply limited to the packages starting at Ada.Strings.UTF_Encoding.  There is no connection to Character_Set found in Maps.  Since many lines of code are designed around the traditional Character_Set in Ada.Strings, the categories of UTF should be conveyable as a (Wide_+)Character_Set so that the much existing code does not have to be fundamentally or completely redesigned in order to use the support to Unicode.  Please consider making Unicode categories available as character_sets (obviously omitting any characters from a category that are out of the range of the string, such as String, sans block drawing, vs. Wide_String, with block drawing).
> 
> If the character_set support for Unicode is not included in the pre-built standard libraries, then it will be much elaboration and unnecessary code to try to implement it correctly.
> 
> Does anybody agree or disagree with this very simple, but very impactful suggestion?

Re: Latest suggestion for 202x

[Dmitry A. Kazakov]

On 2019-06-16 18:54, Maciej Sobczak wrote:
>> An array can be easily swapped for a function without requiring major changes all over the place, as array indexing and function calls have the same syntax.
> 
> A(I) := 7;
> 
> Swap(A(I), A(J));
> 
> Sort_Subarray(A(1..10));
> 
> ...
> 
> Not really.
> 
> Arrays are *not* exchangeable with function calls.

They still must be. Lack of syntax sugar for

    f(i):=x; => f(i,x);

is a problem unrelated to brackets. It is required for sane user-defined 
indexing regardless which brackets.

> Therefore, the fact that they have similar syntax is more a source for confusion than any genuine advantage.

Both are mappings both must have same syntax.

> Also, the bracketing used is different from any other popular programming language, which further adds to confusion.

Why should we care?

> Also, it cannot be easily found by text-based tools without complete semantic capability (grep, etc.).

What for? "Find all references" does everything I need.

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

Re: Latest suggestion for 202x

[John Perry]

On Sunday, June 16, 2019 at 2:34:05 PM UTC-5, Optikos wrote:
> 2) Algol-family languages (especially the widely-influential Algol60 and the otherwise-influential-on-Ada Algol68) utilize brackets [] for array indexing.  Nearly all other programming languages (which often are little more than Algol60 rejiggered a little bit) have followed Algol's lead on array indexing via bracket [] syntax.

One exception to this rule is Eiffel, which uses the @ operator. I decided to see if I could find a summary, and [1] has it. The only really strange one IMHO is Haskell, which uses !.

(This doesn't contradict what you wrote; I just thought it was interesting trivia.)

[1] https://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28array%29#Indexing

Re: Latest suggestion for 202x

[Optikos]

On Sunday, June 16, 2019 at 3:10:55 PM UTC-5, John Perry wrote:
> On Sunday, June 16, 2019 at 2:34:05 PM UTC-5, Optikos wrote:
> > 2) Algol-family languages (especially the widely-influential Algol60 and the otherwise-influential-on-Ada Algol68) utilize brackets [] for array indexing.  Nearly all other programming languages (which often are little more than Algol60 rejiggered a little bit) have followed Algol's lead on array indexing via bracket [] syntax.
> 
> One exception to this rule is Eiffel, which uses the @ operator. I decided to see if I could find a summary, and [1] has it. The only really strange one IMHO is Haskell, which uses !.
> 
> (This doesn't contradict what you wrote; I just thought it was interesting trivia.)
> 
> [1] https://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28array%29#Indexing

Continuing with the thought of not-() and not-[] oddball languages, let's consider what is going on over in the ML family (of which Haskell is a [distant?] cousin):

Over in the ML family languages, array indexing/subscripting has the following variety of syntaxes—one of which resembles the Fortran–Ada a(i) style:

1) Standard ML invokes a function sub as in sub( a, i ), calling to mind subscripts in mathematics notation.

2) CAML allows the shorthand a.(i), somewhat calling to mind the Fortran–Ada precedent of a(i) and the mathematics function notation (but perhaps the . is to also be a visual nod-of-the-hat to the location of subscripts at or below the baseline typographically).  The shorthand a.(i) is short for the verbose Array.get a i.
https://caml.inria.fr/pub/docs/manual-ocaml/libref/Array.html

3) OCaml reserves [] for lists, so OCaml novelly devised [| |] for calling out elements of an array as in a[|i|].
http://xahlee.info/ocaml/ocaml_list.html

4) Breaking with ATS's otherwise strong influence by SML and OCaml as well as break-in with its homage to mathematics/logic (e.g., renaming what we call types to be sorts as in logic; bringing in a thing called type that has no direct analogy in our programming languages), an ATS sats library defers to Algol's [] convention as in a[i] as shorthand for the verbose array0_get_elt_at( a, i ).

And because I forgot to mention it on a prior posting above (although it has nothing to do with ML family), PL/1 follows Fortran's lead of a(i) syntax, meaning that as far as array syntax goes there is a Fortran–PL/1–Ada continuity in constrast to the Algol a[i] contorted abuse of mathematics' [ ] vector/matrix notation.

C & C++ are the weirdo oddballs on a[i][j] being the syntax for Algol's/Pascal's/ATS's/C#'s a[i,j], Fortran–PL/1–Ada's a(i,j), OCaml's a[|i,j|], and CAML's a.(i,j).

Re: Latest suggestion for 202x

[Dmitry A. Kazakov]

On 2019-06-16 22:57, Optikos wrote:

> And because I forgot to mention it on a prior posting above (although it has nothing to do with ML family), PL/1 follows Fortran's lead of a(i) syntax, meaning that as far as array syntax goes there is a Fortran–PL/1–Ada continuity in constrast to the Algol a[i] contorted abuse of mathematics' [ ] vector/matrix notation.

Some books deploy () for matrices too, however [] is more frequent. 
Though for sequences, pairs, tuples etc it is almost always (). So Ada 
83 was pretty much consistent with mathematical notation in aggregates too.

BTW, in mathematics [x] or |_x_| denotes real number truncation.

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

Re: Latest suggestion for 202x

[Lucretia]

On Sunday, 16 June 2019 00:59:41 UTC+1, Micah Waddoups  wrote:

> I have a suggestion, and I am sorry I haven't searched thoroughly to see if someone has suggested this already, though I don't believe they have.  Unicode 

I have, search for it.

>and UTF are supported very well, however, the support is simply limited to the 

No, Ada's support for Unicode is bad, very bad, and broken. There is an article about Ada's Unicode support by someone online, can't remember, thinks it was by Flyx.

Ada needs a full Unicode implementation and not one that layer after layer of abstration which makes it heavy as fuck, sorry League, you're out!

All the existing string stuff needs to be redone with traits and moved into string encoding type stuff.

Luke.

Re: Latest suggestion for 202x

[Egil H H]

On Sunday, June 16, 2019 at 6:54:30 PM UTC+2, Maciej Sobczak wrote:
> > An array can be easily swapped for a function without requiring major changes all over the place, as array indexing and function calls have the same syntax.
> 
> A(I) := 7;
> 
> Swap(A(I), A(J));
> 
> Sort_Subarray(A(1..10));
> 
> ...
> 
> Not really.
> 
> Arrays are *not* exchangeable with function calls.

Maybe not 100%, but that doesn't mean it's not a useful feature. I've certainly had use for it on more than one occasion. It also works the other way around; if your algorithm inside a function is measured to have sub-par performance, it's easy to exchange it for a pre-calculated lookup-table.

> Therefore, the fact that they have similar syntax is more a source for confusion than any genuine advantage. 

I don't find it confusing. Having a similar syntax just makes everything come together in a very nice fashion that feels familiar and aesthetically pleasing to the eyes, i.e. readable.

> Also, the bracketing used is different from any other popular programming language, which further adds to confusion. 

Well, we don't want to repeat the mistakes of others :p


> Also, it cannot be easily found by text-based tools without complete semantic capability (grep, etc.).

There's often more than one array in my codebase... Even within one file there can be both definition and usage of more than one array. So grep-ing for square brackets can give hundreds of false positives. I would much rather just grep for the type name of the actual array I'm interested in.


-- 
~egilhh

Re: Latest suggestion for 202x

[J-P. Rosen]

Le 17/06/2019 à 08:54, Egil H H a écrit :
>> Also, it cannot be easily found by text-based tools without
>> complete semantic capability (grep, etc.).

[shameless plug]
And why would you use such stupid tools? Here are some examples of
things you can search with AdaControl (I hope you can guess what it
means ;-), and there are more to it):

search declarations (array_type);
search declarations (unconstrained_array_type);
search declarations (constrained_array_variable);
search declarations (aliased_array_component);
search array_declarations (index, integer);
search array_declarations (component, float);
search array_declarations (dimensions, min 2, max 3);
...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Latest suggestion for 202x

[Mart van de Wege]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

>> An array can be easily swapped for a function without requiring
> major changes all over the place, as array indexing and function calls
> have the same syntax.
>
> A(I) := 7;
>
> Swap(A(I), A(J));
>
> Sort_Subarray(A(1..10));
>
> ...
>
> Not really.
>
> Arrays are *not* exchangeable with function calls.

Conceptually, an array indexing operation *is* a function call. This is
especially clear when the array elements do not directly map to memory
locations, because then you need to implement an algorithm to find the
nth element of an array.

And even if they directly map there is a function call, even if it as
simple as 'increment the address pointer by the difference of the index
and the base address'.

Mart

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

Re: Latest suggestion for 202x

[Maciej Sobczak]

> Conceptually, an array indexing operation *is* a function call.

There are two basic aggregate data structures in software engineering: arrays and records. Both have elements, which have to be selected from the whole object. In both cases the selection operation is a mapping - hence, a function.

It is interesting to see how much energy is spent on defending the idea that array indexing *must* have the function-call syntax, and yet nobody has a problem with record field accesses.

But hey, name lookup within packages is also a mapping.
So are conditional expressions, both If/Then and Case forms.

Yet, it's convenient to claim that Ada is consistent and readable, because it has round brackets for array indexing?

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

Re: Latest suggestion for 202x

[Dmitry A. Kazakov]

On 2019-06-17 15:35, Maciej Sobczak wrote:
>> Conceptually, an array indexing operation *is* a function call.
> 
> There are two basic aggregate data structures in software engineering: arrays and records. Both have elements, which have to be selected from the whole object. In both cases the selection operation is a mapping - hence, a function.

No, record is not a mapping. A mapping (properly typed) is

    f : I -> V

where I and V are *types*. You cannot define record members this way. 
Member names are not 1st class values, member values have different types.

> Yet, it's convenient to claim that Ada is consistent and readable, because it has round brackets for array indexing?

Right, A(I,J) is far more readable than A[I][J].

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

Re: Latest suggestion for 202x

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> No, record is not a mapping. A mapping (properly typed) is
>    f : I -> V
> where I and V are *types*. You cannot define record members this
> way. Member names are not 1st class values, member values have
> different types.

Each member name is in effect a mapping.  I don't remember the record
member syntax but something like:

   type person is record:
     name : string;
     age : integer
   end record

Then basically "name" is a mapping from person to string, and "age" is a
mapping from person to integer, and there's some syntax sugar to deal
with member notation (xyz.name) and assignment (xyz.name := "John").
Assignment of xyz.name has type

  person -> string -> person

with the side effect of mutating the name.  If you really want to get
theoretical you can think of threading the state of the world through
the mapping, so it really maps one state of the world (plus a string) to
a new state of the world.  That's how monadic I/O in Haskell works.

Re: Latest suggestion for 202x

[Dmitry A. Kazakov]

On 2019-06-17 17:32, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> No, record is not a mapping. A mapping (properly typed) is
>>     f : I -> V
>> where I and V are *types*. You cannot define record members this
>> way. Member names are not 1st class values, member values have
>> different types.
> 
> Each member name is in effect a mapping.  I don't remember the record
> member syntax but something like:
> 
>     type person is record:
>       name : string;
>       age : integer
>     end record
> 
> Then basically "name" is a mapping from person to string, and "age" is a
> mapping from person to integer, and there's some syntax sugar to deal
> with member notation (xyz.name) and assignment (xyz.name := "John").

If Name were an entity in Ada then we could have syntax:

    Name(P)

i.e.

    Name : Person -> String

This would be a mapping. But it is not what Maciej asked, he wanted, I 
suppose, this:

    P(Name)

    P : ? -> ?

instead of P.Name. This is not a mapping of 1st class objects.

He could argue that Ada should follow C++ and use different syntax for 
different names:

    a::b
    a->b
    a.b

To "improve" readability. Why names of an entry, child package, member, 
formal argument of a subprogram etc have all same form A.B. No fun! 
Unicode has 2**24 or so characters free...

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

Re: Latest suggestion for 202x

[G. B.]

John Perry <john.perry@usm.edu> wrote:
> On Sunday, June 16, 2019 at 2:34:05 PM UTC-5, Optikos wrote:
>> 2) Algol-family languages (especially the widely-influential Algol60 and
>> the otherwise-influential-on-Ada Algol68) utilize brackets [] for array
>> indexing.  Nearly all other programming languages (which often are
>> little more than Algol60 rejiggered a little bit) have followed Algol's
>> lead on array indexing via bracket [] syntax.
> 
> One exception to this rule is Eiffel, which uses the @ operator. I
> decided to see if I could find a summary, and [1] has it. The only really
> strange one IMHO is Haskell, which uses !.

Since ‘!’ is sometimes used as a projection _operator_, maybe something
more valuable can be focused: What do you want to do with the indexed
components?
Assume an expression of the intended operations on array elements, as
opposed to them occurring all over the place. The old and the new *for*
loops illustrate, but only outside the loop body.

Re: Latest suggestion for 202x

[Paul Rubin]

John Perry <john.perry@usm.edu> writes:
> One exception to this rule is Eiffel, which uses the @ operator. I
> decided to see if I could find a summary, and [1] has it. The only
> really strange one IMHO is Haskell, which uses !.

Haskell doesn't have syntax for arrays, and its arrays are a library
package, not part of the language.  Haskell has user-defined operators
and the array library defines ! as a subscript operator.

Re: Latest suggestion for 202x

[Keith Thompson]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On 2019-06-17 15:35, Maciej Sobczak wrote:
[...]
>> Yet, it's convenient to claim that Ada is consistent and readable,
>> because it has round brackets for array indexing?
>
> Right, A(I,J) is far more readable than A[I][J].

That conflates two separate issues.  In C (and many C-like
languages), 2-dimensional arrays are simply arrays of arrays, which
is why the syntax for accessing an element is A[I][J].  In Pascal,
for example, 2-dimensional arrays are distinct from arrays of arrays,
and an element of a 2D array can be accessed as A[I,J].

I don't see A(I,J) as being more readable than A[I,J].

Personally, I've always thought that Ada should have used square
brackets for array indexing.  I seem to recall that part of the
rationale was that Ada might be used with character sets that
don't include the '[' and ']' characters, including some variants
of EBCDIC.  But it's not that big a deal, and it's too late
to change it.  Introducing A[I] and removing the existing A(I)
notation would break existing code, which would be unacceptable,
and allowing both would be worse than allowing just one or the other.

I'm not at all persuaded by the argument that array indexing is
interchangeable with function calls.

    A(I) = 42;

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Re: Latest suggestion for 202x

[Jeffrey R. Carter]

On 6/17/19 11:38 PM, Keith Thompson wrote:
> 
> Personally, I've always thought that Ada should have used square
> brackets for array indexing.  I seem to recall that part of the
> rationale was that Ada might be used with character sets that
> don't include the '[' and ']' characters, including some variants
> of EBCDIC.
The Steelman requirements say, "2A. Character Set. The full set of character 
graphics that may be used in source programs shall be given in the language 
definition. Every source program shall also have a representation that uses only 
the following 55 character subset of the ASCII graphics:

     %&'()*+,-./:;<=>?
    0123456789
    ABCDEFGHIJKLMNOPQRSTUVWXYZ"

This is at least partly why Ada did not use brackets. Note also that '"' is not 
in there; '%' may be used instead. That they did not do something similar for 
'[' and ']' may be indicative.

https://dwheeler.com/steelman/steelman.htm#THE_TECHNICAL_REQUIREMENTS

-- 
Jeff Carter
"C++ is like giving an AK-47 to a monk, shooting him
full of crack and letting him loose in a mall and
expecting him to balance your checking account
'when he has the time.'"
Drew Olbrich
52

Re: Latest suggestion for 202x

[Micah Waddoups]

On Sun, Jun 16, 2019, 15:41 'Lucretia' via comp.lang.ada 
> On Sunday, 16 June 2019 00:59:41 UTC+1, Micah Waddoups  wrote:
> 
> > I have a suggestion, and I am sorry I haven't searched thoroughly to see if someone has suggested this already, though I don't believe they have.  Unicode 
> 
> I have, search for it.
> 
> >and UTF are supported very well, however, the support is simply limited to the 
> 
> No, Ada's support for Unicode is bad, very bad, and broken. There is an article about Ada's Unicode support by someone online, can't remember, thinks it was by Flyx.
> 
> Ada needs a full Unicode implementation and not one that layer after layer of abstration which makes it heavy as f***, sorry League, you're out!
> 
> All the existing string stuff needs to be redone with traits and moved into string encoding type stuff.
> 
> Luke.


I agree, with consideration for true Unicode, however, as with Unifont, direct support for at least the literal characters covers perhaps 80% or more of practical use in embedded programming and small programs.  In this the work done seems to classify, map, and handle encoding/decoding each official glyph/character very well.

My intent is to acknowledge the conservative, carefully added support that has been added already. As a programmer eager for advancement and practically in love with the Ada language so far, I am in favor of being very conservative when adding to or removing anything.  The problem implied by our discussion is that as a high and low level general purpose programming language, Ada is sometimes called upon to handle standards or expectations that are very difficult to keep in the realm of Ada's standards, which are readability, maintainability, as complete precision possible abstracted over all target platforms, and integrity.  When full support for Unicode is someday added, I hope it is not too late to be useful, but it needs to be right, and simple enough to apply the wide range of applications or environments supported and considered by the Ada standards.

As is often the case, I think if someone's implementation of Unicode support is correct enough, but small as well, it might be added to a compiler library first.  This would help some people and help those responsible for the next official standard of Ada to vet the techniques of that implementation for the most future prove way to accomplish it in the standard.  

My only idea of something close to merging with the Unicode standard is to add to existing Unicode support a type that is essentially a wide_wide_string for the lower three bytes, but requires all entities to be represented with the full modifying and layout indicators in a particular order that can be parsed however needed.  If that isn't enough, then a tree like structure that groups entities by modifier and visual effects.  Unicode is an idea with the literal specifics being a mix of techniques, so to properly support it with literal code and only one technique, there needs to be an internal encoding that handles the specifics only one way. It is bound to consume more memory than most would like, and if it is to have integrity, it should not compromise accuracy and efficacy to avoid this.  Even so, the bytes representing the modifying or such might be squeezed or enumerated for the internal representation and intelligently included or discarded on export to normal wide_wide_string. Maybe, to accomplish this, each entity could be a record with several wide_character elements and one wide_wide_character. No enumerated or condensed representation of the letter, if it be, may work by itself, because this would ignore the expanding nature of Unicode and might someday cause a problem. As for Asian combined characters, if only the characters are necessary to define an entity, then there is room for all of them.  This is my little unpolished idea.


Ultimately, I feel many concerns about one, the other, or both of the parenthesis and square brackets being preferable, but this is all too particular.  As the standard started with parenthesis and the syntax allows for little change between arguments and array indexes, the flexibility of changing a function to an array is a quality that abstracts the syntax from the implementation.  This is mostly a good thing.

The real reason I am in favor of the square brackets is that it allows clarification of arrays, and possibly aggregates, when building contents without requiring indexing, regardless of the number of components (whether 1 or 10, same syntax). Example:

type Some_Array is array (positive range <>) of integer;

Items3 : Some_Array (1..3) := [50, 60, 80];
Items1 : Some_Array (1..1) := [50];

Items5 : Some_Array := [50, 60, 80, 100, 112];
Items01 : Some_Array := [50];
Items0 : Some_Array := []; -- similar to an empty string ""

type Some_Record is record
  item_one:integer;
  item_two:integer;
end record;

Items2 : Some_Record := [40, 90];


So, basically improving syntax for readability when specifying content.  I see no _other_ situation where there is enough improvement to be worth the quirks and change of switching out the parenthesis.  Certainly not in indexing, and I see no reason no remove the use of parenthesis in building contents.  Others may disagree with me, but I would limit the use of square brackets to filling actual values.  Syntax like:  (Template with extra1, extra2)  should be  possible with [Template with extra1, extra2].   In practical use, there should be a style recommendation to avoid parenthesis when square brackets will work and be more clear, but a style choice of alternating between the parenthesis and the square brackets is unnecessarily confusing in regards to the exact meaning of either.  Limiting the meaning of square brackets makes the syntax more clear and removes the verbosity of indexing single components or even no components, such as an empty array.

Re: Latest suggestion for 202x

[Lucretia]

On Wednesday, 19 June 2019 03:36:50 UTC+1, Micah Waddoups  wrote:
> On Sun, Jun 16, 2019, 15:41 'Lucretia' via comp.lang.ada 
> > On Sunday, 16 June 2019 00:59:41 UTC+1, Micah Waddoups  wrote:
> > 
> > > I have a suggestion, and I am sorry I haven't searched thoroughly to see if someone has suggested this already, though I don't believe they have.  Unicode 
> > 
> > I have, search for it.
> > 
> > >and UTF are supported very well, however, the support is simply limited to the 
> > 
> > No, Ada's support for Unicode is bad, very bad, and broken. There is an article about Ada's Unicode support by someone online, can't remember, thinks it was by Flyx.
> > 
> > Ada needs a full Unicode implementation and not one that layer after layer of abstration which makes it heavy as f***, sorry League, you're out!
> > 
> > All the existing string stuff needs to be redone with traits and moved into string encoding type stuff.
> > 
> > Luke.
> 
> 
> I agree, with consideration for true Unicode, however, as with Unifont, direct support for at least the literal characters covers perhaps 80% or more of practical use in embedded programming and small programs.  In this the work done 

And this is why Ada will never get out of embedded into other areas, because of this narrow minded thinking.

> My intent is to acknowledge the conservative, carefully added support that has been added already. As a programmer eager for advancement and practically in love with the Ada language so far, I am in favor of being very conservative when adding to or removing anything.  The problem implied by our discussion is that 

I'm not, I think there needs to be some quite large sweeping changes. But then, I'm looking at moving away from Ada now.

>as a high and low level general purpose programming language, Ada is sometimes called upon to handle standards or expectations that are very difficult to keep in the realm of Ada's standards, which are readability, maintainability, as complete precision possible abstracted over all target platforms, and integrity.  

Unicode support can be made scalable, it's really not that difficult.

>When full support for Unicode is someday added, I hope it is not too late to be useful, but it needs to be right, and simple enough to apply the wide range of applications or environments supported and considered by the Ada standards.

It has to be now for Ada to make a dent in the current language arena, esp with Rust about.


> As is often the case, I think if someone's implementation of Unicode support is correct enough, but small as well, it might be added to a compiler library first.  This would help some people and help those responsible for the next official standard of Ada to vet the techniques of that implementation for the most future prove way to accomplish it in the standard.  

I was thinking about doing this but have decided on writing my own language instead.

My was this:

1) Follow String and Unbounded_String, by having a static length Unicode_String which would be UTF8. Then have a number of iterators which act on the basic array:

a) The normal array iterator, built-in.
b) Code-point iterator which returns, 32-bit code points.
c) Grapheme cluster iterators.
d) Other iterators, i.e. words.

2) Then the unbounded version which utilises the static stuff, same set of iterators.

3) The character database with access via unicode names and index numbers.

4) Unicode regular expression engine.
 
For embedded only 1 needs to be built, for larger scale apps, you get the full 4.

Luke.

Re: Latest suggestion for 202x

[briot.emmanuel]

> 1) Follow String and Unbounded_String, by having a static length Unicode_String which would be UTF8. Then have a number of iterators which act on the basic array:
> 
> a) The normal array iterator, built-in.
> b) Code-point iterator which returns, 32-bit code points.
> c) Grapheme cluster iterators.
> d) Other iterators, i.e. words.
> 
> 2) Then the unbounded version which utilises the static stuff, same set of iterators.
> 
> 3) The character database with access via unicode names and index numbers.
> 
> 4) Unicode regular expression engine.

It seems to me that all of this can be implemented as a library, and doesn't need to be in the language itself. The nice thing with libraries is that users can provide their own implementation tailored to their needs.

When I implemented GNATCOLL.Strings, I was careful to optionally support unicode via various formal parameters: internally, we store an array of codepoints. Encoding and decoding to utf-8, utf-16 and others is orthogonal to string manipulation (and right now you would have to use some other package for the encoding).

The various iterators you suggest are nice, but can also be implemented on top of it (iterating by words, sentence, paragraph,... is tricky, and irrelevant for most applications). You would provide a `Word_Iterator_Type`, with a GNAT `Iterable` aspect to use, and a function that takes a string and return that iterator.

Regexps are very difficult to implement for unicode, but I would suggest a binding to an existing library like pcre.

I would love to see more such libraries, and this is why I had started GNATCOLL initially. The more the merrier, even when they compete with each other. Users will have more choices. If this is part of the language, it is harder to provide competitors.
And distributions can package the compiler along with a number of such libs to make things easier for new comers to the language.

Project Alire (https://github.com/alire-project/alire) might be a nice way to contribute such libs. GNATCOLL has the same drawback as other libraries regularly mentioned here: it tends to be too monolithic.

Re: Latest suggestion for 202x

[Optikos]

On Wednesday, June 19, 2019 at 6:45:42 AM UTC-5, briot....@gmail.com wrote:
> On Wednesday, June 19, 2019 at 6:14 AM UTC-5, Lucretia wrote:
> > As is often the case, I think if someone's implementation of Unicode support is correct enough, but
> > small as well, it might be added to a compiler library first.  This would help some people and help
> > those responsible for the next official standard of Ada to vet the techniques of that implementation for
> > the most future prove way to accomplish it in the standard.   
> > 
> > I was thinking about doing this but have decided on writing my own language instead. 
> > 
> > My was this:
> > 1) Follow String and Unbounded_String, by having a static length Unicode_String which would be
> > UTF8. Then have a number of iterators which act on the basic array:
> > 
> > a) The normal array iterator, built-in.
> > b) Code-point iterator which returns, 32-bit code points.
> > c) Grapheme cluster iterators.

Luke, I assume that a so-called “cluster” is the denormalization of diacritical marks and combining characters and the like, not some other definition of “cluster” than related to normalization.  If you are utilizing a definition of “cluster” other than related to multiple codepoints not-normalized into one codepoint, then please consider adding an iterator related to normalization and denormalization (utilizing Unicode Consortium terms).

> > d) Other iterators, i.e. words.
> > 
> > 2) Then the unbounded version which utilises the static stuff, same set of iterators.
> > 
> > 3) The character database with access via unicode names and index numbers.
> > 
> > 4) Unicode regular expression engine.
> 
> It seems to me that all of this can be implemented as a library, and doesn't need to be in the language
> itself. The nice thing with libraries is that users can provide their own implementation tailored to their
> needs.
> 
> When I implemented GNATCOLL.Strings, I was careful to optionally support unicode via various formal
> parameters: internally, we store an array of codepoints. Encoding and decoding to utf-8, utf-16 and
> others is orthogonal to string manipulation (and right now you would have to use some other package for
> the encoding).
> 
> The various iterators you suggest are nice, but can also be implemented on top of it (iterating by words,
> sentence, paragraph,... is tricky, and irrelevant for most applications). You would provide a
> `Word_Iterator_Type`, with a GNAT `Iterable` aspect to use, and a function that takes a string and return
> that iterator.
> 
> Regexps are very difficult to implement for unicode, but I would suggest a binding to an existing library
> like pcre.
> 
> I would love to see more such libraries, and this is why I had started GNATCOLL initially. The more the
> merrier, even when they compete with each other. Users will have more choices. If this is part of the
> language, it is harder to provide competitors.
> And distributions can package the compiler along with a number of such libs to make things easier for
> new comers to the language.
> 
> Project Alire (https://github.com/alire-project/alire) might be a nice way to contribute such libs.
> GNATCOLL has the same drawback as other libraries regularly mentioned here: it tends to be too
> monolithic.

Luke, I concur with everything that Emmanuel Briot said above.  But if you find any portion of your vision for a new language (especially the Unicode/ISO10646-related portion) that needs more help from the language proper than a library can provide, then please consider the following:

1) Fork FSF GNAT.

2) Extend existing FSF GNAT to overcome the obstacle(s) that you face for which a library alone would not suffice, needing more help than a library can provide.  (e.g., Optional compiler-enforced rejection of all ISO8652-standardized string types other than your modern complete-solution Unicode string type).

3) Consider having all your extensions as either a command-line option or a pragma or an aspect, so that they can be opted into or opted out of (and to bra-ket your code so that your vision is clearly demarcated from AdaCore's vision & maintenance and ARG's standardization).  In prior posts on c.l.a in prior months, you have proposed language features that alter Ada's fundamental syntax (e.g., {} braces instead of begin-end-esque blocks).  As Randy has correctly stated previously in c.l.a postings a month or 2 ago, syntax is a veneer in a compiler (my paraphrasing, not quotation of Randy), compared to the vastly more complex semantic core of a compiler.  FSF GNAT could be taught to have 2 different syntaxes for Ada opted into or opted out of via command-line, pragma, or aspect:  the current ISO-standardized one and Luke's alternative vision for a bulk of the same semantics.  Then the semantic differences are Luke's course-corrections here and Luke's tweaks there, isolated in the evolved forked FSF GNAT source code by conditionally testing for the prior opt-in or opt-out of a prior command-line argument, pragma, or aspect.

4) In Luke's evolution of forked FSF GNAT, establish industrial practice that is supposed to be the primary input to ISO standardization.  By creating a nonstandard variant of Ada, industrial practice for extensions & variants is established, which can then establish strong standing according to ISO rules (which the ARG must obey).  Such divergent industrial practice is viewed as stronger than proposed AIs that lack prior industrial practice, as I understand ISO regulations.

5) Devise an Ada-esque name that is not Ada for these Ada-language extensions.  For example, perhaps Lucretia Ada, or L-Ada (or Lady Ada).  That way there is a crystal clear differentiated name for your industrial practice versus all the ISO-standard-obeying Ada compilers.

6) Join the ARG.  (And if you can establish citizenship in a nation or Crown possession or territory that lacks an ISO representative on ISO8652, join the ISO8652 committee as a representative of that nation or Crown possession or territory.)  Lobby hard for accepting your established industrial practice as a variant of Ada that needs to be standardized as per ISO regulations.

7) Fix bugs in FSF GNAT on your timeline (i.e., faster) than waiting on AdaCore's timeline.  Establish your industrial-practice evolved FSF GNAT as superior is some metric(s), as a better brand from which to obtain Ada.

All of this together would be less effort in total (and quicker to market) than writing a new compiler from scratch.  Plus, it would more likely reach ISO or ECMA standardization quicker, and hence reshape the programming world in your image more & quicker than writing a compiler from scratch

Re: Latest suggestion for 202x

[G. B.]

Micah Waddoups <dev@micahwelf.us> wrote:
> 
> type Some_Record is record
>   item_one:integer;
>   item_two:integer;
> end record;
> 
> Items2 : Some_Record := [40, 90];
> 
> 
> So, basically improving syntax for readability when specifying content. 

If a program does not specify content in the first place, it makes the
specific values a matter of configuration. Seems preferable, to me.

The argument about distinctive syntax via [,] is tempting and supported
when observing newcomers to programming, if memory serves. In particular,
it still does allow for labels.

Re: Latest suggestion for 202x

[Lucretia]

On Wednesday, 19 June 2019 15:34:16 UTC+1, Optikos  wrote:
> 1) Fork FSF GNAT.

There's pain here in that it's based on GCC which isn't pleasant or easy.
 
maintenance and ARG's standardization).  In prior posts on c.l.a in prior months, you have proposed language features that alter Ada's fundamental syntax (e.g., {} braces instead of begin-end-esque blocks).  As Randy has correctly 

Nope never wanted braces, other people have though.

Re: Latest suggestion for 202x

[Randy Brukardt]

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnef3rnb8d.fsf@kst-u.example.com...
...
> I'm not at all persuaded by the argument that array indexing is
> interchangeable with function calls.
>
>    A(I) = 42;

If A is a container, A(I) *is* a function call. QED. :-)

                              Randy.

Re: Latest suggestion for 202x

[Dmitry A. Kazakov]

On 2019-06-21 00:21, Randy Brukardt wrote:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnef3rnb8d.fsf@kst-u.example.com...
> ...
>> I'm not at all persuaded by the argument that array indexing is
>> interchangeable with function calls.
>>
>>     A(I) = 42;
> 
> If A is a container, A(I) *is* a function call. QED. :-)

It is many function calls actually. I wish it were just one:

    Array_Type'Component_Setter (A, I, 42)

I think Keith probably meant something else, since it is self-evident 
that array indexing is decomposable into calls to properly typed 
subprograms (differently to, say, object construction).

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

Re: Latest suggestion for 202x

[Keith Thompson]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On 2019-06-21 00:21, Randy Brukardt wrote:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lnef3rnb8d.fsf@kst-u.example.com...
>> ...
>>> I'm not at all persuaded by the argument that array indexing is
>>> interchangeable with function calls.
>>>
>>>     A(I) = 42;
>>
>> If A is a container, A(I) *is* a function call. QED. :-)
>
> It is many function calls actually. I wish it were just one:
>
>    Array_Type'Component_Setter (A, I, 42)
>
> I think Keith probably meant something else, since it is self-evident
> that array indexing is decomposable into calls to properly typed
> subprograms (differently to, say, object construction).

Of course the argument about interchangeability of array indexing and
function calling goes back before containers existed in Ada.

In my example, if A is an array variable and I've written
    A(I) = 42;
I *can't* replace A by a function without modifying the code that uses
it.  Array indexing can appear on the LHS of an assignment; a function
call cannot (or at least could not until recently).

I suppose containers weaken that argument -- but if Ada had used [] for
array indexing from the beginning, then presumably containers would have
used that same syntax.

(And again, I'm not suggesting a change to the language.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Re: Latest suggestion for 202x

[Dmitry A. Kazakov]

On 2019-06-21 20:12, Keith Thompson wrote:

> I *can't* replace A by a function without modifying the code that uses
> it.

In short if I can't do something then I don't need it, sour grapes...

> I suppose containers weaken that argument

No, it is no argument regardless.

If Ada has problems with array abstraction, and it has, that is 
irrelevant to the point that this is the *same* abstraction.

A language that syntactically distinguish array calls and function calls 
breaks the abstraction or lacks it completely.

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

Re: Latest suggestion for 202x

[Keith Thompson]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On 2019-06-21 20:12, Keith Thompson wrote:
>> I *can't* replace A by a function without modifying the code that uses
>> it.
>
> In short if I can't do something then I don't need it, sour grapes...
>
>> I suppose containers weaken that argument
>
> No, it is no argument regardless.
>
> If Ada has problems with array abstraction, and it has, that is 
> irrelevant to the point that this is the *same* abstraction.
>
> A language that syntactically distinguish array calls and function calls 
> breaks the abstraction or lacks it completely.

Is breaking that abstraction such a bad thing?  Why *should* array
indexing and function calls be treated as the same thing?  What about
record component selection?  What operations *aren't* function calls?

But please don't overestimate how much I care about this.  In my
opinion, it's really not that big a deal.  I personally like brackets
better than parentheses for array indexing, but I have no particular
problem with Ada's choice.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Re: Latest suggestion for 202x

[Dmitry A. Kazakov]

On 2019-06-21 22:24, Keith Thompson wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> On 2019-06-21 20:12, Keith Thompson wrote:
>>> I *can't* replace A by a function without modifying the code that uses
>>> it.
>>
>> In short if I can't do something then I don't need it, sour grapes...
>>
>>> I suppose containers weaken that argument
>>
>> No, it is no argument regardless.
>>
>> If Ada has problems with array abstraction, and it has, that is
>> irrelevant to the point that this is the *same* abstraction.
>>
>> A language that syntactically distinguish array calls and function calls
>> breaks the abstraction or lacks it completely.
> 
> Is breaking that abstraction such a bad thing?

Yes, because abstraction is useful. Arrays have no "physical" meaning. 
It is always an artifact of software design, some implementation detail, 
not to expose.

> Why *should* array
> indexing and function calls be treated as the same thing?

Because they model the same thing, a mapping, when arrays come in 
consideration.

> What about
> record component selection?

Same. It is not mapping of ordered 1st class object to 1st class object 
in this case, but surely the syntax sugar of record member selection 
must be same for records and functions. And it is, since Ada 2005 
started to support dotted notation:

    R.X  -- Record member *or* call to primitive X of R or ...

> What operations *aren't* function calls?

Ideally there should be none. All built-in syntax forms must be 
available for user-defined operations. Ada suffers greatly when it 
violates this design principle, e.g. consider "and then", "range", "in", 
"'Image" etc.

> But please don't overestimate how much I care about this.  In my
> opinion, it's really not that big a deal.  I personally like brackets
> better than parentheses for array indexing, but I have no particular
> problem with Ada's choice.

In my view it is a language design problem. I have nothing against 
adding further types of brackets: {}, <>, || but they all must be 
user-defined.

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

Re: Latest suggestion for 202x

[Randy Brukardt]

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnd0j6kdsl.fsf@kst-u.example.com...
...
> In my example, if A is an array variable and I've written
>    A(I) = 42;
> I *can't* replace A by a function without modifying the code that uses
> it.  Array indexing can appear on the LHS of an assignment; a function
> call cannot (or at least could not until recently).

That's not strictly true, as anyone who's tried to write an Ada compiler 
knows. Even in Ada 83, you had to resolve assignments that are overloaded on 
both sides (the ACATS insists on it):

    Func(I).all := Func2(J);

or

    Func(I).C := Func3(K);

You're right, of course, that you can't put a function there without a 
dereference (explicit or implicit). And that's still true, we've just hidden 
the dereference even better.

                                                 Randy.

Re: Latest suggestion for 202x

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:qekjbb$vu0$1@gioia.aioe.org...
...
>> Why *should* array
>> indexing and function calls be treated as the same thing?
>
> Because they model the same thing, a mapping, when arrays come in 
> consideration.

Arrays only exist because they mapped easily to early hardware. In a modern, 
container-based system, there is no reason for them to exist separately --  
they are just a kind of container. Perhaps the compiler would map them to a 
hardware array specially, but that simply doesn't matter.

Specifically, I'd suggest that "array" is a container very similar to 
"vector" (esp. the bounded flavor). It should have roughly the same 
operations, just no expandability.

That would require separating strings and arrays, but that would clearly be 
a good thing -- a string needs to support multiple representations while 
that's rarely needed for arrays.

                                                      Randy.

Re: Latest suggestion for 202x

[Dmitry A. Kazakov]

On 2019-06-22 10:43, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:qekjbb$vu0$1@gioia.aioe.org...
> ...
>>> Why *should* array
>>> indexing and function calls be treated as the same thing?
>>
>> Because they model the same thing, a mapping, when arrays come in
>> consideration.
> 
> Arrays only exist because they mapped easily to early hardware. In a modern,
> container-based system, there is no reason for them to exist separately --
> they are just a kind of container. Perhaps the compiler would map them to a
> hardware array specially, but that simply doesn't matter.

Another cases are having control over memory management and 
marshaling/serialization, when keeping object in a single contiguous 
location is important.

> Specifically, I'd suggest that "array" is a container very similar to
> "vector" (esp. the bounded flavor). It should have roughly the same
> operations, just no expandability.
> 
> That would require separating strings and arrays, but that would clearly be
> a good thing -- a string needs to support multiple representations while
> that's rarely needed for arrays.

Just let strings have two container interfaces at once. Here is a case 
where different brackets could be useful. E.g. S(I) could give a code 
point/character, S[J] could give an encoding unit, e.g. octet for UTF-8 
string or word for UCS-2. However overloading of () should work no 
problem, IMO.

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

Re: Latest suggestion for 202x

[Keith Thompson]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnd0j6kdsl.fsf@kst-u.example.com...
> ...
>> In my example, if A is an array variable and I've written
>>    A(I) = 42;
>> I *can't* replace A by a function without modifying the code that uses
>> it.  Array indexing can appear on the LHS of an assignment; a function
>> call cannot (or at least could not until recently).
>
> That's not strictly true, as anyone who's tried to write an Ada compiler 
> knows. Even in Ada 83, you had to resolve assignments that are overloaded on 
> both sides (the ACATS insists on it):
>
>     Func(I).all := Func2(J);
>
> or
>
>     Func(I).C := Func3(K);
>
> You're right, of course, that you can't put a function there without a 
> dereference (explicit or implicit). And that's still true, we've just hidden 
> the dereference even better.

I should have said that an array indexing operation cannot appear *as*
the LHS of an assignment.  Of course either an array indexing operation
or a function call can be *part of* the LHS of an assignment.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Re: Latest suggestion for 202x

[Keith Thompson]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On 2019-06-21 22:24, Keith Thompson wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> On 2019-06-21 20:12, Keith Thompson wrote:
>>>> I *can't* replace A by a function without modifying the code that uses
>>>> it.
>>>
>>> In short if I can't do something then I don't need it, sour grapes...
>>>
>>>> I suppose containers weaken that argument
>>>
>>> No, it is no argument regardless.
>>>
>>> If Ada has problems with array abstraction, and it has, that is
>>> irrelevant to the point that this is the *same* abstraction.
>>>
>>> A language that syntactically distinguish array calls and function calls
>>> breaks the abstraction or lacks it completely.
>>
>> Is breaking that abstraction such a bad thing?
>
> Yes, because abstraction is useful. Arrays have no "physical"
> meaning. It is always an artifact of software design, some
> implementation detail, not to expose.
>
>> Why *should* array
>> indexing and function calls be treated as the same thing?
>
> Because they model the same thing, a mapping, when arrays come in
> consideration.

I disagree.  Array indexing operations refer to elements of an array
object.  Function calls yield a value, and can have side effects.

>> What about
>> record component selection?
>
> Same. It is not mapping of ordered 1st class object to 1st class
> object in this case, but surely the syntax sugar of record member
> selection must be same for records and functions. And it is, since Ada
> 2005 started to support dotted notation:
>
>    R.X  -- Record member *or* call to primitive X of R or ...

So would you prefer "R.X" to be written as "R(X)" (or perhaps "X(R)")?

>> What operations *aren't* function calls?
>
> Ideally there should be none. All built-in syntax forms must be
> available for user-defined operations. Ada suffers greatly when it
> violates this design principle, e.g. consider "and then", "range",
> "in", "'Image" etc.

If you want Lisp, you know where to find it.

>> But please don't overestimate how much I care about this.  In my
>> opinion, it's really not that big a deal.  I personally like brackets
>> better than parentheses for array indexing, but I have no particular
>> problem with Ada's choice.
>
> In my view it is a language design problem. I have nothing against
> adding further types of brackets: {}, <>, || but they all must be
> user-defined.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Re: Latest suggestion for 202x

[Bill Findlay]

On 22 Jun 2019, Keith Thompson wrote
(in article <lnr27likgv.fsf@kst-u.example.com>):

> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>  writes:
> > On 2019-06-21 22:24, Keith Thompson wrote:
> > > "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>  writes:
> > > > On 2019-06-21 20:12, Keith Thompson wrote:
> > > > > I *can't* replace A by a function without modifying the code that uses
> > > > > it.
> > > >
> > > > In short if I can't do something then I don't need it, sour grapes...
> > > >
> > > > > I suppose containers weaken that argument
> > > >
> > > > No, it is no argument regardless.
> > > >
> > > > If Ada has problems with array abstraction, and it has, that is
> > > > irrelevant to the point that this is the *same* abstraction.
> > > >
> > > > A language that syntactically distinguish array calls and function calls
> > > > breaks the abstraction or lacks it completely.
> > >
> > > Is breaking that abstraction such a bad thing?
> >
> > Yes, because abstraction is useful. Arrays have no "physical"
> > meaning. It is always an artifact of software design, some
> > implementation detail, not to expose.
> >
> > > Why *should* array
> > > indexing and function calls be treated as the same thing?
> >
> > Because they model the same thing, a mapping, when arrays come in
> > consideration.
>
> I disagree. Array indexing operations refer to elements of an array
> object. Function calls yield a value, and can have side effects.

They are not exactly the same, but similar enough.
This is/was known as "uniform referent notation".
I take the pragmatic view that it can be very handy.

> > > What about record component selection?
> >
> > Same. It is not mapping of ordered 1st class object to 1st class
> > object in this case, but surely the syntax sugar of record member
> > selection must be same for records and functions. And it is, since Ada
> > 2005 started to support dotted notation:
> >
> > R.X -- Record member *or* call to primitive X of R or ...
>
> So would you prefer "R.X" to be written as "R(X)" (or perhaps "X(R)")?

X(R) is exactly how it was written in ALGOL W
(to get a field of the record pointed to by R,
as there were no off-heap records).

In Pascal f^ could be either data in the buffer
of file f or data referenced by a pointer f.
When I converted some s/w from 1900 Pascal to 2900 Pascal,
all the accesses to filed data became accesses to data
in virtual memory without changing the source code.

-- 
Bill Findlay

Re: Latest suggestion for 202x

[Dmitry A. Kazakov]

On 2019-06-22 19:44, Keith Thompson wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> On 2019-06-21 22:24, Keith Thompson wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>> On 2019-06-21 20:12, Keith Thompson wrote:
>>>>> I *can't* replace A by a function without modifying the code that uses
>>>>> it.
>>>>
>>>> In short if I can't do something then I don't need it, sour grapes...
>>>>
>>>>> I suppose containers weaken that argument
>>>>
>>>> No, it is no argument regardless.
>>>>
>>>> If Ada has problems with array abstraction, and it has, that is
>>>> irrelevant to the point that this is the *same* abstraction.
>>>>
>>>> A language that syntactically distinguish array calls and function calls
>>>> breaks the abstraction or lacks it completely.
>>>
>>> Is breaking that abstraction such a bad thing?
>>
>> Yes, because abstraction is useful. Arrays have no "physical"
>> meaning. It is always an artifact of software design, some
>> implementation detail, not to expose.
>>
>>> Why *should* array
>>> indexing and function calls be treated as the same thing?
>>
>> Because they model the same thing, a mapping, when arrays come in
>> consideration.
> 
> I disagree.  Array indexing operations refer to elements of an array
> object.  Function calls yield a value, and can have side effects.

So can array indexing, when you get a copy of an array element, its 
construction may do whatever you wanted, e.g. spawn format c: /q.

Anyway side effects, when relevant, break abstraction and thus cannot 
count for that reason.

>>> What about
>>> record component selection?
>>
>> Same. It is not mapping of ordered 1st class object to 1st class
>> object in this case, but surely the syntax sugar of record member
>> selection must be same for records and functions. And it is, since Ada
>> 2005 started to support dotted notation:
>>
>>     R.X  -- Record member *or* call to primitive X of R or ...
> 
> So would you prefer "R.X" to be written as "R(X)" (or perhaps "X(R)")?

No, because X is not a 1st class object. The point is that in both cases 
the syntax is same. Same syntax for same intention. In the case of 
mappings the preferable syntax is A(I), regardless the implementation. 
In the case of hierarchical naming the preferable syntax is R.X.

The syntax should help understanding the programmer's intent, rather 
than reflect irrelevant details like if A is an array or R is a record.

>>> What operations *aren't* function calls?
>>
>> Ideally there should be none. All built-in syntax forms must be
>> available for user-defined operations. Ada suffers greatly when it
>> violates this design principle, e.g. consider "and then", "range",
>> "in", "'Image" etc.
> 
> If you want Lisp, you know where to find it.

Except that Lisp has no syntax but balanced brackets. Another 
degenerative language of that sort is Forth. The problem is that the 
syntax is so dire that it cannot assist program understanding.

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

Re: Latest suggestion for 202x

[Optikos]

On Saturday, June 22, 2019 at 12:44:01 PM UTC-5, Keith Thompson wrote:
> "Dmitry A. Kazakov" writes:
> > On 2019-06-21 22:24, Keith Thompson wrote:
> >> "Dmitry A. Kazakov" writes:
> >>> On 2019-06-21 20:12, Keith Thompson wrote:
> >>>> I *can't* replace A by a function without modifying the code that uses
> >>>> it.
> >>>
> >>> In short if I can't do something then I don't need it, sour grapes...
> >>>
> >>>> I suppose containers weaken that argument
> >>>
> >>> No, it is no argument regardless.
> >>>
> >>> If Ada has problems with array abstraction, and it has, that is
> >>> irrelevant to the point that this is the *same* abstraction.
> >>>
> >>> A language that syntactically distinguish array calls and function calls
> >>> breaks the abstraction or lacks it completely.
> >>
> >> Is breaking that abstraction such a bad thing?
> >
> > Yes, because abstraction is useful. Arrays have no "physical"
> > meaning. It is always an artifact of software design, some
> > implementation detail, not to expose.
> >
> >> Why *should* array
> >> indexing and function calls be treated as the same thing?
> >
> > Because they model the same thing, a mapping, when arrays come in
> > consideration.
> 
> I disagree.  Array indexing operations refer to elements of an array
> object.  Function calls yield a value, and can have side effects.

It appears that it was the European predecessor languages of Algol58 that introduced the [ ] notation for subscripts in imperative programming languages.  The IBM-dominated Americans utilized ( ) notation for subscripts in all of their languages up to that point (and counting PL/I and Ada, a little beyond).  Without mentioning array-subscripting syntax per se, tne of the principal contributors to Algol58 mentions this European-vs-American rivalry on page 12 of:
https://web.archive.org/web/20120422070035/http://conservancy.umn.edu/bitstream/107106/1/oh128flb.pdf

Hence, we have the pro-IBM [ ] syntax (e.g., Fortran, Cobol, PL/I, CHILL, Ada) versus the pro-Algol58 ( ) syntax (Algol58, Algol60, Algol68, CPL, BCPL, C) rivalry playing out 6 decades later in this thread.

What seems almost shockingly peculiar to me is that France-based Green Team chose the American-oriented pro-IBM [ ] syntax instead of their favorite-son European ( ) syntax.  (ITU's European-PTT-centric CCITT choosing to follow PL/I's lead on ( ) array subscripting syntax in the Ccitt HIgh Level Language is no surprise at all since so much of CHILL is obviously designed by full-fledged unashamed IBM-lovers.)  By the late 1970s, there obviously was more to the brackets-versus-parentheses rivalry than mere trans-Atlantic geography, as it seems to be during the 1950s (e.g., ZMMD's languages and Algol60 versus Fortran and Cobol) and 1960s (e.g., Algol60 and Simula versus PL/I).  I strongly suspect that the European natural continent-wide embrace of [ ] notation for some sort of ••index register•• has a bracket-based syntactic antecedent in assembly languages on European computers (e.g., Zuse? in West Germany) during the 1950s that was absent in American computers' assembly languages during that same period, hence why ZMMD naturally gravitated strongly toward [ ] brackets whereas IBM-oriented Americans did not (and apparently gravitated by default toward mathematics' notation for f(x) itemized-inventory discrete functions as the closest analogous notation in mathematics when utilizing arrays as lookup tables [LUTs]).

Re: Latest suggestion for 202x

[Optikos]

On Saturday, June 22, 2019 at 3:48:28 PM UTC-5, Optikos wrote:
> On Saturday, June 22, 2019 at 12:44:01 PM UTC-5, Keith Thompson wrote:
> > "Dmitry A. Kazakov" writes:
> > > On 2019-06-21 22:24, Keith Thompson wrote:
> > >> "Dmitry A. Kazakov" writes:
> > >>> On 2019-06-21 20:12, Keith Thompson wrote:
> > >>>> I *can't* replace A by a function without modifying the code that uses
> > >>>> it.
> > >>>
> > >>> In short if I can't do something then I don't need it, sour grapes...
> > >>>
> > >>>> I suppose containers weaken that argument
> > >>>
> > >>> No, it is no argument regardless.
> > >>>
> > >>> If Ada has problems with array abstraction, and it has, that is
> > >>> irrelevant to the point that this is the *same* abstraction.
> > >>>
> > >>> A language that syntactically distinguish array calls and function calls
> > >>> breaks the abstraction or lacks it completely.
> > >>
> > >> Is breaking that abstraction such a bad thing?
> > >
> > > Yes, because abstraction is useful. Arrays have no "physical"
> > > meaning. It is always an artifact of software design, some
> > > implementation detail, not to expose.
> > >
> > >> Why *should* array
> > >> indexing and function calls be treated as the same thing?
> > >
> > > Because they model the same thing, a mapping, when arrays come in
> > > consideration.
> > 
> > I disagree.  Array indexing operations refer to elements of an array
> > object.  Function calls yield a value, and can have side effects.
> 
> It appears that it was the European predecessor languages of Algol58 that introduced the [ ] notation for subscripts in imperative programming languages.  The IBM-dominated Americans utilized ( ) notation for subscripts in all of their languages up to that point (and counting PL/I and Ada, a little beyond).  Without mentioning array-subscripting syntax per se, tne of the principal contributors to Algol58 mentions this European-vs-American rivalry on page 12 of:
> https://web.archive.org/web/20120422070035/http://conservancy.umn.edu/bitstream/107106/1/oh128flb.pdf
> 
> Hence, we have the pro-IBM [ ] syntax (e.g., Fortran, Cobol, PL/I, CHILL, Ada) versus the pro-Algol58 ( ) syntax (Algol58, Algol60, Algol68, CPL, BCPL, C) rivalry playing out 6 decades later in this thread.
> 
> What seems almost shockingly peculiar to me is that France-based Green Team chose the
> American-oriented pro-IBM [ ] syntax instead of their favorite-son European ( ) syntax.

Doh!  (I added the [ ] and ( ) throughout the reply toward the end of editing.)  That sentence should have been:
What seems almost shockingly peculiar to me is that France-based Green Team chose the American-oriented pro-IBM ( ) syntax instead of their favorite-son European [ ] syntax.

>  (ITU's European-PTT-centric CCITT choosing to follow PL/I's lead on ( ) array subscripting syntax in the
> Ccitt HIgh Level Language is no surprise at all since so much of CHILL is obviously designed by
> full-fledged unashamed IBM-lovers.)  By the late 1970s, there obviously was more to the
> brackets-versus-parentheses rivalry than mere trans-Atlantic geography, as it seems to be during the
> 1950s (e.g., ZMMD's languages and Algol60 versus Fortran and Cobol) and 1960s (e.g., Algol60 and
> Simula versus PL/I).  I strongly suspect that the European natural continent-wide embrace of [ ] notation
> for some sort of ••index register•• has a bracket-based syntactic antecedent in assembly languages on
> European computers (e.g., Zuse? in West Germany) during the 1950s that was absent in American
> computers' assembly languages during that same period, hence why ZMMD naturally gravitated strongly
> toward [ ] brackets whereas IBM-oriented Americans did not (and apparently gravitated by default
> toward mathematics' notation for f(x) itemized-inventory discrete functions as the closest analogous
> notation in mathematics when utilizing arrays as lookup tables [LUTs]).

Re: Latest suggestion for 202x

[G.B.]

On 22.06.19 20:37, Dmitry A. Kazakov wrote:
>> I disagree.  Array indexing operations refer to elements of an array
>> object.  Function calls yield a value, and can have side effects.
> 
> So can array indexing, when you get a copy of an array element, its construction may do whatever you wanted, e.g. spawn format c: /q.

The way in which your argument is composed is not really doing justice
to the original ideas of array and record, I think.

It is fusing features of almost different languages, to no avail
(other than formalism).

The original *ideas* of array and record are fairly simple:
store plain old data objects somewhere, by index or by name.
No fancy effects.

Your argument then invokes not-so-simple and later ideas of object
construction and its operations. These would become associated with array
components, but also with any other object. Hence, not specifically
with arrays.

I think it is a better idea to conceive of Ada arrays as low
level representational types. Arrays should only exist in private parts,
or bodies.

So, when there is a need to design some interface, re-inventing
arrays will not be the optimal starting point. Traditional arrays
are far too simplistic and universal. They therefore cannot express
specific requirements. Such as:
* Random-Access,
* Independent-Components,
* Sparse,
* Associating<K, V> where K in I'Class and ...
* ...

A user defined operator for "Element Access" then becomes a distinct subject,
and a distinct opportunity.

Re: Latest suggestion for 202x

[Dmitry A. Kazakov]

On 2019-06-23 09:38, G.B. wrote:
> On 22.06.19 20:37, Dmitry A. Kazakov wrote:
>>> I disagree.  Array indexing operations refer to elements of an array
>>> object.  Function calls yield a value, and can have side effects.
>>
>> So can array indexing, when you get a copy of an array element, its 
>> construction may do whatever you wanted, e.g. spawn format c: /q.
> 
> The way in which your argument is composed is not really doing justice
> to the original ideas of array and record, I think.
> 
> It is fusing features of almost different languages, to no avail
> (other than formalism).
> 
> The original *ideas* of array and record are fairly simple:
> store plain old data objects somewhere, by index or by name.
> No fancy effects.
> 
> Your argument then invokes not-so-simple and later ideas of object
> construction and its operations. These would become associated with array
> components, but also with any other object. Hence, not specifically
> with arrays.

Even machine code objects need construction and have operations. People 
make mistake thinking of types and operations as something you can add 
later or ignore. There is no such thing as typeless value.

> I think it is a better idea to conceive of Ada arrays as low
> level representational types. Arrays should only exist in private parts,
> or bodies.

It is two different concepts - interface and implementation.

1. array as a container object of certain properties (mapping)
2. array as a building block, a primitive types algebra operation

2 implements 1.

Array indexing is an interface. Why must this interface have a syntax 
dependent on its ultimate implementation? Did people learn nothing from 
the Unbounded_String fiasco?

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

Re: Latest suggestion for 202x

[Dennis Lee Bieber]

On Sat, 22 Jun 2019 13:48:26 -0700 (PDT), Optikos <optikos@verizon.net>
declaimed the following:


>
>What seems almost shockingly peculiar to me is that France-based Green Team chose the American-oriented pro-IBM [ ] 

	Remember -- part of the requirement was for embedded systems. Yes,
there is a difference between the target and development environments
but... It was probably defined that the language itself had to be able to
be written using a minimal character set -- hence the case insensitive
nature of keywords and identifiers, and likely the lack of [] (which didn't
exist on many keyboards... In particular, look at the character set of the
IBM 029 keypunch, which was the major means of input to computers
(interactive time-share via CRTs wasn't all that common, nor was the
on-line storage for programs to be edited).

http://www.columbia.edu/cu/computinghistory/029.html
"""
and is missing several of ASCII's other characters: {}[]\^~
"""
	Heck, the () aren't even next to each other on that diagram, but on the
E and N keys.


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Re: Latest suggestion for 202x

[Optikos]

On Sunday, June 23, 2019 at 2:38:31 AM UTC-5, G.B. wrote:
> On 22.06.19 20:37, Dmitry A. Kazakov wrote:
> >> I disagree.  Array indexing operations refer to elements of an array
> >> object.  Function calls yield a value, and can have side effects.
> > 
> > So can array indexing, when you get a copy of an array element, its construction may do whatever you wanted, e.g. spawn format c: /q.
> 
> The way in which your argument is composed is not really doing justice
> to the original ideas of array and record, I think.
> 
> It is fusing features of almost different languages, to no avail
> (other than formalism).
> 
> The original *ideas* of array and record are fairly simple:
> store plain old data objects somewhere, by index or by name.
> No fancy effects.
> 
> Your argument then invokes not-so-simple and later ideas of object
> construction and its operations. These would become associated with array
> components, but also with any other object. Hence, not specifically
> with arrays.
> 
> I think it is a better idea to conceive of Ada arrays as low
> level representational types. Arrays should only exist in private parts,
> or bodies.

I concur.  A modern backwards-compatibility-breaking course-correction of Ada would strictly enforce this prohibition of arrays outside of private.  It would do this as part of dismantling what was in vogue prior to 1980 but has not weathered the test of time due to Ada80 and Ada83 paying far too much homage to legacy languages prior to 1980.  (Thank goodness that Ada did not need to purge PL/1-esque nesting-level numbers from its records as CHILL eventually needed to do, as a hideous example of paying too much homage to one of the worst ideas in PL/1.)

> So, when there is a need to design some interface, re-inventing
> arrays will not be the optimal starting point. Traditional arrays
> are far too simplistic and universal. They therefore cannot express
> specific requirements. Such as:
> * Random-Access,

Since array indexing is already random access, I assume that you mean:  clearly differentiating O(1) random-access from O(log n) logarithmic search from O(n) linear search and so forth.  With the exception of the obviously-generalized f(x) notation (whose very nature says that this function's functionality could be from anything anywhere in the wide world of mathematics), it has always annoyed me that various languages (e.g., the STL-C++-influenced ones; the SNOBOL-influenced ones) abuse the Algol58 [ ] random-access array notation for non-random-access associative searches, such as non-vector containers in C++' s STL and in SNOBOL's tables.  Sloppy† programmers then don't think through the big-Omicron (a.k.a. big-O) Landau-notation growth rates accumulating from innermost to outermost nesting of data-structures and/or of loops.

† which is most of them nowadays

> * Independent-Components,
> * Sparse,
> * Associating<K, V> where K in I'Class and ...
> * ...
> 
> A user defined operator

I would use the plural there:  separate operators (or some sort of obvious visual clue) for different kinds of access other than random-access dense arrays, assuming that f(x) notation is not utilized for arrays, because f(x) notation says to any mathematician-minded programmer that all assumptions of what f(x) is might not be true until further inspection

> for "Element Access" then becomes a distinct subject,
> and a distinct opportunity.

Re: Latest suggestion for 202x

[Dennis Lee Bieber]

On Sun, 23 Jun 2019 11:34:06 -0700 (PDT), Optikos <optikos@verizon.net>
declaimed the following:

>I concur.  A modern backwards-compatibility-breaking course-correction of Ada would strictly enforce this prohibition of arrays outside of private.  It would do this as part of dismantling what was in vogue prior to 1980 but has not weathered the test of time due to Ada80 and Ada83 paying far too much homage to legacy languages prior to 1980.  (Thank goodness that Ada did not need to purge PL/1-esque nesting-level numbers from its records as CHILL eventually needed to do, as a hideous example of paying too much homage to one of the worst ideas in PL/1.)
>

	Since PL/1 attempted to be a do-all language, I suspect level nesting
numbers were purloined from COBOL.


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Re: Latest suggestion for 202x

[Per Sandberg]

Just a humble comment concerning using square brackets for for indexing 
arrays.
Why care if it is an array or function ?
That's just some implementation details that is of interest when using 
assembler.
/P



On 6/16/19 1:59 AM, Micah Waddoups wrote:
> Following is my comment of appreciation AND my suggestion that is a very basic and important level of support for Unicode.
> 
> Frankly, the former rules for directly specifying the contents of an array were perfect, when you can only use parenthesis.  Being able to use square brackets to improve the readability of an array is brilliant because it is familiar to those who use other languages and it does very little to change what is already part of the language definition (square brackets are already use in a way that does not conflict).  Therefore, it is not confusing, just new.
> 
> As for the other uses, I can't fully wrap my head around it, because I don't have time to study that part yet.
> 
> I have a suggestion, and I am sorry I haven't searched thoroughly to see if someone has suggested this already, though I don't believe they have.  Unicode and UTF are supported very well, however, the support is simply limited to the packages starting at Ada.Strings.UTF_Encoding.  There is no connection to Character_Set found in Maps.  Since many lines of code are designed around the traditional Character_Set in Ada.Strings, the categories of UTF should be conveyable as a (Wide_+)Character_Set so that the much existing code does not have to be fundamentally or completely redesigned in order to use the support to Unicode.  Please consider making Unicode categories available as character_sets (obviously omitting any characters from a category that are out of the range of the string, such as String, sans block drawing, vs. Wide_String, with block drawing).
> 
> If the character_set support for Unicode is not included in the pre-built standard libraries, then it will be much elaboration and unnecessary code to try to implement it correctly.
> 
> Does anybody agree or disagree with this very simple, but very impactful suggestion?
> 
> 
> 

Re: Latest suggestion for 202x

[J-P. Rosen]

Le 23/06/2019 à 19:42, Dennis Lee Bieber a écrit :
> It was probably defined that the language itself had to be able to
> be written using a minimal character set -- hence the case insensitive
> nature of keywords and identifiers, and likely the lack of []
Yes for [], but no for case insensitivity.

Case sensitivity brings nothing but confusion. The principle for any
decent language is that if two identifiers mean the same thing in the
brain of the reader, then they must correspond to the same entity. And
the meaning of a word is not changed by casing.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Latest suggestion for 202x

[Paul Rubin]

"J-P. Rosen" <rosen@adalog.fr> writes:
> Case sensitivity brings nothing but confusion.  The principle for any
> decent language is that if two identifiers mean the same thing in the
> brain of the reader, then they must correspond to the same entity. And
> the meaning of a word is not changed by casing.

I don't find this in Haskell.  The names of types and of data
constructors begin with upper-case letters, and the names of ordinary
variables begin with lower-case letters.  So you could have

   string = "hello"

and that is separate from the type String.  That might not be great
style but the language lets you tell the two apart.

Re: Latest suggestion for 202x

[Niklas Holsti]

On 19-06-24 08:40 , Paul Rubin wrote:
> "J-P. Rosen" <rosen@adalog.fr> writes:
>> Case sensitivity brings nothing but confusion.  The principle for any
>> decent language is that if two identifiers mean the same thing in the
>> brain of the reader, then they must correspond to the same entity. And
>> the meaning of a word is not changed by casing.

Yes... most of the time. I recall, as a young programmer several decades 
ago, being stumped for an embarrassingly long time by a compilation 
error from the Burroughs Algol compiler, which would not accept the code

    real IF;
    ...
    if IF > limit then ...

In a case-insensitive language, of course "IF" is just another form of 
the reserved word "if". But my brain insisted that "IF" is an identifier 
that is an acronym / abbreviation for "Intermediate_Frequency"... even 
when "if" and "IF" were adjacent as above!

(That was in the main-frame punch-card ages, when one did not want to 
use long identifiers because of (a) the 80-column (or 72-column) limit, 
and (b) the high risk of spelling the identifier incorrectly and having 
to punch a new card, after waiting an hour or so for the compiler's 
snide error messages.)

> I don't find this in Haskell.  The names of types and of data
> constructors begin with upper-case letters, and the names of ordinary
> variables begin with lower-case letters.  So you could have
>
>    string = "hello"
>
> and that is separate from the type String.  That might not be great
> style but the language lets you tell the two apart.

Formally true, and usually harmless in today's programming styles where 
identifiers are usually longish words.

Ada's case-insensitivity (which I do prefer, in spite of my anecdote 
above) was, I believe, meant to prevent errors such as having two 
variables called respectively "x" and "X" and confusing between them.

Even if "X" is a type identifier and "x" a variable name, there could be 
confusion between, say, x'Size and X'Size, which look very similar but 
can have different values.

That said, I do find it a little irksome that Ada's rules force one to 
invent different, case-insensitive names for types on the one hand, and 
variables on the other. This leads to conventions such as adding "_T" to 
all type names, which seem ugly and cumbersome at first. But I don't 
have any suggestions for a better solution.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Latest suggestion for 202x

[Stefan.Lucks]

[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]

> The principle for any decent language is that if two identifiers mean 
> the same thing in the brain of the reader, then they must correspond to 
> the same entity. And the meaning of a word is not changed by casing.

Do you really think so?

I think, the capical 'I' is very different from i=sqrt(-1).  ;-)

To be honest, I agreee that Ada should not adapt the concept of many other 
case-sensitive languages that capitalization (such as changing between 'I' 
and 'i') gives you two different identifiers, to be used interchangeably.

On the other hand, I would prefer the compiler to require a consistent 
casing. E.g., if you define an identifier "Ada", you are not allowed to 
spell the same identifier as "ADA", "ada", "aDa", ... anywhere else.

Or consider

   procedure P(Value: Integer) is ...
   ...

   declare
     i: Integer := 0;
   begin
     declare
       I: Integer := 1;
     begin
       P(i); -- DOES call P(1) in Ada, since Ada is
             --      not case-sensitive
             -- WOULD call P(0) in most other modern languages,
             --       which usually have case-sensitive identifiers
             -- SHOULD be treated as an error, because "i" and "I"
             --        are *different* identifiers, nevertheless "i"
             --        has been hidden by  "I".
      end;
   end;


--------  I  love  the  taste  of  Cryptanalysis  in  the morning!  --------
www.uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-lucks
----Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany----

Re: Latest suggestion for 202x

[Niklas Holsti]

On 19-06-24 14:12 , Stefan.Lucks@uni-weimar.de wrote:
>> The principle for any decent language is that if two identifiers mean
>> the same thing in the brain of the reader, then they must correspond
>> to the same entity. And the meaning of a word is not changed by casing.
>
> Do you really think so?
>
> I think, the capical 'I' is very different from i=sqrt(-1).  ;-)
>
> To be honest, I agreee that Ada should not adapt the concept of many
> other case-sensitive languages that capitalization (such as changing
> between 'I' and 'i') gives you two different identifiers, to be used
> interchangeably.
>
> On the other hand, I would prefer the compiler to require a consistent
> casing. E.g., if you define an identifier "Ada", you are not allowed to
> spell the same identifier as "ADA", "ada", "aDa", ... anywhere else.

GNAT has the option -gnatyr, which is described as follows:

"r (check references): If the letter r appears in the string after 
-gnaty then all identifier references must be cased in the same way as 
the corresponding declaration. No specific casing style is imposed on 
identifiers. The only requirement is for consistency of references with 
declarations."

I agree that this consistency is a good rule in general, but sometimes 
it results in strange-looking code when a program with a certain 
identifier-casing convention (say, Title_Case) uses a library with 
another convention (say, UPPER_CASE), leading to subprogram calls with 
different conventions. Oh well, perhaps Title_Case will be the law 
someday...

> Or consider
>
>   procedure P(Value: Integer) is ...
>   ...
>
>   declare
>     i: Integer := 0;
>   begin
>     declare
>       I: Integer := 1;
>     begin
>       P(i); -- DOES call P(1) in Ada, since Ada is
>             --      not case-sensitive
>             -- WOULD call P(0) in most other modern languages,
>             --       which usually have case-sensitive identifiers
>             -- SHOULD be treated as an error, because "i" and "I"
>             --        are *different* identifiers, nevertheless "i"
>             --        has been hidden by  "I".
>      end;
>   end;

GNAT also has "-gnatwh", which would warn about "I" hiding "i".

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Latest suggestion for 202x

[J-P. Rosen]

Le 24/06/2019 à 07:40, Paul Rubin a écrit :
>  So you could have
> 
>    string = "hello"
> 
> and that is separate from the type String.  That might not be great
> style but the language lets you tell the two apart.
Exactly. This is a very bad name, since it tells you nothing more than
what you already know. What is the purpose of the string? Better not to
favour that style.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Latest suggestion for 202x

[J-P. Rosen]

Le 24/06/2019 à 13:12, Stefan.Lucks@uni-weimar.de a écrit :
> On the other hand, I would prefer the compiler to require a consistent
> casing. E.g., if you define an identifier "Ada", you are not allowed to
> spell the same identifier as "ADA", "ada", "aDa", ... anywhere else.
AdaControl can do that...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Latest suggestion for 202x

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:gnbslvFqofgU1@mid.individual.net...
...
>Oh well, perhaps Title_Case will be the law someday...

I'd be careful describing "Title_Case". Most people use what I'd call 
"Mixed_Case", where the first letter of every word is capitalized. 
Janus/Ada's pretty printer (and our in-house style guide) use true 
Title_Case, where the first letter of words that would be capitalized in a 
title are the only ones given in upper case.

For instance, "Ada_is_Great" is in Title_Case, "Ada_Is_Great" is in 
Mixed_Case.

I get a lot of grief from the ARG since all of my identifiers are naturally 
in Title_Case, but the RM uses Mixed_Case (in part to avoid arguments about 
language).

                                                  Randy.

Re: Latest suggestion for 202x

[Keith Thompson]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:gnbslvFqofgU1@mid.individual.net...
> ...
>>Oh well, perhaps Title_Case will be the law someday...
>
> I'd be careful describing "Title_Case". Most people use what I'd call 
> "Mixed_Case", where the first letter of every word is capitalized. 
> Janus/Ada's pretty printer (and our in-house style guide) use true 
> Title_Case, where the first letter of words that would be capitalized in a 
> title are the only ones given in upper case.
>
> For instance, "Ada_is_Great" is in Title_Case, "Ada_Is_Great" is in 
> Mixed_Case.
>
> I get a lot of grief from the ARG since all of my identifiers are naturally 
> in Title_Case, but the RM uses Mixed_Case (in part to avoid arguments about 
> language).

My understanding is that "is" would be capitalized in title case, since
it's a verb.  But I'm sure there are variants in which it isn't.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Re: Latest suggestion for 202x

[Jeffrey R. Carter]

On 6/24/19 10:22 PM, Randy Brukardt wrote:
> 
> For instance, "Ada_is_Great" is in Title_Case, "Ada_Is_Great" is in
> Mixed_Case.

A poor choice, since verbs, no matter how short, are capitalized in standard 
American titles. For example, Heinlein's /The Moon Is a Harsh Mistress/, which 
is capitalized exactly like that on the the cover of my copy.

Wonders_of_Ada is in title case.

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail
17

Re: Latest suggestion for 202x

[Stephen Leake]

On Monday, June 24, 2019 at 12:16:51 AM UTC-7, Niklas Holsti wrote:

> That said, I do find it a little irksome that Ada's rules force one to 
> invent different, case-insensitive names for types on the one hand, and 
> variables on the other. This leads to conventions such as adding "_T" to 
> all type names, which seem ugly and cumbersome at first. But I don't 
> have any suggestions for a better solution.

As has been suggested on this list before, one solution to this is to prefix the type name with the package name:

package Cool_Thing is

   type Thing is tagged record ... end record;

   function Do_It (Thing : in Cool_Thing.Thing) return Integer;

It's still only syntax noise, but it appears in fewer places than the _T suffix.

--  Stephe