From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.6.10/8.6.6) with ESMTP id LAA05651; Fri, 6 Sep 1996 11:05:35 +0200
Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id LAA27429; Fri, 6 Sep 1996 11:04:11 +0200 (MET DST)
Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id KAA05175 for caml-redistribution; Fri, 6 Sep 1996 10:56:12 +0200
Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id KAA03239; Fri, 6 Sep 1996 10:17:06 +0200
From: Pierre Weis <Pierre.Weis@inria.fr>
Message-Id: <199609060817.KAA03239@pauillac.inria.fr>
Subject: Re: Pattern Matching
To: e-posse@uniandes.edu.co
Date: Fri, 6 Sep 1996 10:17:06 +0200 (MET DST)
Cc: caml-list@pauillac.inria.fr
In-Reply-To: <322F0B89.553@isis.uniandes.edu.co> from "Ernesto Posse" at Sep 5, 96 12:19:05 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: Pierre.Weis@inria.fr


Hi,

> let assign heap id obj = 
>   List.map
>     ( function 
>         (id,{ vartype = vt; contents = v; 
>               constraints = c; dependencies = d }) -> 
>             (id,{ vartype = vt; contents = obj; 
>                   constraints = c; dependencies = d })
>       | r -> r )    (* 1 *)
>     heap;;
> 
> However the compiler tells me that line marked (* 1 *) is an unused case
> of the match expression. I thought that maybe the problem was that the
> inner id variables (the ones in the function passed to map) are
> identifier patterns therefor they are different from the parameter
> of the assign function.

That's true: variables introduced by patterns are always ``new'' ones,
in the sense that these variables binds new parts of values that are
not related to previous names.

> So I tried to fix it like this:
> 
> let assign heap id obj = 
>   List.map
>     ( function 
>         (name,{ vartype = vt; contents = v; 
>                 constraints = c; dependencies = d }) 
>           when name = id -> 
>             (name,{ vartype = vt; contents = obj; 
>                     constraints = c; dependencies = d })
>       | (name,_) as r when name <> id -> r )
>     heap;;
> 
> And now I get the warning "this pattern-matching is not exhaustive".

Your first pattern is now correct, since you use an explicit equality
test in the ``when'' part of the clause (also called the guard of the
clause). The compiler's warning for the second pattern is also normal,
although it may appear a bit strange at first glance, since your
pattern matching is in fact exhaustive. You may get a better program
by removing the second guarded clause, and using the clause
``| r -> r'' which is equivalent; then, your pattern matching is
properly handled by the compiler that emits no warning no more.

This problem of spurious warnings is that the proof of exhaustivity of
the original guarded pattern matching is far beyond the scope of a
compiler, since it involves to prove that a boolean formula is not
refutable: your pattern matching was exhaustive not only because the
patterns were exhaustive (which is a syntactic condition that can be
checked by the compiler), but also because the boolean conditions of
the when parts were exhaustive, in the sens that the second condition
``name <> id'' were the negation of the first one ``name = id''. This
second part of the proof is much more difficult to tackle, since the
expressions involved in the guards can be arbitrarily complex
expressions e1 and e2, and you get to prove that e1 is equivalent to
(not e2).

Thus, given some guarded clauses
     | pat when condition ->
the compiler performs the ``exhaustive match'' detection as if the
condition can evaluate to false, thus assuming that the guarded clause
is not exhaustive. This is particularly evident if the condition is
reduced to the boolean true:

#function x when true -> 1;;
Toplevel input:
>function x when true -> 1;;
>^^^^^^^^^^^^^^^^^^^^^^^^^
Warning: this matching is not exhaustive.
- : 'a -> int = <fun>
#


Pierre Weis

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