From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA16400 for caml-redistribution; Tue, 10 Mar 1998 19:40:11 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA15136 for ; Mon, 9 Mar 1998 18:36:16 +0100 (MET) Received: from tobago.inria.fr (tobago.inria.fr [128.93.8.21]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id SAA09308; Mon, 9 Mar 1998 18:36:13 +0100 (MET) Received: (from doligez@localhost) by tobago.inria.fr (8.6.10/8.6.6) id SAA29116; Mon, 9 Mar 1998 18:36:12 +0100 Date: Mon, 9 Mar 1998 18:36:12 +0100 From: Damien Doligez Message-Id: <199803091736.SAA29116@tobago.inria.fr> To: rossberg@ips.cs.tu-bs.de Subject: Re: Restrictions of let rec Cc: caml-list@inria.fr Sender: weis >From: Andreas Rossberg [...] > 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. <> 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