OVH Cloud OVH Cloud

tail recursivity - recursivite terminale

57 réponses
Avatar
R12y
[ Attention: Xpost + follow-up ]

Bonjour,

A la Fac, on nous enseigne des langages, mais pas Python.
Sur certains de ces langages (Ocaml, mais c'est pas pour troller) faire un
truc "récursif terminal" permet de faire de la récursivité "très
profonde", en repoussant les limites du stack overflow.

J'aime bien ce "truc", moi. La récursivité ça m'a impressionné :-).

Le problème:
Au niveau professionel, OCaml n'est pas très implanté, et d'ailleurs je
suis plutot dans une boite où c'est Python qui règne en maître. Ce
n'est pas un mal, mais je recherche des exemples à difficulté
progressive de cas de recursivité terminale, et je cherche à savoir si
faire de la récursivité terminale sous Python procure (presque) les
mêmes avantages.

Auriez-vous des pistes?

PS: Je programme, c'est tout. Je ne connais pas _exactement_ pourquoi la
récursivité terminale permet ceci ou cela. Cela viendra un jour,
peut-etre, mais pour l'instant j'apprends :-)

--
SPIP, phpNuke, Plone, opengroupware... c'est bien
CPS c'est mieux: http://www.cps-project.org/
Hébergement de sites CPS: http://www.objectis.org/

10 réponses

2 3 4 5 6
Avatar
Yermat
Jacti wrote:
Jacti wrote:
[...]


Un langage qui utilise l'indentation comme forme syntaxique de bloc
ne peut pas être un "bon" langage... (c'est inexprimable en BNF).


Et alors ? BNF n'est pas la panacé non plus... Par contre, cela devrait
être exprimable en PEG ou autre formalisme !
http://en.wikipedia.org/wiki/Parsing_expression_grammar

De plus, pour qui la lecture est le plus important ? le programmeur ou
l'ordinateur ?

--
Yermat


Avatar
Laurent Pointal
Jacti wrote:

On ne peut pas faire un VRAI système d'exploitation sans un mécanisme
de macros (bien que je n'aime pas ça, mais c'est un mal nécessaire...).


Oui, mais on s'en fout. Avec Python ce ne sont pas des OS qu'on écrit,
mais des applis.

A+

Avatar
Laurent Pointal
Jacti wrote:

Un langage qui utilise l'indentation comme forme syntaxique de bloc
ne peut pas être un "bon" langage... (c'est inexprimable en BNF).


Celle là, il faut la coller dans un fortune consacré à Python.

Avatar
Laurent Pointal
Jacti wrote:
D'après ce post
(http://mail.python.org/pipermail/python-dev/2004-July/046150.html)
il ne semble pas que Python dérécursive la récursion terminale.


Non, mais c'est un choix volontaire. Le patch pour ça existe (en tous
cas il eu existé).



Et pourquoi ce choix "volontaire" ?


Peut-être parce que écraser le sommet de la pile à chaque appel récursif
terminal a, en python, des conséquences qui font qu'on préfère éviter.

- on perd la trace des appels - plus dur à déboguer.
- si certains objets perdent leurs dernière référence, il faut les
supprimer et cela peut avoir des effets de bord non désiré.

Donc pas impossible mais pas nécessairement bon.



Avatar
Jerome
Laurent Pointal wrote:
Jacti wrote:


Un langage qui utilise l'indentation comme forme syntaxique de bloc
ne peut pas être un "bon" langage... (c'est inexprimable en BNF).



Celle là, il faut la coller dans un fortune consacré à Python.


Oui, j'aime bien aussi ;-)

De toute façon la notion de bon langage est subjective et n'est
aucunement liée à sa syntaxe. Je connais des gens qui programment comme
des cochons en ADA et des gens qui sont très rigoureux en python...


Avatar
Laurent Pointal
Laurent Pointal wrote:
Jacti wrote:


On ne peut pas faire un VRAI système d'exploitation sans un mécanisme
de macros (bien que je n'aime pas ça, mais c'est un mal nécessaire...).



Oui, mais on s'en fout. Avec Python ce ne sont pas des OS qu'on écrit,
mais des applis.


Quoi que certains s'y essaient :-)

http://unununium.org/
http://sourceforge.net/projects/cleese/

Mais c'est quand même très annecdotique comme usage pour Python.


Avatar
Laurent Pointal
Jerome wrote:
Laurent Pointal wrote:

Jacti wrote:


Un langage qui utilise l'indentation comme forme syntaxique de bloc
ne peut pas être un "bon" langage... (c'est inexprimable en BNF).




Celle là, il faut la coller dans un fortune consacré à Python.



Oui, j'aime bien aussi ;-)

De toute façon la notion de bon langage est subjective et n'est
aucunement liée à sa syntaxe. Je connais des gens qui programment comme
des cochons en ADA et des gens qui sont très rigoureux en python...


ADA.... (soupir)

Bon, ben j'ai commencé un fortune Python.

http://perso.limsi.fr/pointal/python/fortunes-python.html



Avatar
Christophe Cavalaria
Jacti wrote:




Jacti wrote:



[ Attention: Xpost + follow-up ]

(snip)


D'après ce post
(http://mail.python.org/pipermail/python-dev/2004-July/046150.html)
il ne semble pas que Python dérécursive la récursion terminale.


Non, mais c'est un choix volontaire. Le patch pour ça existe (en tous
cas il eu existé).


Et pourquoi ce choix "volontaire" ?


Je l'ai déjà dit dans ce même fil de discution : la dérécursification
terminale a pour effet secondaire de détruire les traceback en cas
d'exception. Forcement puisque le traceback est directement construit à
partir de la pile d'appel. Les concepteurs du langage on préféré favorisé
la facilité de débogage à la vitesse d'execution. Tu remarqueras que la
facilité de lécture/écriture et de débogage sont parmis les points les plus
mis en avant pour la conception du langage.

De toute façon, je considère Python comme un très mauvais langage


Heu... Tu a bien lu le warning en haut du message, et regardé sur quel
ng tu postais ?-)


Oui, et alors ?

(je sais je vais à contre courant de l'avis de beaucoup de gens...)


Oui, particulièrement ici...

mais
j'ai travailler dans les compilateurs et je connais plus de 30 langages
de programmation et, donc,
je sais de quoi je parle...


Au lieu d'affirmer péremptoirement, tu pourrais peut-être argumenter ?


Un langage qui utilise l'indentation comme forme syntaxique de bloc
ne peut pas être un "bon" langage... (c'est inexprimable en BNF).


Je me permet ici un gros "lol" car il n'y a rien de plus à dire sur ce
sujet :)

Pourquoi les informaticiens ont-ils toujours des attirances pour les
plus mauvais langages
(C, C++, Python, Visual Basic, par exemple) ?


Cherchez l'intrus... Si tu place Python et VB dans la même catégorie, je
crains que tu ne saches pas si bien que ça de quoi tu parles...


Bien sûr que VB n'est pas sur le même plan que Python (tout de même !), VB
étant le "Canada Dry" des LOO mais du point de vue qui nous occupe ici,
ils sont aussi "sales" (même si ce n'est pas le même type de saletés).

Sinon, pour répondre à ta question:
http://www.laputan.org/gabriel/worse-is-better.html

Seraient-ils tous d'infâmes
bidouilleurs ?


Oui, bien sûr. C'est évident.

Ou peut-être trouvent-ils juste que l'ambiance sur comp.lang.lisp est
trop saturée de prétention, de suffisance et d'arrogance ?-)

En ce qui me concerne, Python me permet de faire ce que j'ai à faire
simplement et rapidement. Effectivement avec d'infâmes bidouilles, comme
par exemple :
- les fonctions en tant qu'objets de première classe
- les fermetures
- les expressions de liste
- les générateurs
- les descripteurs
- les métaclasses


C'est vraiment la redécouverte de la poudre !


Combien de langages inventent un truc révolutionaire ? Il n'y en a pas
beaucoup. Tout l'art est plutôt de prendre les trucs bien et de les
intégrer tous ensemble de façon cohérente et simple d'utilisation.

Bref, si l'on mets de côté les deux derniers points, d'infâmes
bidouilles très ouvertements inspirées des langages fonctionnels...

Ah, oui, c'est vrai, pas de macros, pas de joli modèle mathématique, une
préférence marquée pour la simplicité et la lisibilité... C'est vrai que
c'est minable, Python, quand on y pense.


Bonjour la simplicité syntaxique de Python !!
On ne peut pas faire un VRAI système d'exploitation sans un mécanisme
de macros (bien que je n'aime pas ça, mais c'est un mal nécessaire...).


Qui a dit que Python servait à faire des systèmes d'exploitation ? Et qui a
dis qu'il fallait un système de macro pour faire un OS de toute façon ?
Tellement d'erreurs en si peu de mots. Celui là aussi mérite une fortune !

Dernière remarque : loin de moi l'idée d'un troll. J'utilise Usenet depuis
1985 et je connais les règles.


Je ne pense pas que la définition de troll d'aujourd'hui soit si différente
de celle de 85. En tout cas rien qui ne change le fait que tu as posté un
gros troll baveux.




Avatar
Bruno Desthuilliers



Jacti wrote:

(snip)




De toute façon, je considère Python comme un très mauvais langage




Tu n'a pas toujours dit ça... Il y a une paire d'année, tu te
retranchais derrière tes années d'expérience comme enseignant pour
affirmer que c'était un mauvais *premier* langage, je cite:

"""
Je ne dis pas que Python est un mauvais langage, c'est un mauvais langage
pour apprendre la programmation, ce qui est différent...
"""

Je te laisse le soin de retrouver le contexte - vu ton expérience, ça ne
devrait pas te poser de problème !-)


Heu... Tu a bien lu le warning en haut du message, et regardé sur quel
ng tu postais ?-)



Oui, et alors ?



Oh, rien...

j'ai travailler dans les compilateurs et je connais plus de 30 langages de
programmation et, donc,
je sais de quoi je parle...


Au lieu d'affirmer péremptoirement, tu pourrais peut-être argumenter ?



Un langage qui utilise l'indentation comme forme syntaxique de bloc
ne peut pas être un "bon" langage... (c'est inexprimable en BNF).


Ce n'est pas la première fois que tu nous la sors, celle-là !-)

Bon, à part que *tu* n'aimes pas ce principe - ce qui es ton droit le
plus strict-, la seule chose que ça prouve est le formalisme BNF est
limité. Je pense que tu connais assez la POO et des langages comme
Smalltalk ou CLOS pour avoir sous la main des idiomes courant dans ces
langages qui sont à peu près inexprimables en UML. Si oui, celà
implique-t'il que Smalltalk et CLOS soient de mauvais langages objets ?-)


Pourquoi les informaticiens ont-ils toujours des attirances pour les plus
mauvais langages
(C, C++, Python, Visual Basic, par exemple) ?


Cherchez l'intrus... Si tu place Python et VB dans la même catégorie, je
crains que tu ne saches pas si bien que ça de quoi tu parles...


Bien sûr que VB n'est pas sur le même plan que Python (tout de même !), VB
étant le "Canada Dry" des LOO


<hs>
Crois-le ou non, mais il y a pire que VB. Si si, c'est possible...
</hs>

mais du point de vue qui nous occupe ici,
ils sont aussi "sales" (même si ce n'est pas le même type de saletés).


Jugement de valeur encore. 30 ans d'expérience ne suffisent pas à faire
passer un jugement de valeur pour une critique argumentée.

(snip)

En ce qui me concerne, Python me permet de faire ce que j'ai à faire
simplement et rapidement. Effectivement avec d'infâmes bidouilles, comme
par exemple :
- les fonctions en tant qu'objets de première classe
- les fermetures
- les expressions de liste
- les générateurs
- les descripteurs
- les métaclasses



C'est vraiment la redécouverte de la poudre !


Non, pas la "redécouverte", juste l'utilisation. PAQJS, il n'y a rien de
nouveau en Python - et je n'ai jamais vu personne le prétendre (en tout
cas personne ayant un minimum de culture dans ce domaine). Là encore, je
te trouve de bien mauvaise foi.


Bref, si l'on mets de côté les deux derniers points, d'infâmes
bidouilles très ouvertements inspirées des langages fonctionnels...

Ah, oui, c'est vrai, pas de macros, pas de joli modèle mathématique, une
préférence marquée pour la simplicité et la lisibilité... C'est vrai que
c'est minable, Python, quand on y pense.



Bonjour la simplicité syntaxique de Python !!


Je n'ai pas parlé de "simplicité syntaxique", mais de simplicité
d'utilisation. Mais si tu veux aller sur ce terrain, je veux bien que tu
me démontre en quoi l'utilisation de *deux* point-virgules à la fin
d'une expression relève de la "simplicité syntaxique" !-)

<ironie>
Quant à la simplicité d'utilisation, il faut bien avouer que les
entrées/sorties en Haskell sont d'une simplicité remarquables
</ironie>

Bref, le purisme, c'est bien beau, mais ça a des limites...

On ne peut pas faire un VRAI système d'exploitation


C'est quoi un "VRAI" système d'exploitation ?-)

sans un mécanisme
de macros


M'en fiche, je ne fais pas d'OS. Ni de contrôle de missiles, d'ailleurs.


Dernière remarque : loin de moi l'idée d'un troll. J'utilise Usenet depuis 1985
et je connais les règles.


Avec tout le respect que j'ai pour ton éminente expérience (non, ce
n'est pas de l'ironie - enfin, à moitié seulement...), je me permets
d'attirer ton attention sur le fait que l'un n'empêche pas l'autre - au
contraire...

Mais bon, on a déjà eu plusieurs fois l'occasion de troller^Mdébattre de
ces sujets, et, hélas, la seule chose que ça m'a appris est que tu a 30
ans d'expérience et que tu sais de quoi tu parles...



Avatar
Jacti

Jacti wrote:
Jacti wrote:
[...]


Un langage qui utilise l'indentation comme forme syntaxique de bloc
ne peut pas être un "bon" langage... (c'est inexprimable en BNF).


Et alors ? BNF n'est pas la panacé non plus... Par contre, cela devrait
être exprimable en PEG ou autre formalisme !
http://en.wikipedia.org/wiki/Parsing_expression_grammar


ah ! ah ! ah !
Je ne sais pas qui a écrit cet article du wikipedia mais alors là, je
rigole franchement tellement il est nul.
Les choses sont présentées de façon si maladroite que ça en est risible.
Exemples choisis :
- "Parsing expression grammars look similar to regular expressions or
context-free
grammars (CFG) in Backus-Naur form (BNF) notation, but have a different
interpretation."
Commentaire : allons-y, mélangeons allègrement les expressions régulières
(en théorie des langages formels
les expressions régulières sont engendrées par des langages de type 3 de
Chomsky appelés encore
langages rationnels ou de Kleene et sont reconnus par des automates à états
finis alors que les
CFG (Context Free Grammar) génèrent des langages de type 2 de Chomsky
encore appelés
Context Free Languages et sont reconnus par des automates à pile). Les
correspondances entre
types de langages et automates de reconnaissance ont été démontrées au
début des années 70
et tout ceci se trouve dans le Volume 1 : Parsing de AHO et ULLMAN intitulé

"The Theory of parsing, translation and compiling de... 1972 ! (aujourd'hui
épuisé).

- Dans les avantages des PEG, on peut lire :
"PEGs make a good replacement for regular expressions, because they are
strictly more powerful.
For example, a regular expression inherently cannot find matched pairs of
parentheses, because it is not recursive, but a PEG can."
Commentaire : Ceci est évident puisque les PEG décrivent des langages de
type 2 alors que les expressions régulières sont de type 3 (donc "moins
puissantes") et que les expressions arithmétiques (donc des langages avec
des paires de parenthèses) sont de type 2.
Tout ceci est connu depuis presque 50 ans !

- Autre morceau choisi :
"Any parsing expression grammar can of course be converted directly into a
recursive descent parser.
Due to the unlimited lookahead capability that the grammar formalism
provides, however,
the resulting parser could exhibit exponential time performance in the
worst case."
qui est à rapprocher de : "PEGs cannot express left-recursive rules"
Commentaire : ben oui, évidemment, chacun sait depuis la nuit des temps
(enfin environ 50 ans) qu'un parser en descente récursive
va boucler sur la récursivité gauche. ce n'est pas une nouveauté.
Et puis des performances en temps exponentiel, bonjour les dégâts !!!
Je rappelle à propos du parsing que des outils aussi éprouvés et aussi
communément utilisés que "lex" et "yacc"
font une analyse ascendante (techniquement du LALR(1)) beaucoup plus propre
qu'une
analyse LL (surtout que les PEG ont un look-ahead infini!) pour pouvoir
localiser les erreurs de syntaxe
(je ne dis pas que tous les parsers LR localisent les erreurs proprement,
après c'est une question de courage
pour exprimer les actions sur les règles...).

En conclusion, je ne vois pas ce que les PEG apportent de nouveau. C'est
même plutôt une régression.
Et encore, je n'ai pas parlé des transformations sur les CFG (forme normale
de Chomsky, forme quadratique, etc.)

De plus, pour qui la lecture est le plus important ? le programmeur ou
l'ordinateur ?


Je répondrai à cette question en disant : par les 2 car on peut toujours
"inventer" des formes syntaxiques
"agréables" pour le programmeur mais quasi inimplémentable par un
algorithme (donc illisible par un ordinateur),
ou peut-être en temps exponentiel ;-)

Jacti



2 3 4 5 6