Re: Ada and Unicode

[Thomas <fantome.forums.tDeContes@free.fr.invalid>]

In article <t2g0c1$eou$1@dont-email.me>,
 "Randy Brukardt" <randy@rrsoftware.com> wrote:

> "Thomas" <fantome.forums.tDeContes@free.fr.invalid> wrote in message 
> news:fantome.forums.tDeContes-5E3B70.20370903042022@news.free.fr...
> ...
> > as i said to Vadim Godunko, i need to fill a string type with an UTF-8
> > litteral.but i don't think this string type has to manage various 
> > conversions.
> >
> > from my point of view, each library has to accept 1 kind of string type
> > (preferably UTF-8 everywhere),
> > and then, this library has to make needed conversions regarding the
> > underlying API. not the user.
> 
> This certainly is a fine ivory tower solution,

I like to think from an ivory tower, 
and then look at the reality to see what's possible to do or not. :-)



> but it completely ignores two 
> practicalities in the case of Ada:
> 
> (1) You need to replace almost all of the existing Ada language defined 
> packages to make this work. Things that are deeply embedded in both 
> implementations and programs (like Ada.Exceptions and Ada.Text_IO) would 
> have to change substantially. The result would essentially be a different 
> language, since the resulting libraries would not work with most existing 
> programs.

- in Ada, of course we can't delete what's existing, and there are many 
packages which are already in 3 versions (S/WS/WWS).
imho, it would be consistent to make a 4th version of them for a new 
UTF_8_String type.

- in a new language close to Ada, it would not necessarily be a good 
idea to remove some of them, depending on industrial needs, to keep them 
with us.

> They'd have to have different names (since if you used the same 
> names, you change the failures from compile-time to runtime -- or even 
> undetected -- which would be completely against the spirit of Ada), which 
> means that one would have to essentially start over learning and using the 
> resulting language.

i think i don't understand.

> (and it would make sense to use this point to 
> eliminate a lot of the cruft from the Ada design).

could you give an example of cruft from the Ada design, please? :-)


> 
> (2) One needs to be able to read and write data given whatever encoding the 
> project requires (that's often decided by outside forces, such as other 
> hardware or software that the project needs to interoperate with).

> At a minimum, you 
> have to have a way to specify the encoding of files, streams, and hardware 
> interfaces

> That will greatly complicate the interface and 
> implementation of the libraries.

i don't think so.
it's a matter of interfacing libraries, for the purpose of communicating 
with the outside (neither of internal libraries nor of the choice of the 
internal type for the implementation).

Ada.Text_IO.Open.Form already allows (a part of?) this (on the content 
of the files, not on their name), see ARM A.10.2 (6-8).
(write i the reference to ARM correctly?)



> 
> > ... of course, it would be very nice to have a more thicker language with 
> > a garbage collector ...
> 
> I doubt that you will ever see that in the Ada family,

> as analysis and 
> therefore determinism is a very important property for the language.

I completely agree :-)

> Ada has 
> lots of mechanisms for managing storage without directly doing it yourself 
> (by calling Unchecked_Deallocation), yet none of them use any garbage 
> collection in a traditional sense.

sorry, i meant "garbage collector" in a generic sense, not in a 
traditional sense.
that is, as Ada users we could program with pointers and pool, without 
memory leaks nor calling Unchecked_Deallocation.

for example Ada.Containers.Indefinite_Holders.

i already wrote one for constrained limited types.
do you know if it's possible to do it for unconstrained limited types, 
like the class of a limited tagged type?

-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/