Re: Latest suggestion for 202x

[Optikos <optikos@verizon.net>]

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