\DOC frees
\TYPE {Compat.frees : term -> term list}
\SYNOPSIS
Returns a list of the variables which are free in a term.
\DESCRIBE
When applied to a term, {frees} returns a list of the free variables in
that term. There are no repetitions in the list produced even if there
are
multiple free instances of some variables.
\FAILURE
Never fails.
\EXAMPLE
Clearly in the following term, {x} and {y} are free, whereas {z} is
bound:
{
- frees (--`(x=1) /\ (y=2) /\ (!z. z >= 0)`--);
val it = [(--`x`--),(--`y`--)] : term list
}
\COMMENTS
{frees} is not in hol90; the function {free_vars} is used instead.
WARNING: the order of the list returned by {frees} and {free_vars} is
different.
- val tm = (--`x (y:num):bool`--);
val tm = (--`x y`--) : term
- free_vars tm
val it = [(--`y`--),(--`x`--)] : term list
- frees tm;
val it = [(--`x`--),(--`y`--)] : term list
It ought to be the case that the result of a call to {frees} (or
{free_vars})
is treated as a set, that is, the order of the free variables should be
immaterial. This is sometimes not possible; for example the result of
gen_all
(and hence the results of GEN_ALL and new_axiom) necessarily depends on
the
order of the variables returned from {frees}. The problem comes when
users
write code that depends on the order of quantification. For example,
contrary
to some expectations, it is not the case that (tm being a closed term
already)
GEN_ALL (SPEC_ALL tm) = tm
where "=" is interpreted as identity or alpha-convertibility.
\SEEALSO
freesl, free_in, thm_frees.
\ENDDOC