Skip to the content

Exprimer des appels de fonction imbriqués sans ambiguïté en espéranto

by psychoslave, November 20, 2013

Messages: 20

Language: Français

psychoslave (User's profile) November 22, 2013, 8:44:11 PM

Je continue de chercher une alternative à kaj pour exprimer le fait que le mot suivant est le dernier sujet de la proposition du niveau courant avant de retourner au contexte dont elle est la subordonnée. Je regarde donc les traductions de phrase avec ainsi que

Pour « Il est très intelligent, ainsi que son frère. » on propose :
Li estas tre inteligenta, kiel lia frato.
Li estas tre inteligenta, same kiel lia frato

Est-ce que la première traduction est correct ? Un kiel suffit-il à exprimer « ainsi que » ?

Francestral (User's profile) November 22, 2013, 10:34:41 PM

psychoslave:Je me rends compte qu'en fait je peut utiliser le pronom démonstratif tio et le pronom relatif kio pour manipuler une pile de variables anonymes qui se voient attribuer les résultats des fonctions appelés.
Pourrais-tu donner un exemple ?

psychoslave:Je continue de chercher une alternative à kaj
On pourrait remplacer le "et logique" par kajo. Du coup, ça laisse une place libre pour kaj.

psychoslave:Un kiel suffit-il à exprimer « ainsi que » ?
De quelle manière comptes-tu utiliser kiel en programmation ?

psychoslave (User's profile) November 23, 2013, 6:59:55 PM

Pour l’instant je met ça de côté, car je suis assez satisfait avec la proposition d’utiliser un adverbe en N-ope pour préciser le nombre de paramètre. Plutôt que kajo je verrais plutôt kaju, en tant que fonction/verbe à l’impératif, en tout cas bravo pour l’idée de libérer ainsi le mot kaj. ridulo.gif

Je voyais kiel comme remplaçant potentiel en tant qu’avant dernier mot d'un appel de fonction jouant le même rôle qu’une parenthèse fermante :
sumu(sumu(a,b, c, d),e)
sumu, kio sumu a, b, c kiel d, e

Merci en tout cas pour toutes vos bonnes idées. Je vais mettre tout ceci de côté pour le moment. Comme expliqué je voulais surtout m’assurer que c’est faisable, mais en tant que possibilité optionnelle. Garder une syntaxe plus proche des langages de programmation usuelles comme forme par défaut me paraît plus judicieux. Pour autant je n’oublierais pas vos excellentes suggestions que j’ai fort apprécié. Merci, merci. ridulo.gif

MajorLaFrime (User's profile) November 23, 2013, 7:51:20 PM

sumigigxi est bizarre: igi et igxi sont des fonctions inverses. Un verbe est actif ou passif, pas les deux.
sumigi: Toto sumigas 3 kaj 8
sumigxi: 3 kaj 8 sumigxas de Toto.

Bizarre aussi "sumu!" = soyez une somme, jouez le rôle d'une somme, mettez-vous à la place d'une somme!
(difficile à expliquer en Français)
"sumigu!" = additionnez, faites la somme! (mot à mot "faire somme!")
"sumigi"= additionner. (c'est plus neutre, moins impératif)

L'emploi de "do" (=donc) pour "d", "po" (=chacun) pour "p" est gênant.

Si vous tenez absolument à l'accusatif "d'n" serait plus approprié mais pas très beau.
Mais on peut se passer de l'accusatif.

Si vous restreignez "sumigxi" à deux entrées, vous retrouvez la concision, sinon l'élégance.
On peut même envisager des fonctions non associatives, f[(a,b),c] <> f[a,(b,c)]
inversa pola notacio de Łukasiewicz-Zamenhof!
Monsieur Łukasiewicz s'est trituré la tête pour trouver sa notation polonaise à deux entrées seulement, s'il avait pu trouver un nombre d'entrées variables, il l'eût certainement fait. Ni fidu lin!
::*
c=sum(sum(b,b),b)
en c sumigxas la sumo b kaj b, (petite pause de lecture) kaj b
ou selon votre (bonne) idée
en c sumigxas la sumo b plie b plie b
Mais ce n'est déjà plus du langage humain. Sonnera-ce agréable aux oreilles?
::*
b = sum(c, sum(d, f) )
en b sumigxas c, kaj la sumo d kaj f
::*
b = sum( sum(c, d), f)
en b sumigxas la sumo c kaj d, kaj f
::*
::*
La solution de Sub, est intéressante pour l'élégance:
sumu duope sumu duope a , sumu triope c, d , e , sumu duope f kaj g

mais "duope" du langage Esperanto courant, laisse entendre qu'on double a.
"duterme" serait moins ambigü.

sumigi duterme la sumon duterme a kaj la sumon triterme c, d kaj e , kaj la sumon duterme f kaj g

Algoritmaro.
Je vois le comment, mais je ne vois pas le but.
S'agit-il de remplacer des fonctions au nom anglais en fonctions au nom espéranto? (facile)

"tout exprimer en toute lettre" = ça doit ressembler au langage parlé (poésie)? Ou au parler d'un langage (qui n'existe pas encore)?

psychoslave (User's profile) November 23, 2013, 11:23:58 PM

Bizarre aussi "sumu!" = soyez une somme, jouez le rôle d'une somme, mettez-vous à la place d'une somme!
C’est pourtant bien ce que je souhaite formuler, des objets (sujets) se somment dans un autre (COD). ridulo.gif
Algoritmaro.
Je vois le comment, mais je ne vois pas le but.
Divertissant, éducatif, et peut-être un jour d’utilité public, qui sais. lango.gif

L’objectif « langage en toute lettre » est un projet séparé (bien que lié) avec celui d’avoir des langages de programmation s’appuyant sur l’espéranto plutôt que l’anglais. Il y a plein de points sur lesquels la régularité et la précision grammaticale de l’espéranto me semble pouvoir constituer une aide précieuse à la compréhension et à l’expression d’algorithmes.

Altebrilas (User's profile) November 24, 2013, 9:35:46 AM

Por mi, la plejsimpla solvo estas legi la formulon, uzante mallongigojn por "ekparentezo" kaj "finparentezo":

la solution la plus simple est de lire la formule, en usant d'abréviations pour les parenthèses.

a+ f((b+c)*d,e*x,t*(y-z))
legeblus:
pourrait se lire:
a plus fo ek ek bo plus co fin foje do komo e foje ikso komo to foje ek upsilono minus zo fin fin

Bien entendu, pour les formules non imbriquées comme f(a,b,c), "fo de a, bo, co" suffirait.

psychoslave (User's profile) November 24, 2013, 9:58:13 AM

Merci pour ton idée Altebrilas. Je préfère la solution de Sub avec la conjonction qui précède le dernier mot, c’est cependant toujours intéressant d’avoir le plus d’idée possible.

psychoslave (User's profile) November 26, 2013, 9:51:18 AM

Tiens en utilisant vortaro.net, je découvre que k est utilisé comme diminutif de kaj ! Voilà qui pourrait aider à mettre en œuvre la notation proposée par Sub sans créer de problème avec mon souhait de réserver kaj pour la fonction logique. D’ailleurs cette dernière devrait plutôt être rendu par le verbe « kaji », comme le suggère Francestral : a^b -> a kaju b

(a+(c+d+e))+(f+g)
sumu(sumu(a, sumu(c, d, e) ), sumu(f, g) )
sumu(sumu(a,sumu(c,d,e)),sumu(f,g)) # même notation mais sans espaces logiquement superflu
sumu sumu a k sumu c, d k e k sumu f k g
sumu sumu a kaj sumu c, d kaj e kaj sumu f kaj g

On voie qu’avec l’utilisation de k, on arrive à quelque chose de guère plus long qu’une notation fonctionnelle utilisant les même mots clés, et même à quelque chose de plus court qu’une notation fonctionnel qui rajoute un minimum d’espaces pour aider la lisibilité.

D’ailleurs, on peut très bien envisager des abréviations pour chacune des opérations mathématique de base :
- a de adicio pour l’addition
- d de divido pour la division
- e de eksponento pour l’exponentiel
- k de kaj pour fermer un contexte donc
- o de obligo pour la multiplication
- i de inverso pour l’inverse
- l de logaritmo pour le logarithme
- m de modulo pour le reste de la division
- n de negativo pour le contraire
- r de radiko pour la racine
- s de subtraho pour la soustraction

Mais je ne suis pas franchement emballé par ce genre de notation. lango.gif

Francestral (User's profile) November 26, 2013, 11:52:37 AM

Je ne suis pas sûr qu'utiliser de telles abréviations soit une bonne idée. Cela inciterait à restreindre l'usage de certains noms de variable usuels qui eux aussi ne font qu'une lettre.

Par exemple, i et j sont souvent utilisés pour désigner le nombre complexe de module 1 et d'argument Pi/2.

De plus, i, j et k sont souvent utilisés pour les itérations.
Ex : for(int k = 1; k <= 4; k++) { ... }
Traduction : Pour k entier de 1 à 4, faire { ... }.

psychoslave (User's profile) November 27, 2013, 12:58:12 PM

Je suis d’accord que ce ne serait pas une bonne idée, mais pas pour les mêmes raisons : pour ma part je n’aime pas cette pratique de la mono-lettre, y compris celui de l’usage courant. Je préfère l’utilisation de mots qui ont du sens.

La longueur du mot à peut d’importance à la lecture, il y a de nombreuses études qui montrent qu’on ne lie pas lettre à lettre mais qu’on reconnaît les mots par leur forme global.

Et à l’écrit, avec les IDE modernes il n’y a vraiment aucun argument pour l’utilisation de mots brefs : même LesTrèsLongMotsDesGensQuiFontDesHorreursPareilles demandent peu de saisie à l’appel grâce à la complétion.

Cela étant, je pense qu’il faut savoir trouver un compromis entre la concision et la signification. En espéranto on à plein de mots et d’affixes qui sont aussi signifiant et brefs qu’utiles dans un contexte de programmation :
  • -j, opo, aro, ingo, ujo pour désigner différents types de collections/conteneurs ;
  • ano, ero pour désigner des éléments/membres ;
  • -ulo pour des représentants/instances d’une classe ;
  • post, -id-, antaŭ-, pra- pour désigner des successeurs/prédécesseurs.
por(indukta ano = 1; ano < aro; poste-ano) { ano[aro] … }

L’utilisation d’itérateurs à la python permet de se passer des nombres :
por(ero in listo):
print(ero)

Si c’était pour faire du pur mimétisme des langages existants, je trouverais l’idée d’utiliser l’espéranto comme base pour des langages de programmation beaucoup moins attrayante. Au contraire, il me semble que l’espéranto comporte tout un tas d’idiomatismes qui ont le potentiel de remplacer des notations plus ou moins ésotériques au profane sans nuire à l’expressivité logique non-ambiguë.

Pour l’instant c’est vrai que je suis encore dans une phase de tâtonnement lexicale et syntaxique, cela prend du temps, mais il me semble déjà apercevoir tout un tas de possibilités fort attrayantes.

Back to the top