Date: Mon, 9 Mar 1998 18:36:12 +0100
From: Damien Doligez <Damien.Doligez@inria.fr>
Message-Id: <199803091736.SAA29116@tobago.inria.fr>
To: rossberg@ips.cs.tu-bs.de
Subject: Re: Restrictions of let rec
>From: Andreas Rossberg <rossberg@ips.cs.tu-bs.de>
[...]
> let rec f = f' some_defaul_arg
> and f' v = function ... -> ...f' v' x... | ... -> ...f y... | ...
>
>The compiler argues that "this kind of expression is not allowed with
>`let rec'", probably because the RHS of f is neither an abstraction nor
>a constructor application nor does f appear in it.
^^^^^^^^^^^^^^^^^^^^^^^
This last item is irrelevant. The RHS has to be a function
abstration, a constructor, an array, or a record. More precisely,
every RHS of a let rec must be a value and not a variable. <<value>>
is defined as a subclass of expression:
value :
| value-path
| constant
| ( value )
| begin value end
| ( value : typexpr )
| value, value {, value}
| ncconstr value
| value :: value
| [ value {; value} ]
| [| value {; value} |]
| { label = value {; label = value} }
| function pattern-matching
| fun multiple-matching
| let [rec] let-binding {and let-binding} in value
Note that "pattern-matching" and "multiple-matching" in the above are
the real thing, which may contain arbitrary expressions.
>I know it's easy to avoid this by doing eta conversion, but I don't see
>the point in disallowing such definitions. What's the rationale?
In short, we want to avoid run-time errors.
>Maybe
>it's an oversight and the compiler should actually check whether f
>appears on _any_ RHS of the let rec?
I don't understand this remark, since f does appear on the RHS of f'
in your example. Anyway, when f does not appear in any RHS, then its
definition is not really recursive, so you shouldn't include f in the
let rec (unless you're trying to obfuscate your code).
-- Damien
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:14 MET