Re: Irrelevant variables in patterns

Re: Irrelevant variables in patterns

[Damien Doligez]

La solution serait plutot d'avoir une distinction syntaxique entre
variables et constructeurs (par exemple, les constructeurs commencent
par une majuscule et les variables par une minuscule).

Ca resout le meme probleme qui apparait dans les match.

Malheureusement, ce qui precede est un sujet de flame-wars permanent
parmi les implementeurs de Caml, donc on s'est impose un moratoire
sur le sujet (moratoire que je viens de violer...)

Irrelevant variables in patterns

[calla]

   Le probleme est excatement le meme en ADA qui a la meme philosophie des
  exceptions que caml, meme si le mecanisme est plus puissant en Caml.

   Le probleme de fond est le suivant me semble-t-il : on traite syntaxiquement
 et semantiquement  de la meme  facon  des exceptions de nature tres differentes
 quand au  comportement du  programme a l'execution :
 
  1)celles qui sont  definies par le programmeur comme un moyen de programmation
 qui evite des test dans des cas tordus et qui sont bien pratiques
 
  2) celles qui sont generees par le run-time du langage  mais qui sont de meme 
 utilite (du genre Failure "hd" et autres  Invalid_argument ..)
  
  et enfin celles qui viennent du systeme hote dont le plus bel exemple est 
  Out_Of_memory, mais qui peuvent etre moins catatrophiques comme celles
 liees aux entrees-sorties.

   Si on veut ecrire des softs robustes, on ne peut s'interdire de traiter
 ces dernieres, meme  Out_Of_memory, mais la solution serait une hierachisation
 des exceptions dans le langage, avec des constructions differentes pour
 le traitement. Certes ca complique certainement l'ecriture du compilateur,
 et je ne connais pas grand chose aux problemes semantiques poses par les 
 exceptions, mais ca me semble une solution plus serieuse que d'imposer des
 contraintes  de syntaxe un peu arbitraires. 
    Mais sans doute demande-je la lune.
            
            Pierre Calladine.

Irrelevant variables in patterns

[Christophe Raffalli]

> Ce n'est pas un bug lorsqu'on veut faire de la "finalisation":

Cela signifie que l'on doit avoir un warning quand on capture toute les
exceptions et que l'on ne les "reraisent" pas

ex:

        let oc = open_out "foo" in
        try
          ...;
          close_out oc
        with exc ->
          close_out oc;
          sys__remove "foo";
          raise exc

pas de warning ...

        let oc = open_out "foo" in
        try
          ...;
          close_out oc
        with exc ->
          myclose "foo" exc

pas de warning (je ne sais pas vraiment) ? Si l'on ne mets pas de warning dans
ce cas, Chet sera content, car son example n'en produira pas.     

        let oc = open_out "foo" in
        try
          ...;
          close_out oc
        with exc ->
          myclose "foo"

un warning.

        let oc = open_out "foo" in
        try
          ...;
          close_out oc
        with _ ->
          myclose "foo"

une erreur ! (de maniere generale le "_" ne devrait pas etre autoriser pour les
exceptions).

cela devrait attrapper quelques bugs.

Cela serait vraiment bien (pour moi) si la prochaine version de caml-light
pouvait avoir des warnings bien pense de ce type que l'on peut activer par une
option de compilation.

Les deux warnings que je voudrais vraiment pouvoir activier (ce genre de
warning devrait plutot est inactif par defaut ?) sont:

	- variables non utilisees (pattern ou definition de function)
	- capture de toutes les exceptions sans chances de les relever.

Re: Irrelevant variables in patterns

[John Harrison]

Chet writes:

| Exceptions in ML are a programming mechanism.  They are not used
| anymore for exceptional conditions.  We need a new mechanism for that.

In the HOL theorem prover we use exceptions to indicate that certain
inference rules are inapplicable. It's quite common for code to trap
failures at certain subterms and conclude "we have rewritten this subterm
as much as possible, so return it". In the present code (including hol90 in
SML) most of the exceptions are caught completely indiscriminately, i.e.
`_' not `HOL_ERR(_)'. This means there are situations where exceptional
conditions just get driven over. Really the code should be rewritten, but
as Chet remarks, there's something to be said for a separate signal
mechanism.

| Moreover, even if I _do_ write the code in handle_exceptions_generally
| to treat Out_of_memory, etc, I get many warnings telling me that I am
| catching the exception.

Which raises another point. Is there a way to suppress the incredibly
irritating (and I seem to recall not very accurate) "match not exhaustive"
messages in CAML Light (in general expression matching as well as
exceptions)? I find myself putting in redundant clauses to avoid them,
which is hardly good style. It's especially pointless when the match is
actually done at toplevel, e.g.

  let [x;y] = [1;2];;

As Christophe says:

|                               [...] Then what you really needs is a compiler
| option to discard a particular warning (or class or warning) so you only get
| the warnings which are relevant to you programming style.

I agree completely.

John.

Re: Irrelevant variables in patterns

[Judicael Courant]

Oui, mais on peut documenter comme ceci :

map (fun (_(*key*), data) -> data) the_a_list

ou alors on pourrait autoriser (mais dans ce cas, il faudrait modifier
la grammaire) :

map (fun (_key, data) -> data) the_a_list

Je serais cependant plus partisant de la premiere solution...  Et puis,
il est toujours possible de n'avoir le warning qu'en option (pour les
programmeurs qui n'aiment pas documenter leurs programmes).

Judicael Courant.

Re: Irrelevant variables in patterns

[Xavier Leroy]

> De maniere generale, le compilateur ne pourrait-il pas fournir un
> "Warning : irrelevant variable xxx in pattern yyy" lorsque qu'une
> variable liee dans un motif n'est pas utilisee ?

Si, mais ca gene ceux d'entre nous qui aiment documenter leur
programme en nommant les feuilles des motifs, et par exemple preferent
ecrire

        map (fun (key, data) -> data) the_a_list

plutot que

        map (fun (_, data) -> data) the_a_list

Quant a la remarque de Christophe Raffalli:

> La solution serait plutot de fournir un warning lorsque l'on capture toutes
> les exception, car cela est un bug dans 99% des cas (on ne veut pas attraper
> Catch_break ou Out_of_memory en general).

Ce n'est pas un bug lorsqu'on veut faire de la "finalisation":

        try ... with exc -> finalize(); raise exc

C'est meme de l'excellent style. Par exemple:

        let oc = open_out "foo" in
        try
          ...;
          close_out oc
        with exc ->
          close_out oc;
          sys__remove "foo";
          raise exc

- Xavier Leroy

Re: Irrelevant variables in patterns

[Chet Murthy]

>>>>> On Sat, 28 May 1994 12:08:22 -0000, Christophe Raffalli <cr@dcs.ed.ac.uk> said:

> Superfluous warning confuse the programmer, and cause him to
> disregard the warnings completely.  Which can cause him real pain
> when it was a warning that he should have heeded.

	CR> I strongly disagree with this statement. If you get a lot of
	CR> warning, it means you have a particular style of programming
	CR> (for instance catching all exceptions in most of the
	CR> handler). Then what you really needs is a compiler option to
	CR> discard a particular warning (or class or warning) so you only
	CR> get the warnings which are relevant to you programming style.

How about an ML-Lint?  Anybody out there writing one?

--chet--

Irrelevant variables in patterns

[Christophe Raffalli]

> Another simple solution is to disallow variables in case/match/try
> which do not actually occur in the body.  If you really want to have
> such variables around, then put an underscore in front of the name.

I like this one !

Christophe.

Irrelevant variables in patterns

[Christophe Raffalli]

> Superfluous warning confuse the programmer, and cause him to disregard
> the warnings completely.  Which can cause him real pain when it was a
> warning that he should have heeded.

I strongly disagree with this statement. If you get a lot of warning, it means
you have a particular style of programming (for instance catching all
exceptions in most of the handler). Then what you really needs is a compiler
option to discard a particular warning (or class or warning) so you only get
the warnings which are relevant to you programming style.

Christophe.

 

Re: Irrelevant variables in patterns

[Chet Murthy]

>>>>> On Sat, 28 May 1994 12:01:55 -0000, Christophe Raffalli <cr@dcs.ed.ac.uk> said:

	CR> I understand your "point de vue". But then to catch the
	CR> mispelling of an exception, the only solution I can see is a
	CR> different syntax for constructors and variables at least in
	CR> pattern (a quote in front of the constructeur in pattern
	CR> only).

Yes - Daniel de Rauglaudre suggests (and I agree) that we capitalize
constructors, and not capitalize variables.

Another simple solution is to disallow variables in case/match/try
which do not actually occur in the body.  If you really want to have
such variables around, then put an underscore in front of the name.

--chet--

Irrelevant variables in patterns

[Christophe Raffalli]

I understand your "point de vue". But then to catch the mispelling of an
exception, the only solution I can see is a different syntax for constructors
and variables at least in pattern (a quote in front of the constructeur in
pattern only).

I think this is important to find a solution to the mispelling problem,
because it's a common bug which is sometimes tricky to discover.

Christophe.

Re: Irrelevant variables in patterns

[Chet Murthy]

>>>>> On Sat, 28 May 1994 11:36:02 -0000, Christophe Raffalli <cr@dcs.ed.ac.uk> said:

>>>La solution serait plutot de fournir un warning lorsque l'on
>>>capture toutes les exception, car cela est un bug dans 99% des cas
>>>(on ne veut pas attraper Catch_break ou Out_of_memory en general).

>But that doesn't work if I have 10 different exceptions in my program
>- I am unwilling to write 10-way branches, as are most programmers.

>Exceptions in ML are a programming mechanism.  They are not used
>anymore for exceptional conditions.  We need a new mechanism for
>that.

	CR> Ok, but as long as "Out_of_memory" and "catch_break" are
	CR> exceptions, if you don't write the ten cases, this is likely
	CR> to be a bug !!

Actually, that's not the case.  Often, I write:

try blablab with (E1(x,y,z)) -> code1
               | (E2(x,y,z)) -> code2
               | e -> handle_exceptions_generally e
;;

Now, that code ought to be written without consideration for things
like Out_of_memory.  Its like writing code in C to do signals.  If you
don't _explicitly_ mess with SIGSEGV, you can't screw yourself.

Moreover, even if I _do_ write the code in handle_exceptions_generally
to treat Out_of_memory, etc, I get many warnings telling me that I am
catching the exception.

The fact that there isn't a separation of exceptions into classes
really limits their usefulness.  At least, we need two classes -
"signals" and "exceptions".  "signals" would be thing which you have
to register global handlers for.

	CR> Furthermore, I just asked for a warning ! this would catch the
	CR> attention of the programmer on a likely bug. but if he knowns
	CR> what he is doing, he is free to do so.

Superfluous warning confuse the programmer, and cause him to disregard
the warnings completely.  Which can cause him real pain when it was a
warning that he should have heeded.

--chet--

Irrelevant variables in patterns

[Christophe Raffalli]

>>>La solution serait plutot de fournir un warning lorsque l'on capture toutes
>>>les exception, car cela est un bug dans 99% des cas (on ne veut pas attraper
>>>Catch_break ou Out_of_memory en general).

>But that doesn't work if I have 10 different exceptions in my program
>- I am unwilling to write 10-way branches, as are most programmers.

>Exceptions in ML are a programming mechanism.  They are not used
>anymore for exceptional conditions.  We need a new mechanism for that.

>--chet--

Ok, but as long as "Out_of_memory" and "catch_break" are exceptions, if you
don't write the ten cases, this is likely to be a bug !!

Moreover, if you need to catch an exception, it means you want to do something
with it, which is in general specific to this exception. So you have to write
all the branches in most cases (the syntax "A | B | C ->" is then very
usefull).

Furthermore, I just asked for a warning ! this would catch the attention of
the programmer on a likely bug. but if he knowns what he is doing, he is free
to do so.

Christophe.

Re: Irrelevant variables in patterns

[Chet Murthy]

>>La solution serait plutot de fournir un warning lorsque l'on capture toutes
>>les exception, car cela est un bug dans 99% des cas (on ne veut pas attraper
>>Catch_break ou Out_of_memory en general).

But that doesn't work if I have 10 different exceptions in my program
- I am unwilling to write 10-way branches, as are most programmers.

Exceptions in ML are a programming mechanism.  They are not used
anymore for exceptional conditions.  We need a new mechanism for that.

--chet--

Irrelevant variables in patterns

[Christophe Raffalli]

La solution serait plutot de fournir un warning lorsque l'on capture toutes
les exception, car cela est un bug dans 99% des cas (on ne veut pas attraper
Catch_break ou Out_of_memory en general).

Christophe.

Irrelevant variables in patterns

[Judicael Courant]

Bonjour,

j'ai perdu un (gros) bout de temps sur le (stupide) bug suivant :

j'avais ecrit :

try (f x) with NotFound -> raise toto

au lieu de :

try (f x) with Not_found -> raise toto

Resultat : lorsqu'une exception etait levee dans l'evaluation de (f x),
elle etait toujours rattrappee. Pourtant, si j'avais voulu rattrapper toutes les exceptions, il aurait ete beaucoup plus naturel
d'ecrire :

try (f x) with _ -> raise toto

De maniere generale, le compilateur ne pourrait-il pas fournir un "Warning : irrelevant variable xxx in pattern yyy" lorsque qu'une variable liee dans un motif n'est pas utilisee ?

Judicael Courant.