From: Pierre Weis <Pierre.Weis@inria.fr>
Message-Id: <199611141503.QAA01251@pauillac.inria.fr>
Subject: Re: match values
In-Reply-To: <328A4CA0.D18858A@l-carnot1.ac-dijon.fr> from Quercia at "Nov 13, 96 10:33:04 pm"
To: querciam@l-carnot1.ac-dijon.fr
Date: Thu, 14 Nov 1996 16:03:24 +0100 (MET)
[En francais]
> Le code Caml suivant ne fonctionne pas comme on pourrait le vouloir :
>
> let f(x,y,z) = match x with
> | y -> ...
> | z -> ...
> | _ -> ...
> ;;
[...]
> 1. de modifier la syntaxe de "match" de sorte que les identificateurs
> soient evalues s'ils ne sont pas precedes de "as" comme dans :
>
> match x with
> | y -> ... (* comparaison des valeurs x et y *)
> | _ as t -> ... (* definition de l'identificateur t *)
Je ne comprends pas bien la ligne ``_ as t -> ...''
que vaut t ? que signifie le souligne' ?
La seule re'ponse plausible me semble e^tre
``t vaut x'' et ``_'' ne sert a` rien.
(mais si t est un alias pour x alors pourquoi de'finir t ?)
> 2. d'introduire une nouvelle forme de filtrage "matchval" qui evaluerait
> les motifs avant de proceder a la comparaison, en conservant la
> possibilite
> de definir un nouvel identificateur par "_ as <ident>" ?
Le proble`me est justement dans le terme comparaison: le filtrage
posse`de une se'mantique bien pre'cise lie'e a` la comparaison
structurelle des donne'es, alors que votre proposition introduit un
appel implicite a` des fonctions de comparaison plus se'mantiques. Se
pose alors imme'diatement le proble`me du choix de cette comparaison:
comparaison physique (==) ou e'galite' structurelle re'cursive (=) ou
isomorphisme d'arbres rationnels (equal en Caml V3.1), ou e'galite'
se'mantique adapte'e au type des ``filtres''. Le proble`me de la
pertinence de la comparaison se pose aussi: que faire si le motif
s'e'value en une fonction ? plus ge'ne'ralement en une valeur qui
n'admet pas l'e'galite' (valeur d'un type abstrait par exemple) ?
Il me semble encore une fois que la construction cherche'e est la
construction when, une ge'ne'ralisation du if then else de'ja`
propose'e ici:
Syntaxe:
when
| cond1 -> e1
| cond2 -> e2
...
(| condn -> en) | (| _ -> en)
Se'mantique:
if cond1 then begin e1 end else
if cond2 then begin e2 end else
...
begin en end, dans le cas | _ -> en
if condn then begin en end else (), dans le cas | condn -> en
Ainsi la fonction d'e'galite' est explicite et laisse'e au choix du
programmeur. Votre exemple devient:
let f(x,y,z) =
when
| x = y -> ...
| x = z -> ...
| _ -> ...;;
L'avantage est que maintenant la condition peut e^tre plus ge'ne'rale qu'une
e'galite':
let f(x,y,z) =
when
| x < y -> ...
| x + y >= z -> ...
| _ -> ...;;
Cette construction est simple a` imple'menter (4 lignes dans
l'analyseur syntaxique suffisent) et permet d'e'crire e'le'gamment les
tests complexes. Son seul inconve'nient est d'offrir une alternative
supple'mentaire au if then else. Pour ma part, j'e'changerais
volontier le if then else (avec ses lourdes parenthe`ses begin end en
cas de se'quences) contre le when (et ses e'le'gants symboles | et ->,
re'miniscents du filtrage et moins sensible aux se'quences).
[In english]
> The following Caml code does not work as one would expect :
>
> let f(x,y,z) = match x with
> | y -> ...
> | z -> ...
> | _ -> ...
[...]
> 1. modify "match" syntax so that identifiers are evaluated unless they
> are
> precededed by "as" as in :
>
> match x with
> | y -> ... (* comparison of the values of x and y *)
> | _ as t -> ... (* definition of identifier t *)
I don't understand the last line ``_ as t -> ...'': what means the
underscore and what's the value of t ?
My interpretation: t is a useless alias for x ? ``_'' is useless ?
> 2. introduce a new form of pattern-matching "matchval" which would
> evaluate the patterns before comparison, preserving the possibility
> to define a new identifier with a "_ as <ident>" construct ?
The problem is the ``comparison'': the actual pattern matching feature
has a precise semantics, bound to the structural comparison of
data. Your proposition means introducing implicit calls to more
semantical comparison functions. Thus, we have to choose this implicit
comparison: physical identity (==), recursive structural equality (=),
rational trees isomorphism (equal in Caml V3.1), or even some
semantical equality specialized to the type of ``patterns''. This
problem may not be trivial, if solvable at all, for functions or
abstract data types.
It seems that once more you are looking for the when construct, a
generalised if then else, already proposed here:
Syntax:
when
| cond1 -> e1
| cond2 -> e2
...
(| condn -> en) | (| _ -> en)
Se'mantics:
if cond1 then begin e1 end else
if cond2 then begin e2 end else
...
begin en end, dans le cas | _ -> en
if condn then begin en end else (), in the case | condn -> en
Now the equality test is explicit and written by the programmer:
let f(x,y,z) =
when
| x = y -> ...
| x = z -> ...
| _ -> ...;;
Moreover, the conditions are not restricted to be equality tests:
let f(x,y,z) =
when
| x < y -> ...
| x + y >= z -> ...
| _ -> ...;;
By the way, this construct is simple to implement (4 lines in the
parser) and provides a clear way to write complex tests. Its only
drawback is to be a bit redundant with if. In my opinion, the when
construct is a profitable alternative to if then else: its separator
symbols | and -> are intuitive to the Caml programmer, since they are
reminiscent to those of pattern matching. Moreover, in the presence of
imperative sequences of expressions, the when construct is
syntactically superior.
Pierre Weis
INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis