Quelle a été la première langue à autoriser Unicode dans les noms de fonction?
Les gens sont souvent excités à l'idée que JuliaLang prenne en charge les noms de fonction Unicode. Mais ce n'est pas nouveau du tout, c'est juste que la communauté Julia a décidé que c'était parfois approprié, et a construit des outils pour faciliter l'entrée dans Unicode.
Quelle a été la première langue à le permettre? Veuillez sauvegarder la référence de la réponse à une source fiable, par exemple notes de version.
J'ai vu une référence à ce qu'il soit autorisé dans Java 1.5, en 2004, mais je ne l'ai pas trouvé dans les notes de version.
Remarque: je recherche en particulier Unicode. Ainsi, les fichiers de texte riche de Mathematica ou l'utilisation par APL de symboles non ASCII et de codes personnalisés ne comptent pas.
Prise en charge Unicode des années 1990 par Perl dans les noms de fonction
Je ne peux pas dire que Perl était "le premier" langage de programmation à autoriser Unicode dans les noms de fonctions - cela me semble peu probable - mais je peux définitivement documenter quand il a commencé à le faire.
Validation du premier référentiel: 834a4ddd8309fbf6aabbbc51bb6fcbe056e7963f Le 1998-10-23
C'est dans ce commit de 1998 que Larry Wall a corrigé les bugs empêchant l'utilisation des "identifiants UTF-8" en Perl:
commit 834a4ddd8309fbf6aabbbc51bb6fcbe056e7963f
Author: Larry Wall <[email protected]>
Date: Fri Oct 23 18:00:41 1998 +0000
Program with utf8 identifiers fails to compile
Avec le recul, cela a prouvé que cela nous a pris autant de temps, car c'est à notre grande chance que nous avons retenu (certains pourraient dire stupides) pendant des années avant d'ajouter enfin tout support Unicode à la distribution Perl de base jusqu'à ce que - n précédent commit de Larry's en juillet 1998 :
commit a0ed51b321531af4b47cce24205ab9656f043f0f
Author: Larry Wall <[email protected]>
Date: Fri Jul 24 05:44:33 1998 +0000
Here are the long-expected Unicode/UTF-8 modifications.
Notez que c'était quelques années après sortie d'Unicode 2.0 en 1996 . Retarder les chaînes Unicode dans le langage de base nous a permis d'éviter la mer de problèmes qui ont inondé les langues des premiers adoptants qui avaient sauté directement dans les caractères 16 bits d'Unicode 1.0, et que tous ont collé avec cela. En attendant de nous mouiller les pieds dans cette mer antique jusqu'au répertoire de point de code 21 bits "moderne" d'Unicode, nous avons pu utiliser UTF-8 comme représentation interne de toutes nos cordes.
Première version de développement: version 5.005_54 du 1998-11-30
Suivi Versions mineures historiques de Perl vers la fin du dernier millénaire peut être délicat pour les non-initiés en raison des conventions de numérotation des versions particulières qu'il utilisait encore à cette époque pour ses pistes de développement et de maintenance parallèles.
Première version stable/de production: v5.6 le 2000-03-22
Il suffit de dire que la possibilité d'utiliser Unicode dans les noms de fonction est apparue pour la première fois dans la version de développement mineur 5.005_54, qui était destinée à produire la version v5.6 en mars 2000. Les notes de version v5.6 contiennent ce passage :
Prise en charge Unicode et UTF-8
Perl utilise désormais UTF-8 comme représentation interne pour les chaînes de caractères. Les pragmas
utf8Etbytessont utilisés pour contrôler ce support dans la portée lexicale actuelle. Voir perlunicode , tf8 et bytes pour plus d'informations.
À ce moment-là, Unicode lui-même était à sa version v3.0.
Leçons apprises: jetez toujours le premier!
Même si Perl n'a jamais été pris par le piège 16 bits (toujours!) Qui en affecte tant d'autres, son modèle interne initial pour la prise en charge d'Unicode s'est rapidement révélé problématique, nous avons donc réécrit tous ces éléments internes pour la version v5.8 de 2002 -07-18.
Heureusement, cette réécriture interne a affecté très peu d'utilisateurs finaux réels, car elle était limitée à l'API C interne. En ce qui concerne l'utilisation par le programmeur final, la séparation logique cruciale d'un point de code abstrait (un nombre de 21 bits) d'une part et la disposition de mémoire physique sous-jacente cachée inhérente à la représentation UTF-8 de l'autre a été préservée, et ainsi les gens écrivent Les scripts Perl (plutôt que les gens qui mettent à jour le compilateur et l'interpréteur Perl) n'ont presque jamais besoin de penser à autre chose qu'aux caractères abstraits (plus comme les runes de Go), pas aux dispositions de machine en bits et octets.
Retravailler notre modèle de représentation initial a non seulement corrigé une conception défectueuse, mais il a également facilité le rôle dans les mises à jour du consortium Unicode; par Perl v5.8.1 du 25/09/2003, nous avons pris en charge la version 4.0 de la base de données de caractères Unicode, et avons suivi les mises à jour de l'UCD et les nombreuses annexes et rapports techniques étroitement liés (comme TR # 18 sur Unicode Regular) Expressions ) assez étroitement depuis lors.
Hier et aujourd'hui
Et bien sûr, il y a encore diverses choses "Unicode-y" que nous ne faisons pas aussi bien en Perl que possible . Les exemples qui viennent rapidement à l'esprit incluent la normalisation des identifiants des variables et des noms de fonction par le biais de quelque chose comme normalisation NFKC , ou de meilleures garanties sur la façon dont Unicode dans les noms de module est représenté en externe dans le système de fichiers.
Malgré cela, je trouve toujours plus facile d'utiliser Unicode en Perl que dans tout autre langage de programmation de son vénérable millésime. Après tout, ils tous devaient avoir la prise en charge Unicode après la langue a été créée pour la première fois, et c'est toujours son propre cauchemar. De nombreuses tâches liées à Unicode qui sont difficiles dans les langues conçues à l'origine il y a longtemps mais qui, comme Perl et Python sont toujours présentes aujourd'hui, sont parfois plus faciles dans "récent ”Langages conçus avec un support Unicode abstrait intégré dans leur conception depuis le git-go , comme le dit le dicton. Mais c'est un sujet pour un autre jour.
Java a pris en charge unicode dans les identificateurs à partir de sa première version (1996). Voir The Java Language Specification 1.0: http://titanium.cs.berkeley.edu/doc/Java-langspec-1.0/3.doc.html#40625 :
Les lettres et les chiffres peuvent être tirés de l'ensemble du jeu de caractères Unicode, qui prend en charge la plupart des scripts d'écriture utilisés dans le monde aujourd'hui, y compris les grands jeux pour le chinois, le japonais et le coréen. Cela permet aux programmeurs Java d'utiliser des identifiants dans leurs programmes écrits dans leur langue maternelle.
La première spécification fait référence à Unicode 1.1.5. mis à jour ultérieurement en unicode 2.0.
Unicode 1.0 est sorti en 1991, cinq ans avant Java 1.0, il est donc théoriquement possible que d'autres langages soient supportés unicode plus tôt. Je n'en connais pas cependant.