Comment author: administrator

From: Nicolas barnier barnier@recherche.enac.fr

Je suis tombé sur ce rapport de bug ouvert et sans suite :

let f (_ :: l | l) = l;;

val f : 'a list -> 'a list =

f [1;2;3];;

• : int list = [1; 2; 3]

Si c'est trop dur a compiler selon l'intuition, il me semble qu'il
faudrait au moins un warning.

     Jacques

Mais c'est documenté :

6.6 Patterns

``Or'' patterns

[...] If both matchings succeed, it is undefined which set of
bindings is selected.

Ca n'est pas pire que des let ... = ... and ... = ... in ...
pour lesquels l'ordre n'est pas non plus spécifié, non ?

Ce n'est pas du meme ordre qu'on parle: dans un cas il s'agit de
l'ordre des effets de bord, dans l'autre cas de savoir a` quelle
partie d'un motif une variable va etre liee. Difficilement comparable
(dans les deux sens!)

Je crois que Luc est d'accord que ca devra etre arrange' un jour, mais
que ce n'est pas simple a` faire.
Mais est-ce qu'il n'y a pas un progres avec le nouveau warning sur les
motifs partiellement inutilises? Il suffit de noter que le second l
inclus un motif contenant le premier l pour detecter l'ambiguite'.

   Jacques

Compte tenu de ce que je sais de la compilation du PM, je pourrais
mettre un avertissement d'inutilite' dans ce cas tres pre'cis. La regle est extremement simple : si il y a une variable comme
argument d'un or-pat, tous les autres arguments du or-pat sont
inutiles...

Mais je pre'fe`re ne pas la faire afin de me laisser dans la te^te
qu'il faut changer la compilation. Si vous trouvez c,a idiot je met le
warning en cinq minutes.

--Luc

Comment author: administrator

Jacques Garrigue wrote:

Ce n'est pas du meme ordre qu'on parle: dans un cas il s'agit de
l'ordre des effets de bord, dans l'autre cas de savoir a` quelle
partie d'un motif une variable va etre liee. Difficilement comparable
(dans les deux sens!)

En fait, je pensais plus à ce type de construction qui permettrait à
un compilateur idoine de générer du code qui évalue les différentes
branches en parallèle. Mais effectivement, ce n'est pas ce qu'on
recherche avec le pattern matching : heureusement d'ailleurs que
l'ordre est spécifié sur les patterns standards...

Par ailleurs, je vois qu'on peut dérouter l'intuition encore plus :

    Objective Caml version 3.04

let f (_ :: l | l | _ :: _ :: l) = l;;

val f : 'a list -> 'a list =

f [1;2;3];;

• : int list = [1; 2; 3]

C'est le genre de construction qu'on ne fait pas apprendre à nos
élèves...

-- Nicolas

Comment author: administrator

From: Nicolas barnier barnier@recherche.enac.fr

Je suis tombé sur ce rapport de bug ouvert et sans suite :

let f (_ :: l | l) = l;;

val f : 'a list -> 'a list =

f [1;2;3];;

• : int list = [1; 2; 3]

Si c'est trop dur a compiler selon l'intuition, il me semble qu'il
faudrait au moins un warning.

     Jacques

Mais c'est documenté :

6.6 Patterns

``Or'' patterns

[...] If both matchings succeed, it is undefined which set of
bindings is selected.

Ca n'est pas pire que des let ... = ... and ... = ... in ...
pour lesquels l'ordre n'est pas non plus spécifié, non ?

Ce n'est pas du meme ordre qu'on parle: dans un cas il s'agit de
l'ordre des effets de bord, dans l'autre cas de savoir a` quelle
partie d'un motif une variable va etre liee. Difficilement comparable
(dans les deux sens!)

Je crois que Luc est d'accord que ca devra etre arrange' un jour, mais
que ce n'est pas simple a` faire.
Mais est-ce qu'il n'y a pas un progres avec le nouveau warning sur les
motifs partiellement inutilises? Il suffit de noter que le second l
inclus un motif contenant le premier l pour detecter l'ambiguite'.

   Jacques

Comment author: administrator

Apparemment corige' par Luc depuis un certain temps.