PpHd (./27) :
Tiens Pollux se réveille

(faut dire que ce forum est pas dans ma sélection )

Pollux (./26) :
Je comprends pas : pourquoi on peut pas comparer bêtement les pointeurs comme avec les fonctions internes ? Tu prends le nom d'un type d'extension dans un champ et pas en appelant une méthode, donc a priori il ne bouge pas ?

Pour les extensions, ca doit marcher. Reste à savoir si je veux le documenter.

Ben un strcmp() c'est super lent...

Pollux (./26) :
Et c'est quoi une user function ?

f(x), g(x), ...

Oui j'ai fait un edit furtif quand j'ai vu où c'était (en cherchant "user function" j'avais rien trouvé )

Pollux (./26) :
Ca pose un problème d'évolutivité, qu'est-ce qui se passe si je définis une fonction digamma et qu'elle est implémentée dans une version future de maylib ? Ca veut dire qu'il faut que je préfixe toutes mes fonctions pour éviter les collisions ? Ou alors que la liste des fonctions de maylib est figée ?

Oui, il y aura conflit. Mais c'est pas trop grave, car ca fait partie des incompatibilités inévitables entre version majeure.
Sinon ta fonction digamme, tu vas l'implanter via une user function (Forme non évaluée). Tu l'évalues en faisant un remplacement à l'aide d'un gros dictionnaire (qui contient toutes les variables globales, les fonctions que l'utilisateur à fait, ..) que tu appliqueras via may_subs.
Or may_subs supporte les fonctions internes. Donc ce qui se passera est que lors de la nouvelle version (majeure), digamma sera simplifiée par MAY, puis s'il reste sous forme non évaluée, ton propre évaluateur sera appelé. Ce qui fera beaucoup de dégat

- 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
- 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 ?

Pollux (./26) :
Tu ne spécifies pas la priorité des types de base ?

Un type de base est pris en compte de suite (priorité 0). Faudrait peut être le préciser plus dans la doc.

Ah oui quand on voit le prototype de add() ça devient évident ^^

Pollux (./26) :
Ce serait pas plus intéressant de mettre genre 100/200/300/400, pour qu'on puisse définir des extensions de priorité intermédiaire ? Et tu n'as pas une priorité encore supérieure pour les opérateurs unaires ?

Tu confonds la priorité des opérateurs et la priorité des extensions, qui sont 2 priorité différentes (La priorité des extensions n'intervient pas dans le parsing, et inversement).

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 ^^

Pollux (./26) :
- Tu ne précises pas si on peut appeler plusieurs fois put_string (j'imagine que oui ?)

Oui. Faut-il vraiment le précisier ?

Ben c'est pas super clair, même si on s'en doute bien.

Pollux (./26) :
- Ce serait pas plus logique d'appeler convert() put_may() ? Y a pas besoin de passer put_string pour que ça soit réentrant ? Et pourquoi "ext" s'appelle comme ça, il peut avoir un type quelconque et pas seulement un type de l'extension ? Ou alors j'ai rien compris ?

1. Je ne pense pas. Mais je suis ouvert.
2. Non. En fait put_string est une fonction interne que je ne veux pas exporter directement, mais qui est nécessaire.
3. Type quelconque. Ca n'aurait pas beaucoup de sens de faire un put_string de l'extension, car on partirait en boucle infini

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

Pollux (./26) :
mme façon de savoir si la classe vérifie un prédicat, ça veut dire que c'est impossible de linker ensemble deux modules qui ont été compilés avec des versions différentes de maylib (alors que si tu veux t'en servir comme CAS sur calculatrice la compatibilité binaire est super importante). Pourquoi pas utiliser à la place un champ avec des flags genre ASSERT_COMMUTATIVE_PRODUCT ? Comme ça tu pourras en rajouter d'autres quand t'en auras besoin...

MAYLIB est une librairie de bas niveau. Il me parait impensable de linker deux modules linkées avec des versions différentes de may et d'espérer que ca marche.
Mais si tu penses que c'est nécessaire, je peux ajouter un check pour rejeter toute tentative d'enregistrement si la version de lib est différente entre le .h et le .a.

PS: N'oublies pas que MAYLIB est une bibliothèque. Il reste à faire le langage, les fonctions de haut niveau, l'enrobage, et toute l'interface utilisateur.

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.