Re: Latest suggestion for 202x

[Micah Waddoups <dev@micahwelf.us>]

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.