From: Thomas <fantome.forums.tDeContes@free.fr.invalid>
Subject: Re: Ada and Unicode
Date: Fri, 31 Mar 2023 05:06:22 +0200 [thread overview]
Message-ID: <64264e2f$0$25952$426a74cc@news.free.fr> (raw)
In-Reply-To: t2g0c1$eou$1@dont-email.me
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/
next prev parent reply other threads:[~2023-03-31 3:06 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-17 22:03 Ada and Unicode DrPi
2021-04-18 0:02 ` Luke A. Guest
2021-04-19 9:09 ` DrPi
2021-04-19 8:29 ` Maxim Reznik
2021-04-19 9:28 ` DrPi
2021-04-19 13:50 ` Maxim Reznik
2021-04-19 15:51 ` DrPi
2021-04-19 11:15 ` Simon Wright
2021-04-19 11:50 ` Luke A. Guest
2021-04-19 15:53 ` DrPi
2022-04-03 19:20 ` Thomas
2022-04-04 6:10 ` Vadim Godunko
2022-04-04 14:19 ` Simon Wright
2022-04-04 15:11 ` Simon Wright
2022-04-05 7:59 ` Vadim Godunko
2022-04-08 9:01 ` Simon Wright
2023-03-30 23:35 ` Thomas
2022-04-04 14:33 ` Simon Wright
2021-04-19 9:08 ` Stephen Leake
2021-04-19 9:34 ` Dmitry A. Kazakov
2021-04-19 11:56 ` Luke A. Guest
2021-04-19 12:13 ` Luke A. Guest
2021-04-19 15:48 ` DrPi
2021-04-19 12:52 ` Dmitry A. Kazakov
2021-04-19 13:00 ` Luke A. Guest
2021-04-19 13:10 ` Dmitry A. Kazakov
2021-04-19 13:15 ` Luke A. Guest
2021-04-19 13:31 ` Dmitry A. Kazakov
2022-04-03 17:24 ` Thomas
2021-04-19 13:24 ` J-P. Rosen
2021-04-20 19:13 ` Randy Brukardt
2022-04-03 18:04 ` Thomas
2022-04-06 18:57 ` J-P. Rosen
2022-04-07 1:30 ` Randy Brukardt
2022-04-08 8:56 ` Simon Wright
2022-04-08 9:26 ` Dmitry A. Kazakov
2022-04-08 19:19 ` Simon Wright
2022-04-08 19:45 ` Dmitry A. Kazakov
2022-04-09 4:05 ` Randy Brukardt
2022-04-09 7:43 ` Simon Wright
2022-04-09 10:27 ` DrPi
2022-04-09 16:46 ` Dennis Lee Bieber
2022-04-09 18:59 ` DrPi
2022-04-10 5:58 ` Vadim Godunko
2022-04-10 18:59 ` DrPi
2022-04-12 6:13 ` Randy Brukardt
2021-04-19 16:07 ` DrPi
2021-04-20 19:06 ` Randy Brukardt
2022-04-03 18:37 ` Thomas
2022-04-04 23:52 ` Randy Brukardt
2023-03-31 3:06 ` Thomas [this message]
2023-04-01 10:18 ` Randy Brukardt
2021-04-19 16:14 ` DrPi
2021-04-19 17:12 ` Björn Lundin
2021-04-19 19:44 ` DrPi
2022-04-16 2:32 ` Thomas
2021-04-19 13:18 ` Vadim Godunko
2022-04-03 16:51 ` Thomas
2023-04-04 0:02 ` Thomas
2021-04-19 22:40 ` Shark8
2021-04-20 15:05 ` Simon Wright
2021-04-20 19:17 ` Randy Brukardt
2021-04-20 20:04 ` Simon Wright
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox