Pollux (./29) :
- Je viens de regarder may_subs_c, déjà il y a un gros problème c'est que le namespace des fonctions et des variables est le même : si je fais un subs sur l'expression digamma+1 ça va planter

Non. Il ne se passera rien. Car digamma est une expression et tu as fourni à subs une fonction de ce nom. Donc il ne fera pas le remplacement.

Pollux (./29) :
- Je pensais plutôt au cas où c'est non pas l'utilisateur final (= programme Basic) qui l'utilise, mais un programme écrit en C appelant MAY directement et définissant des fonctions comme digamma pour son usage interne. Peut-être que tu veux plutôt qu'on définisse une extension dans ce cas-là en fait ?

A mon avis, la meilleure facon d'implanter çà efficacement (une vrai fonction, avec une dérivée, et tout, et tout), est de faire une classe d'extension regroupant toutes tes fonctions.
L'enfant 1 est un entier indiquant le numéro de la fonction (0->digamma, 1 ->besselJ, ...)
L'enfant 2 est l'argument de la fonction.
Tu parses ton expression SANS l'évaluer. Puis tu fais un subs_c avec toutes ces nouvelles fonctions, pour les remplacer par les extensions.
Puis tu fais un éval de ton expression (avec tes extensions).
Avec cette méthode, même si un digamma interne apparait, ton digamma reste prioritaire

Pollux (./29) :
Non non je parle bien de la priorité des opérateurs, ça peut être utile d'avoir une priorité plus faible que + (genre pour un "=" ou un "or"), et aussi intermédiaire entre priorités prédéfinies ^^

Là tu me demande de pouvoir rajouter de nouveaux opérateurs. C'est dans le TODO, mais c'est pas encore supporté
Accordé.

Pollux (./29) :
Je crois que c'est important de faire le parallèle entre put_string() et la fonction qui put() un objet arbitraire ^^

Ok

Pollux (./29) :
L'enrobage c'est très bien, mais à moins que tu veuilles interdire de définir des extensions aux auteurs de programmes de moyen niveau (= l'équivalent des programmes C sous AMS, qui sont quand même assez étroitement couplés au CAS) ça ne te dispensera pas de la compatibilité binaire.

Oui je compte pas tout casser. Donc il y en aura. Mais ca ne sera pas la priorité absolue.

Pollux (./30) :
- Ah oui, mais selon la doc bar ne devient pas entièrement invalide dans le premier cas puisqu'on peut encore l'évaluer ?!?

Oui. C'est la seule chose possible restante.

Pollux (./30) :
- Ce serait possible de formaliser toutes les exigences des extensions pour qu'elles puissent maintenir ce genre d'invariants ? Là ça me paraît très très fragile, c'est à peu près certain que la première extension venue cassera tout si elle a une structure récursive...

Je ne pense pas que ca soit si fragile. En général, une forme _c ne vit pas très longtemps et tu l'évalues très rapidement (parce qu'autrement tu ne peux pas faire grand chose dessus).
De toute façon, si tu as les assertions activées, MAYLIB te lachera une robustesse très vite normalement dans ce cas.
Que verrais-tu dans la doc ?