eval + return = fin du monde

[luc2]

#!/usr/bin/perl

use strict;

# bonjour, je pensais empecher la fin du monde en utilisant "return",
# mais j'ai echoue. je comprends a peu pres le pourquoi du comment,
# mais j'ai pas apprecie le piege...

sub fin_du_monde
{
eval
{
return "je quitte la fonction pour eviter la fin du monde\n";
};

return "destruction de l'univers\n";
}

print fin_du_monde;

[Paul Gaborit]

À (at) 14 Sep 2011 13:06:41 GMT,

Post by luc2
#!/usr/bin/perl
use strict;
# bonjour, je pensais empecher la fin du monde en utilisant "return",
# mais j'ai echoue. je comprends a peu pres le pourquoi du comment,
# mais j'ai pas apprecie le piege...
sub fin_du_monde
{
eval
{
return "je quitte la fonction pour eviter la fin du monde\n";
};
return "destruction de l'univers\n";
}
print fin_du_monde;

Ce n'est pas un piège et c'est documenté (dans perlfunc à la section
'eval'). Un 'return' au plus haut niveau du contenu d'un 'eval' (que ce
soit un bloc comme dans votre cas ou une chaîne) définit le résultat du
'eval'.

Le bout de code suivant :

$a = eval {return 42};
print "$a\n";

affichera 42.

[luc2]

si. c'est un piege. ca peut preter a confusion, donc, c'est un piege.

le fait que ce soit documente, explicable ou comprehensible n'empeche pas que
ce soit un piege.

c'est comme les faux-amis entre 2 langues differentes : c'est documente,
explicable et comprehensible, et pourtant, ce sont des pieges.

[Marc Espie]

Post by luc2
si. c'est un piege. ca peut preter a confusion, donc, c'est un piege.
le fait que ce soit documente, explicable ou comprehensible n'empeche pas que
ce soit un piege.
c'est comme les faux-amis entre 2 langues differentes : c'est documente,
explicable et comprehensible, et pourtant, ce sont des pieges.

Bof, bof, bof.

C'est perl, hein. entre last, next, return, eval, die, ca offre pas mal
de possibilites de confusions semantiques (le fonctionnement d'eval/die/$@
est suffisamment complexe pour avoir suscite "quelques" modifications dans les
perl recents, par exemple).

Si c'est un "piege" pour toi, tu n'es pas au bout de tes amusements.

[Paul Gaborit]

À (at) 14 Sep 2011 14:59:34 GMT,

Post by luc2
si. c'est un piege. ca peut preter a confusion, donc, c'est un piege.

Ça ne prête à confusion que pour ceux qui ont des idées préconçues sur
le fonctionnement de 'return' et de 'eval'.

Post by luc2
le fait que ce soit documente, explicable ou comprehensible n'empeche pas que
ce soit un piege.

Vu l'endroit où c'est documenté (à la fois dans 'eval' et dans
'return'), le fait de dire que c'est un piège est en fait un jugement de
valeur (sur celui qui tombe dedans).

Il existe de vrais pièges en Perl (commme dans tous les autres langages)
qui, eux, sont mal ou pas documentés du tout. Par exemple, le piège des
fuites mémoires liées aux références circulaires n'est qu'évoqué dans
perlref avec un renvoi vers perlobj qui l'explique un peu mieux mais ne
fournit pas de solution. Ça, c'est un vrai piège du langage difficile à
comprendre et difficile à résoudre.

[Marc Espie]

Post by Paul Gaborit
Il existe de vrais pièges en Perl (commme dans tous les autres langages)
qui, eux, sont mal ou pas documentés du tout. Par exemple, le piège des
fuites mémoires liées aux références circulaires n'est qu'évoqué dans
perlref avec un renvoi vers perlobj qui l'explique un peu mieux mais ne
fournit pas de solution. Ça, c'est un vrai piège du langage difficile à
comprendre et difficile à résoudre.

Dans le meme genre, le gc n'en sort assez mal avec les variables locales
capturees par des sub anonymes. Par exemple, penser a fermer explicitement
les fichiers dans les lambda, sous peine de se retrouver avec trop de
fichiers ouverts...

[Tower]

Je vous serais reconnaissant de bien vouloir poster un petit bout de
code pour montrer exactement ce à quoi vous faites allusion.

D'avance merci.

Post by Paul Gaborit
Il existe de vrais pièges en Perl (commme dans tous les autres langages)
qui, eux, sont mal ou pas documentés du tout. Par exemple, le piège des
fuites mémoires liées aux références circulaires n'est qu'évoqué dans
perlref avec un renvoi vers perlobj qui l'explique un peu mieux mais ne
fournit pas de solution. Ça, c'est un vrai piège du langage difficile à
comprendre et difficile à résoudre.

[Paul Gaborit]

À (at) Wed, 14 Sep 2011 18:33:16 +0200,

Post by Tower

Post by Paul Gaborit
Il existe de vrais pièges en Perl (commme dans tous les autres langages)
qui, eux, sont mal ou pas documentés du tout. Par exemple, le piège des
fuites mémoires liées aux références circulaires n'est qu'évoqué dans
perlref avec un renvoi vers perlobj qui l'explique un peu mieux mais ne
fournit pas de solution. Ça, c'est un vrai piège du langage difficile à
comprendre et difficile à résoudre.

Je vous serais reconnaissant de bien vouloir poster un petit bout de
code pour montrer exactement ce à quoi vous faites allusion.

Un exemple tout simple :

{
my $pere = {};
$pere->{fils} = {pere => \$pere};
}

Normalement, cette structure de données devraient étre détruite à la fin
du bloc... Mais elle ne l'est pas à cause des références circulaires (le
père référence son fils qui référence son père...). C'est donc une fuite
mémoire.

Le module Devel::Cycle propose la fonction find_cycle pour détecter ce
type de soucis. Pour s'en sortir soit on casse soi-même les références
circulaires avant la fin du bloc (en faisant par exemple 'undef
$pere->{fils}') soit on utilise des références faibles en utilisant la
fonction 'weaken' proposée par le module Scalar::Util. Pour l'exemple
ci-dessus, cela donnerait :

{
my $pere = {};
$pere->{fils} = {pere => \$pere};
weaken($pere->{fils}{pere});
}

[Erwan David]

Post by Paul Gaborit
À (at) Wed, 14 Sep 2011 18:33:16 +0200,

Post by Tower

Post by Paul Gaborit
Il existe de vrais pièges en Perl (commme dans tous les autres langages)
qui, eux, sont mal ou pas documentés du tout. Par exemple, le piège des
fuites mémoires liées aux références circulaires n'est qu'évoqué dans
perlref avec un renvoi vers perlobj qui l'explique un peu mieux mais ne
fournit pas de solution. Ça, c'est un vrai piège du langage difficile à
comprendre et difficile à résoudre.

Je vous serais reconnaissant de bien vouloir poster un petit bout de
code pour montrer exactement ce à quoi vous faites allusion.

{
my $pere = {};
$pere->{fils} = {pere => \$pere};
}
Normalement, cette structure de données devraient étre détruite à la fin
du bloc... Mais elle ne l'est pas à cause des références circulaires (le
père référence son fils qui référence son père...). C'est donc une fuite
mémoire.

tu veux dire que le GC de perl est un simple compteur de références ?
Ça faut quand même des années qu'on sait faire mieux...

[Alain Ketterlin]

Post by Erwan David

Post by Paul Gaborit
{
my $pere = {};
$pere->{fils} = {pere => \$pere};
}
Normalement, cette structure de données devraient étre détruite à la fin
du bloc... Mais elle ne l'est pas à cause des références circulaires (le
père référence son fils qui référence son père...). C'est donc une fuite
mémoire.

tu veux dire que le GC de perl est un simple compteur de références ?
Ça faut quand même des années qu'on sait faire mieux...

Je partage ta stupéfaction, et en allant lire les documents auquel Paul
faisait référence, j'ai bien peur que ce soit le cas...

-- Alain.

[Paul Gaborit]

À (at) Thu, 15 Sep 2011 19:57:08 +0200,

Post by Alain Ketterlin

Post by Erwan David

Post by Paul Gaborit
{
my $pere = {};
$pere->{fils} = {pere => \$pere};
}
Normalement, cette structure de données devraient étre détruite à la fin
du bloc... Mais elle ne l'est pas à cause des références circulaires (le
père référence son fils qui référence son père...). C'est donc une fuite
mémoire.

tu veux dire que le GC de perl est un simple compteur de références ?
Ça faut quand même des années qu'on sait faire mieux...

Je partage ta stupéfaction, et en allant lire les documents auquel Paul
faisait référence, j'ai bien peur que ce soit le cas...

Les créateurs de Lisp disaient : « La gestion de la mémoire est une
chose tellement importante qu'on ne peut pas la laiser au
programmeur. C'est le système qui doit s'en occuper lui-même. »

Les créateurs du C disaient : « La gestion de la mémoire est une
chose tellement importante qu'on ne peut pas la laiser au
système. C'est le programmeur qui doit s'en occuper lui-même. »

Perl utilise effectivement un système de gestion par compteur de
références. C'est un choix parfaitement pragmatique.

Pour la plupart des programmes, c'est le meilleur choix puisqu'ils
n'utilisent pas de références cycliques.

Pour les cas plus complexes, l'utilisation des références faibles ou
d'une destruction programmée suffit.

Seul les cas où il y a des nombreux cycles créés et détruits sans moyen
de prédiction simple de le faiblesse ou non des références peut poser de
réels problèmes et nécessiteraient effectivement un ramasse-miettes plus
« puissants ». Mais la mise en œuvre d'un tel ramasse-miettes est
nécessairement coûteuse et ne vaut pas le coup d'être payé s'il n'est
pas nécessaire.

[Alain Ketterlin]

Post by Paul Gaborit
À (at) Thu, 15 Sep 2011 19:57:08 +0200,

Post by Alain Ketterlin

Post by Erwan David
tu veux dire que le GC de perl est un simple compteur de références ?
Ça faut quand même des années qu'on sait faire mieux...

Je partage ta stupéfaction, et en allant lire les documents auquel Paul
faisait référence, j'ai bien peur que ce soit le cas...

Les créateurs de Lisp disaient : « La gestion de la mémoire est une
chose tellement importante qu'on ne peut pas la laiser au
programmeur. C'est le système qui doit s'en occuper lui-même. »
Les créateurs du C disaient : « La gestion de la mémoire est une
chose tellement importante qu'on ne peut pas la laiser au
système. C'est le programmeur qui doit s'en occuper lui-même. »

Tout à fait d'accord, avec les deux. Mais j'aurais du mal à défendre :
« La gestion de la mémoire est une chose tellement importante que quand
c'est facile on la laisse au système et quand c'est plus compliqué on
demande l'aide du programmeur. »

[...]

Post by Paul Gaborit
Pour la plupart des programmes, c'est le meilleur choix puisqu'ils
n'utilisent pas de références cycliques.

J'aurais dit exactement le contraire, mais je n'ai pas l'intention de
verser dans le débat religieux.

-- Alain.

[Paul Gaborit]

À (at) Fri, 16 Sep 2011 00:09:58 +0200,

Post by Alain Ketterlin

Post by Paul Gaborit
Les créateurs de Lisp disaient : « La gestion de la mémoire est une
chose tellement importante qu'on ne peut pas la laiser au
programmeur. C'est le système qui doit s'en occuper lui-même. »
Les créateurs du C disaient : « La gestion de la mémoire est une
chose tellement importante qu'on ne peut pas la laiser au
système. C'est le programmeur qui doit s'en occuper lui-même. »

« La gestion de la mémoire est une chose tellement importante que quand
c'est facile on la laisse au système et quand c'est plus compliqué on
demande l'aide du programmeur. »

C'est bien la bonne formulation. ;-)

Post by Alain Ketterlin
[...]

Post by Paul Gaborit
Pour la plupart des programmes, c'est le meilleur choix puisqu'ils
n'utilisent pas de références cycliques.

J'aurais dit exactement le contraire,

C'est quoi « exactement le contraire » ?

Que la plupart des programmes nécessitent des références cycliques ? Que
ce n'est pas le meilleur choix lorsqu'il n'y a pas de références
cycliques ? Autre chose ?

Post by Alain Ketterlin
mais je n'ai pas l'intention de verser dans le débat religieux.

Personnellement, ce n'est pas une religion mais juste mon expérience. Il
n'existe pas de ramasse-miettes meilleur que les autres pour toutes les
situations. De tous les langages que j'ai pratiqués (dont C, C++, Java,
Lisp, Prolog, Fortran) pour manipuler des structures de données
complexes, Perl est celui qui, jusqu'à maintenant, m'a posé le moins de
soucis avec la gestion de la mémoire. Mais mon appréciation n'est pas
définitive.

[Alain Ketterlin]

Post by Paul Gaborit

Post by Alain Ketterlin
[...]

Post by Paul Gaborit
Pour la plupart des programmes, c'est le meilleur choix puisqu'ils
n'utilisent pas de références cycliques.

J'aurais dit exactement le contraire,

C'est quoi « exactement le contraire » ?

Selon moi, la plupart des programmes utilisent des références cycliques.
Seuls les plus simples ont un graphe de données parfaitement
arborescent.

Post by Paul Gaborit
[...] Il n'existe pas de ramasse-miettes meilleur que les autres pour
toutes les situations. [...]

Ce n'est pas la question. La question c'est : y a-t-il un ramasse-miette
ou pas ? Pour Perl, la réponse est : "oui mais non".

(Et si la question est de savoir comment implémenter un ramasse-miette,
cela fait longtemps que les solutions mixtes existent : OCaml utilise
des stratégies différentes pour des générations différents, Python fait
du comptage de référence et une collection des données cycliques
au besoin, Java te permet même de changer de gc selon l'application,
etc.)

-- Alain.

[Paul Gaborit]

À (at) Fri, 16 Sep 2011 14:54:22 +0200,

Post by Alain Ketterlin

Post by Paul Gaborit

Post by Alain Ketterlin
[...]

Post by Paul Gaborit
Pour la plupart des programmes, c'est le meilleur choix puisqu'ils
n'utilisent pas de références cycliques.

J'aurais dit exactement le contraire,

C'est quoi « exactement le contraire » ?

Selon moi, la plupart des programmes utilisent des références cycliques.
Seuls les plus simples ont un graphe de données parfaitement
arborescent.

Heu... Sans cycle ne veut pas dire nécessairement arborescent ! Je ne
suis pas certain que les cycles soient si courants que cela. D'autant
moins, si on ne parle que des cycles où le développeur ne peut pas
facilement indiquer quelles sont les références faibles.

Post by Alain Ketterlin

Post by Paul Gaborit
[...] Il n'existe pas de ramasse-miettes meilleur que les autres pour
toutes les situations. [...]

Ce n'est pas la question. La question c'est : y a-t-il un ramasse-miette
ou pas ? Pour Perl, la réponse est : "oui mais non".
(Et si la question est de savoir comment implémenter un ramasse-miette,
cela fait longtemps que les solutions mixtes existent : OCaml utilise
des stratégies différentes pour des générations différents, Python fait
du comptage de référence et une collection des données cycliques
au besoin, Java te permet même de changer de gc selon l'application,
etc.)

Oui, je sais tout ça... Mais toutes ces solutions ont un coût ! Pourquoi
le payer lorsque ce n'est pas nécessaire ?

En fait, ce qui manque à Perl 5, ce sont des ramasses-miettes plus
puissants (mais plus coûteux) qu'on pourrait activer au besoin (dans les
cas où les compteurs de référence couplés aux références faibles ne
suffisent pas ou dans les cas où le developpeur ne veut vraiment pas se
soucier de la gestion mémoire).

C'est sur ce principe que fonctionne Perl 6 (en fait la machine
virtuelle Parot).

[Erwan David]

Post by Paul Gaborit
En fait, ce qui manque à Perl 5, ce sont des ramasses-miettes plus
puissants (mais plus coûteux) qu'on pourrait activer au besoin (dans les
cas où les compteurs de référence couplés aux références faibles ne
suffisent pas ou dans les cas où le developpeur ne veut vraiment pas se
soucier de la gestion mémoire).

Un simple mark & sweep à 3 couleurs c'est pas couteux et ça marche (j'en
ai implémenté un en embarqué avec une mémoire de l'ordre de 64 ko).
Après on peut faire plus fin en le faisant génératif, temps réel ou
concurrent...

[Paul Gaborit]

À (at) Fri, 16 Sep 2011 19:23:24 +0200,

Post by Erwan David

Post by Paul Gaborit
En fait, ce qui manque à Perl 5, ce sont des ramasses-miettes plus
puissants (mais plus coûteux) qu'on pourrait activer au besoin (dans les
cas où les compteurs de référence couplés aux références faibles ne
suffisent pas ou dans les cas où le developpeur ne veut vraiment pas se
soucier de la gestion mémoire).

Un simple mark & sweep à 3 couleurs c'est pas couteux et ça marche (j'en
ai implémenté un en embarqué avec une mémoire de l'ordre de 64 ko).
Après on peut faire plus fin en le faisant génératif, temps réel ou
concurrent...

Un "mark & sweep" ainsi que son amélioration à "3 couleurs" introduisent
des phases de ramassage des miettes qui arrêtent momentanément le
programme (et qui forment le coût supplémentaire que j'évoquais). De
plus, certains objets sont détruits avec retard (alors qu'ils sont hors
de portée depuis longtemps). L'intérêt est évidemment qu'on n'a pas à se
soucier des cycles.

L'intérêt du simple comptage de références (combiné avec des références
faibles ou un cassage manuel des cycles) est de garantir une destruction
des objets au moment où ils deviennent hors de portée et des phases de
destruction dont le coût est exactement lié au nombre d'objets détruits
(le comportement est déterministe). L'inconvénient est évidemment de
créer des fuites mémoire si on oublie de gérer les cycles d'une manière
ou d'une autre.

Le choix pragmatique en Perl 5 a été la deuxième solution pour des
raisons de performances. Il est évidemment discutable (c'est d'ailleurs
ce qu'on fait ;-)). Mais il n'est pas condamnable en tant que tel.

[Marc Espie]

Post by Erwan David

Post by Paul Gaborit
En fait, ce qui manque à Perl 5, ce sont des ramasses-miettes plus
puissants (mais plus coûteux) qu'on pourrait activer au besoin (dans les
cas où les compteurs de référence couplés aux références faibles ne
suffisent pas ou dans les cas où le developpeur ne veut vraiment pas se
soucier de la gestion mémoire).

Un simple mark & sweep à 3 couleurs c'est pas couteux et ça marche (j'en
ai implémenté un en embarqué avec une mémoire de l'ordre de 64 ko).
Après on peut faire plus fin en le faisant génératif, temps réel ou
concurrent...

Erwan, comme souvent... Si c'est si facile a faire que ca, et si tu l'as
deja fait, qu'est-ce que tu attends pour nous filer un patch pour perl5.

Ah oui, j'oubliais, t'es pas paye pour ca.

[Erwan David]

Post by Marc Espie

Post by Erwan David

Post by Paul Gaborit
En fait, ce qui manque à Perl 5, ce sont des ramasses-miettes plus
puissants (mais plus coûteux) qu'on pourrait activer au besoin (dans les
cas où les compteurs de référence couplés aux références faibles ne
suffisent pas ou dans les cas où le developpeur ne veut vraiment pas se
soucier de la gestion mémoire).

Un simple mark & sweep à 3 couleurs c'est pas couteux et ça marche (j'en
ai implémenté un en embarqué avec une mémoire de l'ordre de 64 ko).
Après on peut faire plus fin en le faisant génératif, temps réel ou
concurrent...

Erwan, comme souvent... Si c'est si facile a faire que ca, et si tu l'as
deja fait, qu'est-ce que tu attends pour nous filer un patch pour perl5.

Je l'ai fait il y a longtemps, mais pas pour perl. Ça teva mieux ?

Post by Marc Espie
Ah oui, j'oubliais, t'es pas paye pour ca.

Je ne fais pas que les trucs pour lesquels je suis payé, mais quand jene
suis pas payé je fais d'abord ce qui m'intéresse le plus. Et perl n'est
pas ma tasse de thé.

[Marc Espie]

Post by Erwan David
Je ne fais pas que les trucs pour lesquels je suis payé, mais quand jene
suis pas payé je fais d'abord ce qui m'intéresse le plus. Et perl n'est
pas ma tasse de thé.

Pourquoi lis-tu ce groupe, alors ?

[Erwan David]

Post by Marc Espie

Post by Erwan David
Je ne fais pas que les trucs pour lesquels je suis payé, mais quand jene
suis pas payé je fais d'abord ce qui m'intéresse le plus. Et perl n'est
pas ma tasse de thé.

Pourquoi lis-tu ce groupe, alors ?

Parceque j'ai parfois besoin de faire du perl...
Dereprendre quelque chose écrit en perl, de le modifier, d'y ajouter une
fonction...

Ce qui n'a rien à voir avec se plonger dans la mécanique interne de
l'implémentation de perl.

[Marc Espie]

Post by Erwan David

Post by Marc Espie

Post by Erwan David
Je ne fais pas que les trucs pour lesquels je suis payé, mais quand jene
suis pas payé je fais d'abord ce qui m'intéresse le plus. Et perl n'est
pas ma tasse de thé.

Pourquoi lis-tu ce groupe, alors ?

Parceque j'ai parfois besoin de faire du perl...
Dereprendre quelque chose écrit en perl, de le modifier, d'y ajouter une
fonction...
Ce qui n'a rien à voir avec se plonger dans la mécanique interne de
l'implémentation de perl.

Par contre, sur un truc qui est du logiciel libre, je trouve relativement
discourtois de te moquer de l'implementation alors que tu dis que tu sais
faire mieux et que tu as deja fait mieux... t'as meme pas l'excuse du langage
vu que perl est pour l'essentiel ecrit en C.

[luc2]

Post by Paul Gaborit

Post by luc2
si. c'est un piege. ca peut preter a confusion, donc, c'est un piege.

Ça ne prête à confusion que pour ceux qui ont des idées préconçues sur
le fonctionnement de 'return' et de 'eval'.

une grosse majorite quoi...

Post by Paul Gaborit

Post by luc2
le fait que ce soit documente, explicable ou comprehensible n'empeche pas que
ce soit un piege.

Vu l'endroit où c'est documenté...

mon affirmation tenait deja compte de l'endroit.

Post by Paul Gaborit
...(à la fois dans 'eval' et dans 'return'), le fait de dire que c'est un
piège est en fait un jugement de valeur (sur celui qui tombe dedans).

'pas besoin de determiner s'il s'agit d'un jugement de valeur ou pas, meme sans
jugement de valeur, on peut toujours deformer la verite.

Post by Paul Gaborit
Il existe de vrais pièges en Perl (commme dans tous les autres langages)
qui, eux, sont mal ou pas documentés du tout. Par exemple, le piège des
fuites mémoires liées aux références circulaires n'est qu'évoqué dans
perlref avec un renvoi vers perlobj qui l'explique un peu mieux mais ne
fournit pas de solution. Ça, c'est un vrai piège du langage difficile à
comprendre et difficile à résoudre.

ce n'est pas parce qu'il existe des pieges plus vicieux que celui-ci n'en est
pas un.

[Marc Espie]

Post by luc2

Post by Paul Gaborit
Il existe de vrais pièges en Perl (commme dans tous les autres langages)
qui, eux, sont mal ou pas documentés du tout. Par exemple, le piège des
fuites mémoires liées aux références circulaires n'est qu'évoqué dans
perlref avec un renvoi vers perlobj qui l'explique un peu mieux mais ne
fournit pas de solution. Ça, c'est un vrai piège du langage difficile à
comprendre et difficile à résoudre.

ce n'est pas parce qu'il existe des pieges plus vicieux que celui-ci n'en est
pas un.

ce n'est pas parce que tu insistes que c'est un vrai piege que c'en est un.

[luc2]

Post by Marc Espie

Post by luc2

Post by Paul Gaborit
Il existe de vrais pièges en Perl (commme dans tous les autres langages)
qui, eux, sont mal ou pas documentés du tout. Par exemple, le piège des
fuites mémoires liées aux références circulaires n'est qu'évoqué dans
perlref avec un renvoi vers perlobj qui l'explique un peu mieux mais ne
fournit pas de solution. Ça, c'est un vrai piège du langage difficile à
comprendre et difficile à résoudre.

ce n'est pas parce qu'il existe des pieges plus vicieux que celui-ci n'en est
pas un.

ce n'est pas parce que tu insistes que c'est un vrai piege que c'en est un.

tu cites ma phrase sans la mettre en defaut. au contraire, tu tentes d'utiliser
le meme genre d'argument contre moi, ce qui te fait involontairement valider
mon argument.

[Denis Dordoigne]

Bonjour,

Post by luc2

Post by Paul Gaborit
Ça ne prête à confusion que pour ceux qui ont des idées préconçues sur
le fonctionnement de 'return' et de 'eval'.

une grosse majorite quoi...

A priori la majorité de ceux qui ont appris à utiliser eval l'ont fait en lisant
la doc, et n'ont donc pas d'idées préconçues... D'ailleurs j'ai une question :
comment as-tui découvert eval, et d'après toi à qui ça sert ?

[luc2]

Post by Denis Dordoigne
Bonjour,

Post by luc2

Post by Paul Gaborit
Ça ne prête à confusion que pour ceux qui ont des idées préconçues sur
le fonctionnement de 'return' et de 'eval'.

une grosse majorite quoi...

A priori la majorité de ceux qui ont appris à utiliser eval l'ont fait en lisant
comment as-tui découvert eval, et d'après toi à qui ça sert ?

je pense plutot que la majorite n'a pas appris a utiliser eval. ils
connaissaient deja eval des autres langages, et donc, ne sont pas passes par la
doc. il y a ensuite les gens qui ont connu eval par un ami, et donc, ne sont
pas non plus passes par la doc. viennent ensuite les gens qui ont devine tout
seul que la directive dont ils avaient besoin commencait par un "e" et se
terminait par "val" (avec leur competence de divination 525/525), et qui sont
partis lire la doc sur ce mot. en dernier, il y a ceux qui sont alles lire la
doc en entier, parce qu'en general, on se contente de lire ce dont on a besoin,
et on zappe les autres paragraphes.

oui monsieur, les idees preconcues dominent le monde.

[gerbier]

Post by luc2
#!/usr/bin/perl
use strict;
# bonjour, je pensais empecher la fin du monde en utilisant "return",
# mais j'ai echoue. je comprends a peu pres le pourquoi du comment,
# mais j'ai pas apprecie le piege...
sub fin_du_monde
{
eval
{
return "je quitte la fonction pour eviter la fin du monde\n";
};
return "destruction de l'univers\n";
}
print fin_du_monde;

il suffit de changer peu de choses : un return en die et un test

#!/usr/bin/perl

use strict;

# bonjour, je pensais empecher la fin du monde en utilisant "return",
# mais j'ai echoue. je comprends a peu pres le pourquoi du comment,
# mais j'ai pas apprecie le piege...

sub fin_du_monde
{
eval
{
die "Argh ....\n";
};
if ($@) {
return "je quitte la fonction pour eviter la fin du monde\n";
}

return "destruction de l'univers\n";
}

print fin_du_monde;