Comment author: administrator

Salut Judicaël,

Pourquoi tant de haine envers cette merveilleuse fonction printf :-)
En bref:

• Non, je ne vois aucun moyen de changer son comportement vis-à-vis
  de l'application partielle.
• Oui, il faudra documenter cela dans le manuel.

Amicalement,

• Xavier

Comment author: administrator

Added documentation (Xavier, 2001-02-12)

Comment author: administrator

Full_Name: Judicaël Courant
Version: 3.00+8 et antérieures
OS: Linux
Submission from: ext2.lri.fr (129.175.15.5)

A propos de la question de l'utilisation de printf et de l'application
partielle
soulevée par Charles Martin
(http://caml.inria.fr/archives/200101/msg00036.html),
quelques arguments en réaction à la réponse de Pierre Weis et une suggestion
constructive.

• la réponse de Pierre est que c'est une fonctionnalité. Certes,
  c'est une fonctionnalité de l'implantation actuelle. Mais rien dans
  la doc ne laisse supposer que ça fonctionne comme ça. Au contraire,
  il me semble assez naturel d'attendre d'une fonction qu'un coup
  d'eta-expansion ne modifie pas son comportement (*).

C'est très naturel, mais malheureusement c'est une erreur de
s'attendre à cela. Cette propriété n'a jamais été vraie en Caml (et
même avant en ML). C'est bien sûr une erreur classique des débutants
que de croire qu'un programme dont le type est fonctionnel n'est pas
sensible à l'éta-conversion. C'est regrettable, et c'est la raison
pour laquelle il faut en parler assez tôt aux étudiants !

Printf met en évidence ce problème de façon accrue, c'est tout. (Et tu
as raison, c'est aussi dû à son implémentation, mais une autre
implémentation qui induirait un effet retard pour obtenir le
comportement qui te semble naturel, serait pour moi tout aussi
bizarre!)

A l'inverse, j'ai du mal à concevoir un emploi de cette fonctionnalité qui ne
soit pas immonde.

Tout à fait d'accord, mais le moyen de l'empêcher ?

• je conçois qu'il soit difficile d'implanter printf autrement qu'avec ce
  comportement (encore qu'il me semble que quelqu'un avait proposé dans le passé
  une solution sans Obj.magic et que la dite solution n'avait peut-être pas ce
  problème (? sans garantie) et même s'il y en a une c'est du boulot.

Je ne connais personnellement aucune solution aussi générale que
l'actuel printf et qui ait une syntaxe si simple.

• je sais bien que, la doc de printf ne disant rien à propos de
  l'application partielle, on n'est pas censé croire qu'elle a le
  comportement qu'on voudrait. Cela dit ce comportement est très
  naturel.

Suggestion : pourquoi ne pas ajouter dans la doc du module printf
(et pas seulement dans la FAQ) un avertissement disant que le
comportement d'un "printf" partiellement appliqué est non spécifié ?
Cela éviterait à ceux qui n'ont pas le code de printf en tête de se
tromper et laisserait la porte ouverte pour changer peut-être un
jour l'implantation.

Tu as raison bien sûr.

Amicalement,

Judicaël.

(*) Taquinerie : lorsque les variables de type non généralisables
ont été introduites en Caml, il me semble que je m'était étonné (à
Pierre ?) que le truc proposé pour permettre à Caml de généraliser
(l'eta expansion) risquait de changer la sémantique de certaines
fonctions ; il me semble qu'on m'avait répondu alors que ce genre de
fonctions ne devraient pas exister dans des codes bien écrits, donc
a bon entendeur, salut ! :-)

Encore une fois ce n'est pas nouveau: l'eta expansion change la
sémantique de certaines fonctions. On n'y peut rien, et c'est un fait
indépendant du problème de la généralisation des variables de
type. Cependant, dans la vaste majorité des cas, l'eta-expansion
(cette eta-expansion nécessaire à la généralisation) ne gêne pas: elle
ajoute au contraire à la lisibilité et aide souvent les compilateurs à
produire du meilleur code...

PS : Il me semble qu'une des forces de Caml est d'avoir su faire des
choix qui ne soient pas guidés par la facilité ni par ce qui existe
déjà mais au contraire guidés par le désir d'avoir un beau
langage. Le pari est à mon avis largement réussi mais s'il y a moyen
d'avoir la cerise sur le gâteau...

Je ne suis pas sûr que la sémantique actuelle de printf soit
incohérente. Elle est discutable, comme d'ailleurs le typage magique
des formats (peut-être plus encore, puisqu'il implique que le typage
est actuellement dépendant du parcours de l'arbre de syntaxe
implémenté par le code actuel du contrôleur de types!)

PPS : pour ceux qui se poseraient encore la question, je viens de
perdre une heure avec ce problème et en aurait certainement perdu
plus si je ne m'étais pas vaguement rappelé que quelqu'un avait posé
une question à ce sujet quelques temps avant (le "%a" compris par
printf est d'ailleurs une invitation à la faute : c'est tellement
joli de faire List.iter (fprintf c "%a\n" printf_term) term_list)...

Euh, ton exemple est justement un cas où ça marche parfaitement!
Mais tu as raison: on aurait envie d'avoir un Warning à tout le moins ...

Cordialement,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/