Re: ergonomie du compilateur

[Claude Marche <Claude.Marche@lri.fr>]

In his message of Wed January 15, 1997, David Monniaux writes:
> -- VERSION FRANCAISE --
> Bonjour à tous,
> je trouve un aspect pénible au compilateur Ocaml, ou d'ailleurs au
> toplevel, c'est son report d'erreur. En effet, il est quelquefois assez
> difficile de retrouver l'origine du problème.
> Si les messages du type "Parse error", bien que peu explicites, ne sont
> toute de même pas trop pénibles quand on a l'habitude (il suffit
> pratiquement de compter les parenthèses!), il n'en est pas de même pour
> les messages d'erreur de typage.
> En effet, souvent une erreur de typage intervient à une ligne donnée non
> pas à cause d'un problème à cette ligne, mais à cause d'un problème à une
> ligne antérieure. S'il est souvent assez facile de retrouver où a été typé
> un terme, cela devient quelquefois difficile, notamment avec les fonctions
> récursives, pour le type de la fonction.
> Ne pourrait-on pas faire que, sur demande, le compilateur, lorsqu'il
> rencontre une erreur de type, ressorte d'où il a inféré les types qui lui
> posent problème?

Une remarque a propos de ce problème qui revient souvent, en
particulier avec les étudiants auxquels on enseigne CAML : il existe
une possibilite que l'on oublie trop souvent, qui est d'ajouter des
contraintes de types. Par exemple on peut ecrire

#let rec fact (n:int) = (if n<= 1 then 1 else n*fact(n-1) : int);;
fact : int -> int = <fun>

Evidemment, et c'est souvent le cas avec CAML, la syntaxe n'est pas
tres pratique (mais peut-etre y a-t-il une meilleure facon de faire ?)
il faut mettre les parentheses obligatoirement...

L'important c'est que ca permet de detecter des erreurs de types a la
definition de la fonction, par exemple :

#let module (x:float) (y:float)  = (x*x + y*y : float);;
Toplevel input:
>let module (x:float) (y:float)  = (x*x + y*y : float);;
>                                   ^
This expression has type float,
but is used with type int.

bon sang mais c'est bien sur, j'ai oublie les points :

#let rec module (x:float) (y:float)  = (x*.x +. y*.y : float);;
module : float -> float -> float = <fun>

Sans les contraintes de types, CAML repond
module : int -> int -> int = <fun>
et l'on ne s'apercoit pas de l'erreur si on fait pas attention.

De facon generale, quand on a une erreur de typage dans une fonction
compliquee, quelles contraintes de type bien placees permettent de
trouver le pb.

> -- ENGLISH VERSION --
> Hello all,
> I find the Ocaml compiler, or the toplevel, sometimes quite tiresome with
> its error reporting. It is sometimes difficult to trace the origin of an
> error.
> While the messages of the "Parse error" kind, if not very explicit, are
> not too bothersome because with some experience one can fix that kind of
> errors quite easily (most often, just count the parenthesises!), this is
> not the case for typing errors.
> A typing problem in a line of code often happens not because this line is
> buggy, but because some previous line is, from which the types of terms in
> the current line have been inferred. Often it's not too difficult to trace
> where those inferences took place, but it's sometimes tedious, especially
> with recursive functions.
> Couldn't the Ocaml compiler be made to have, on request, more verbose
> messages on typing errors, including the trace of inferences of the terms
> to cause problems?

#french_to_english previous_text;;
Toplevel input:
>french_to_english previous_text;;
>^^^^^^^^^^^^^^^^^
The value identifier french_to_english is unbound.

--
| Claude Marché           | mailto:Claude.Marche@lri.fr |
| LRI - Bât. 490          | http://www.lri.fr/~marche/  |
| Université de Paris-Sud | phoneto: +33 01 69 15 64 85  |
| F-91405 ORSAY Cedex     | faxto: +33 01 69 15 65 86    |