Re: Latest suggestion for 202x

[Lucretia <laguest9000@googlemail.com>]

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.