MAYLIB V0.7.0 - Page 1

I release today the first alpha public version of MAYLIB:

MAYLIB is a C library for symbolic mathematical calculations. It is not a CAS (Computer Algebra System): it doesn't have any internal programming language and it is very limited in functionalities. It doesn't support global variables, neither global functions: this is let to the user of the library. It is released under LGPLv3.

All the information you may want to know should be in the manual : [url]technic/archives/Librairies/Maylib/may.html [/url]
Please report in this topic all the bugs, problems you may found. Currently, it has been successfully built and tested on linux (x86-32, x86-64, and PPC) and windows (32).

The integration with PedroM will come later when tigcc tool chain is ready (Support of the data section for the OS targerts): a tigcc build has been done but is useless. I don't plan to do a TI application which uses this library for PedroM. I hope someone else will do it.

D/L: [url]technic/archives/Librairies/Maylib/may-0.7.0.tar.bz2 [/url]

je sais pas si je l'utiliserai réellement un jour, mais c'est superbe bravo aussi.

Bon, à nous d'en faire un soft mainant

It's up to us to create a useable software for calcs, now

If you have any ideas about functions to write for this library, don't hesitate to ask for them.

before that, we must write a test program integrating existing functions

squalyl (./5) :

It's up to us to create a useable software for calcs, now

Some news?

By the way, some news. I have optimized a little bit MAY. Previous released branch:

MAY V0.7.0 (GMP V4.2.2 MPFR V2.3.1 CC=gcc CFLAGS=-O3 -fomit-frame-pointer -funroll-loops -ffast-math -march=pentium3 -fexceptions -ffunction-sections -fdata-sections)
eval (sum ai*ai*ai) - quite different - N=100......0.03ms
eval (sum ai*ai*ai) -  quite similar  - N=100......0.03ms
eval (sum ai*ai*ai) - quite different - N=1000......0.50ms
eval (sum ai*ai*ai) -  quite similar  - N=1000......0.50ms
eval (sum ai*ai*ai) - quite different - N=10000......1.71ms
eval (sum ai*ai*ai) -  quite similar  - N=10000......2.00ms
eval (sum ai*ai*ai) - quite different - N=100000......72.00ms
eval (sum ai*ai*ai) -  quite similar  - N=100000......64.00ms
eval (sum ai*ai*ai) - quite different - N=1000000......828.00ms
eval (sum ai*ai*ai) -  quite similar  - N=1000000......884.00ms
eval(x+f(x)+f(f(x))+...+f(5000)(x)), subs f to id...1716ms
expand ((a0+...a500)^2), replace a0, reeval...808ms
expand ((x0+...x2+1)^16*(1+(x0+...x2+1)^16))...1268ms
expand ((1+x)^800*(2+x)^800)...456ms
expand ((17+x)^400*(42+x)^400)...256ms
expand ((1+sqrt(5))^65000)...8ms
expand ((1+x+y)^500)...1645ms
divide ( (1+x)^1000+1 , (1-x)^500)...856ms
divide ( (1+x)^1000+1 , x^3-5*x+17)...256ms
divide ( (1+x+y^2)^50+1 , (1-x)^25+y)...1252ms
divide ( (1+x+y^2)^25+1 , x^3*y-5*x*y^42+17*y+1)...1972ms
gcd ( (1+2*x)^200*(x^3+2*x^2+1) , (1+2*x)^42*(x^3-2*x+42) )...100ms
gcd ( (1+2*x)^200*(x^3+2*x^2+1) , (1+2*x)^42*(x^3-2*x+42)+1 )...728ms
gcd ( (1+2*x+y)^100*(x^3+2*x^2*y+1) , (1+2*x+y)^42*(x^3-2*x+42) )...28030ms
gcd ( (x^2-y^2)*(a+b)^10 , (x-y)*(a-c)^10 )...0ms
gcd ( (x-y)^50+a , (x+y)^50 )...0ms
Total time 41202ms

Current branch:

MAY V0.7.1 (GMP V4.2.2 MPFR V2.3.1 CC=gcc CFLAGS=-O3 -fomit-frame-pointer -funroll-loops -ffast-math -march=pentium3 -fexceptions -ffunction-sections -fdata-sections)
eval (sum ai*ai*ai) - quite different - N=100......0.03ms
eval (sum ai*ai*ai) -  quite similar  - N=100......0.03ms
eval (sum ai*ai*ai) - quite different - N=1000......0.38ms
eval (sum ai*ai*ai) -  quite similar  - N=1000......0.36ms
eval (sum ai*ai*ai) - quite different - N=10000......2.29ms
eval (sum ai*ai*ai) -  quite similar  - N=10000......1.71ms
eval (sum ai*ai*ai) - quite different - N=100000......64.00ms
eval (sum ai*ai*ai) -  quite similar  - N=100000......52.00ms
eval (sum ai*ai*ai) - quite different - N=1000000......628.00ms
eval (sum ai*ai*ai) -  quite similar  - N=1000000......836.00ms
eval(x+f(x)+f(f(x))+...+f(5000)(x)), subs f to id...1620ms
expand ((a0+...a500)^2), replace a0, reeval...748ms
expand ((x0+...x2+1)^16*(1+(x0+...x2+1)^16))...864ms
expand ((1+x)^800*(2+x)^800)...424ms
expand ((17+x)^400*(42+x)^400)...256ms
expand ((1+sqrt(5))^65000)...4ms
expand ((1+x+y)^500)...1657ms
divide ( (1+x)^1000+1 , (1-x)^500)...724ms
divide ( (1+x)^1000+1 , x^3-5*x+17)...120ms
divide ( (1+x+y^2)^50+1 , (1-x)^25+y)...932ms
divide ( (1+x+y^2)^25+1 , x^3*y-5*x*y^42+17*y+1)...1352ms
gcd ( (1+2*x)^200*(x^3+2*x^2+1) , (1+2*x)^42*(x^3-2*x+42) )...108ms
gcd ( (1+2*x)^200*(x^3+2*x^2+1) , (1+2*x)^42*(x^3-2*x+42)+1 )...92ms
gcd ( (1+2*x+y)^100*(x^3+2*x^2*y+1) , (1+2*x+y)^42*(x^3-2*x+42) )...2912ms
gcd ( (x^2-y^2)*(a+b)^10 , (x-y)*(a-c)^10 )...0ms
gcd ( (x-y)^50+a , (x+y)^50 )...0ms
Total time 13396ms

Not too much regressions, so I think I have done a good work

Sur TI, tu auras la même chose en heures plutôt que ms.

./9> sorry, I've not so much time. I'm concentrating on another program, hoping it will be released some day.

Sur TI, tu auras la même chose en heures plutôt que ms.

Il y a quelques ordres de grandeur de trop dans ton estimation

Good work

J'ai mis le "" parce que j'exagérais clairement.

En tout cas, pour ce développement très intéressant. Ça pourrait faire enfin un OS libre utilisable pour les TIs. La seule chose qui me préoccupe est que cette grosse usine à gaz à base de GMP+MPFR risque d'être encore plus grosse que le CAS de AMS quand elle aura les mêmes fonctionnalités.

faudrait réimplémenter l'usine à gaz

Kevin Kofler (./14) :

En tout cas, pour ce développement très intéressant. Ça pourrait faire enfin un OS libre utilisable pour les TIs.

Kevin qui me félicite ! Faut que je l'imprime et que je l'encadre ! Vite !

On l'oublie souvent, mais Kevin peut être gentil

c'est juste que quand on l'agace, on le sait, et qu'il tient à ses convictions.

et ici on parlait de MAYLIB ##sifflotte##

Et vous pensez vraiment qu'à fonctionnalités équivalentes pedrom sera plus gros qu'AMS ?

Perso, je n'y vois rien de choquant. C'est normal qu'un CAS soit lourd surtout qu'il n'a pas été prévu d'origine pour calculatrice. Si on peux l'avoir en option(PedromApp), c'est déjà un gros plus.

Sasume (./21) :
Et vous pensez vraiment qu'à fonctionnalités équivalentes pedrom sera plus gros qu'AMS ?

Si quelqu'un veut m'aider dans cette tache, qu'il se présente. Il ne sera pas de trop.

Mais pourquoi "à fonctionnalités équivalentes" ça prendrait plus de place ? Surtout que pedrom est écrit en ASM, et que le compilo utilisé par TI était de moins bonne qualité que gcc.

Parce que les algorithmes utilisés sont au cutting edge de la technologie ? Actuellement pour multiplier deux entiers, on peut utiliser du code FFT si nécessaire

Nouvelle fonction:

[pphd@localhost may]$ ./t-pika "y^3*x+b*y^2+y^2*c^2*x+y^3+b*y*c^2*x+b*y^2*x+b*y*c^2+y^2*c^2" -ofactor
(b+y)*y*(1+x)*(c^2+y)

(Factorisation naive + square free + tous les termes de degré 1 sont factorisés).
D'ailleurs je ne sais pas trop comment l'appeler: may_ratfactor / may_unitfactor / may_unitarizefactor ?
(C'est pas un vrai factor. Il manque Cantor-Zassenhaus mais c'est un bon début)

PpHd (./1) :
I release today the first alpha public version of MAYLIB:

Excellent

Quelques remarques/questions :

This function, contrary to all other, may not copy the expression while changing its form (for efficiency reasons).

"might not" plutôt ? ("may not" ça veut dire qu'elle a pas le droit de copier l'expression)

The value returned is a pointer to the allocated memory, which is suitably aligned for a long, or NULL if the request fails.

L'alignement d'un "long" peut être plus petit que celui d'une structure, je pense que tu veux plutôt "suitably aligned for a struct" (l'alignement de toutes les structures est le même, donc comme une structure peut contenir un long l'alignement est plus grand).

If the node of x is an user defined type, it returns the type name. In both cases, the only way to identify it is to use strcmp.

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 ?

The fact of avoiding any name collision (between function and type) is let to the user.

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 ?

Wild-cards behave like symbols: they are subject to the same transformations. For example, $0+$0 is transformed to 2*$0.

Est-ce que ça veut dire que par exemple si sin(2*x)+y est réécrit en y+sin(2*x) et que sin(2*a)+sin(sin(b)) est réécrit en sin(sin(b))+sin(2*a), alors sin(2*a)+sin(sin(b)) ne sera pas de la forme sin(2*$1)+$2, ou est-ce que le matching prend en compte la commutativité ?

priority : an integer between 1 and 1000. It defines its priority accross all extension class. The priority defines the order of the calls to the overloaded operators if there is more than one extension class as an argument to the operator: it calls the overloaded function which corresponds to the extension class of upper priority if doing inter-class computing is not needed (for example in A^B) or call the overloaded functions in the same order than their priority otherwise. For example, in the expression 2+A1+B1+A2+B2 if the priority of A is lower than B, the overloaded function of A is called before with 2+A1+A2 as an argument. Its returned value is then given as input to the overload function of B. The case whose two or more extension class have the same priority is undefined. 1 is the lowest priority, and 1000 the highest.

Tu ne spécifies pas la priorité des types de base ?

level is the priority level of the current operator (0 for +, 1 for *, 2 for pow, 3 for func) if the priority of the extension is greater, some brackets might be needed to have a proper convertion (default: 3).

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 ?

void convert2str (may_t extension, int level, void (*convert)(may_t ext,int level), void (*put_string)(const char *string));

- Tu ne précises pas si on peut appeler plusieurs fois put_string (j'imagine que oui ?)
- Ce serait pas plus logique d'appeler convert() put_may() ? 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 ?

int non_commutative_product;

Ca me paraît pas très extensible comme 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...

Hold x: mark it as evaluated without performing any simplification. This function may be dangerous, since the other functions expect an evaluated form.

Dangereux à quel point ? Crash ou résultats faux ?



Est-ce que may_eval(may_foo_c(may_bar_c(x,y),z)) est équivalent à may_foo(may_bar(x,y),z) ? (modulo la rapidité si par exemple foo=mul et z=0)

Tiens Pollux se réveille

Pollux (./26) :
"might not" plutôt ? ("may not" ça veut dire qu'elle a pas le droit de copier l'expression)

Corrigé.

Pollux (./26) :
L'alignement d'un "long" peut être plus petit que celui d'une structure, je pense que tu veux plutôt "suitably aligned for a struct" (l'alignement de toutes les structures est le même, donc comme une structure peut contenir un long l'alignement est plus grand).

Faut que je revoie çà donc...

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.

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

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

Pollux (./26) :
(et sinon ça serait peut-être plus clair si tu distinguais tous les cas feuille/noeud et interne/user pour dire ce qui se passe)

Je ne décris pas du tout comment ca marche, parce que l'utilisateur n'a pas à le savoir et parce que ca va encore changer dans pas longtemps en plus.

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
Ou alors tu as implanté ta fonction via une extension (une classe regroupant plein de fonctions supplémentaires serait parfait) et de manière interne, ca ne changerait pas. Ensuite tout dépendrait du parsing et de comment tu amènes ta fonction digamma... Il serait bien que l'on puisse surcharger au moment du parsing les fonctions internes pour retourner des extensions. Mais ca complique le code, et le parseur !
D'un autre coté, je n'ai pas fini de spécifier comme les extensions modifient le parsing. Et pour faire ce que je veux, ce n'est pas simple

Pollux (./26) :
Est-ce que ça veut dire que par exemple si sin(2*x)+y est réécrit en y+sin(2*x) et que sin(2*a)+sin(sin(b)) est réécrit en sin(sin(b))+sin(2*a), alors sin(2*a)+sin(sin(b)) ne sera pas de la forme sin(2*$1)+$2, ou est-ce que le matching prend en compte la commutativité ?

Le matching prend en compte la commutativité. Par exemple, x matche x*$1+$2 aussi
C'est pour çà qu'il interdit d'avoir 'x+$2+$3' comme expression.

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.

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).

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 ?

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

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.

Correction suite à son EDIT furtif.

Pollux (./26) :
Ca me paraît pas très extensible comme 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...

Ok pour le flags ==> Dans le TODO.

Pollux (./26) :
Dangereux à quel point ? Crash ou résultats faux ?

Crash et résultat faux. Il faudrait que je précise les conditions d'utilisation.
Si MAY est compilé avec les assertions, ca ne doit que faire que lever une assertion dans le pire des cas (mais ce n'est pas garanti).

Pollux (./26) :
Est-ce que may_eval(may_foo_c(may_bar_c(x,y),z)) est équivalent à may_foo(may_bar(x,y),z) ? (modulo la rapidité si par exemple foo=mul et z=0)

Oui. Par contre,
may_eval(may_foo_c(bar = may_bar_c(x,y),z))
bar est incorrect (une évaluation invalide toute les références aux éléments non évalués qu'elle parcourt). Alors que :
may_foo(bar = may_bar(x,y),z)
bar est correct.

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.

PpHd (./28) :

Pollux (./26) :
Est-ce que may_eval(may_foo_c(may_bar_c(x,y),z)) est équivalent à may_foo(may_bar(x,y),z) ? (modulo la rapidité si par exemple foo=mul et z=0)

Oui. Par contre,
may_eval(may_foo_c(bar = may_bar_c(x,y),z))
bar est incorrect (une évaluation invalide toute les références aux éléments non évalués qu'elle parcourt). Alors que :
may_foo(bar = may_bar(x,y),z)
bar est correct.

- Ah oui, mais selon la doc bar ne devient pas entièrement invalide dans le premier cas puisqu'on peut encore l'évaluer ?!?
- 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...