Re: Jeux de caractères, notamment UT F-8

Bonjour :-)


Désolé d'avoir tardé à continuer ce fil
(c'est en partie du au fait que je tape au clavier lentement).

L'avantage, c'est que ça m'a évité d'écrire beaucoup de bêtises,
et je crois que maintenant j'ai les idées un peu plus claires sur ce sujet là :-)
(mais pas certain que je sois arrivé au bout, encore).



Le 7 déc. 2020 à 22:36, Thomas De Contes a écrit :

> Le 11 sept. 2020 à 16:25, Jean-Pierre Rosen a écrit :
> 
>> Le 08/09/2020 à 19:34, Thomas De Contes a écrit :
>> 
>>> L'idéal, ça serais de pouvoir écrire un programme en UTF-8, y compris des littéraux de chaines de caractères, et que ça soit interprété directement sous la forme Ada.Strings.UTF_Encoding.UTF_8_String, sans aucune conversion
>>> (par exemple pour qu'on puisse le passer directement à GtkAda).
>>> 
>>> - Est ce que dans les révisions futures, notamment la prochaine, vous continuez à vous rapprocher de ça ?

>> Pas sûr que ça s'applique, mais il y a une généralisation des litéraux
>> qui pourrait bien faire ça.

Si j'ai bien compris c'est de ça qu'il s'agit :
http://www.ada-auth.org/standards/2xrm/html/RM-4-2-1.html


La partie la plus importante de ce message :

S'il était permis d'appliquer cet aspect String_Literal à Ada.Strings.UTF_Encoding.UTF_8_String, avec Ada.Strings.UTF_Encoding.Wide_Wide_Strings.Encode,
il suffirait que GtkAda s'aligne, et je pourrais tranquillement utiliser UTF-8 dans mes appels à GtkAda
(sans souci de comment ça va être interprété, si j'ai pas oublié un appel à Encode à un endroit (que le compilateur ne me signalera pas), etc ...),
... et je serais heureux ! :-)

Est il envisageable d'arriver à ça dans une prochaine version du langage ?
Peut-être dans une "correction technique" intermédiaire ? Voire dans la toute prochaine version, s'il n'est pas encore trop tard (soyons fou) ?


Je vois 2 problèmes pour y arriver :
- Il me semble que c'est réservé aux types, donc interdit aux sous-types.
- Si je comprend bien le paragraphe 7, la fonction n'est appelée que si le type n'est pas en forme de "string type" ?
C'est à dire que si le type est en forme de "string type", l'aspect String_Literal est autorisé mais il est ignoré ?? Je suppose que je n'ai pas bien compris.

Est ce que quelqu'un aurais le temps de m'expliquer les freins, ce qui empêche d'atteindre l'état qui rendrait le truc applicable à Ada.Strings.UTF_Encoding.UTF_8_String ?


> 
> je ne comprend pas bien ce que tu veux dire :
> - "une généralisation des littéraux", c'est à dire par exemple on pourra faire un littéral directement pour Unbounded_String ? bonne nouvelle, c'est un truc qui manquait :-)

À lire
http://www.ada-auth.org/standards/2xrm/html/RM-A-4-5.html
on dirait que ça non plus, c'est pas encore fait. :-(

C'est bête, il y a des tas de cas où ça serais super pratique de pouvoir passer en paramètre un littéral qui serait une liste de chaines de longueurs variables : ("une chaine", "une autre chaine", "et encore une").

Et là, on est à 2 doigts de pouvoir le faire.
(Le type en paramètre ressemblerais à "array(range <>) of Unbounded_String".)


Il me semble que ce qui empêche, cette fois ci, c'est que l'aspect String_Literal demande une fonction qui prend obligatoirement un type Wide_Wide_String.

Pourquoi ça n'accepte pas n'importe quel "string type" ?

S'il y a une bonne raison, il reste la possibilité d'ajouter :
   function To_Unbounded_String (Source : in Wide_Wide_String)
      return Unbounded_String;

L'inconvénient serait simplement que ça serais plus logique de laisser au compilateur le soin de vérifier que tous les caractères sont dans Latin-1, comme il le fait avec les littéraux pour String, plutôt que de devoir gérer ça dans cette fonction.




(J'avais écrit plus haut : )

> Avoir son code source en UTF-8 et dire à gnat que c'est en Latin-1, pour pouvoir remplir un UTF_8_String avec un littéral,
> - est ce qu'on peut le faire pour se simplifier la vie des maintenant, en anticipant la prochaine version du langage, parce qu'il n'y aura que des changements marginaux à faire pour rendre ça du "code propre",
> - ou bien est ce qu'il ne faut surtout pas le faire, parce que c'est "coder salement"

> ?

Puisque le précédent mainteneur de RAPID m'a demandé de respecter majoritairement le GNAT Coding Style, je crois que cette option est à écarter définitivement, même à titre temporaire.



Le 9 sept. 2020 à 11:36, Pascal Pignard a écrit :

> Que penses-tu de la proposition UXString

En fait, je pense que ça m'irais très bien en interne, ça serais surtout une question d'habitude pour ne plus avoir le réflexe d'utiliser String par simplicité.

Mais en fait, ce problème d'encodage je l'ai surtout avec GtkAda. (D'ailleurs il faudrait que je me préoccupe de comment ça se passe avec les autres interfaces ...)
Donc il faudrait que GtkAda accepte d'utiliser ce type là aussi, pour que tout glisse bien.
Sinon, je continuerai de me taper une série de conversions systématiques, aussi bien dans les cas où j'aurai des appels directement à GtkAda avec des littéraux en paramètres, que dans les cas où j'utiliserai UXString d'abord.



Le 1 févr. 2021 à 15:40, Jean-Pierre Rosen a écrit :

> Si je comprends bien ton problème, c'est d'avoir des litéraux déjà encodés en UTF-8. Pour ça, il suffit d'appeler Encode. Si ce sont des messages statiques et que tu as peur que ça coûte cher en temps d'exécution:
> 1) Tu fais un paquetage qui contient tous les messages globaux, ce qui ne peut que faciliter la vie en cas de traduction. Comme ça, les messages sont encodés à l'élaboration

Idée interessante, je la met de coté. :-)
Mais ça n'empêche pas mes remarques pour ceux qui programment "vite", et mal parce que le compilateur ne le leur dit pas.

> 2) Optimiser l'initialisation d'un programme, c'est perdre son temps
> 3) D'autant plus que ces messages transitant par des E/S, le temps d'exécution est tout à fait négligeable

En 1ère approche, ça me parait saugrenu de faire des conversions avec d'autres encodages si le développeur décide au départ qu'il ne va travailler qu'avec UTF-8 d'un bout à l'autre.
Mais c'est un problème d'optimisation,
et je suis d'accord avec toi (je crois) que les problèmes d'optimisation sont secondaires (on peut s'en occuper plus tard).

L'important est :
- la bonne lisibilité du code
- la fiabilité du programme
 -> pas son optimisation.



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

_______________________________________________
Ada-france mailing list
[email protected]
https://mail.ada-france.org/cgi-bin/mailman/listinfo/ada-france