caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: David Chemouil <David.Chemouil@enseeiht.fr>, caml-list@inria.fr
Subject: Re: variables in 'let rec'
Date: Thu, 23 Mar 2000 16:57:36 +0100	[thread overview]
Message-ID: <20000323165736.05662@pauillac.inria.fr> (raw)
In-Reply-To: <38D8953B.80D821F6@enseeiht.fr>; from David Chemouil on Wed, Mar 22, 2000 at 10:41:15AM +0100

> I'm currently writing a program where I need to create both variables
> and functions in a 'let rec'. The problem is that it is not allowed to
> define a simple variable (i.e not a variant) in a 'let rec', because it
> would be able to write things such as:
> 
> # let rec x = x+1;;
> This kind of expression is not allowed as right-hand side of `let rec'
> 
> This error message seems okay to me.
> 
> However, the error message also occurs in situations where there is no
> problem:
> 
> # let rec x = fact 5    (* using usual fact *)
>               ^^^^^^
>   and even = function
>   | 0 -> true
>   | n -> odd (n-1)
>   and odd = function
>   | 1 -> true
>   | n -> even (n-1);;
> This kind of expression is not allowed as right-hand side of `let rec'
> 
> What is "funny" is that it is possible to write 'Some (fact 5)'...

You're correct that the example above could be accepted because "x"
could be computed in advance (fact 5 doesn't depend on the variables of
the recursive equations).  However, this would complicate both the
well-formedness test and the compilation scheme for "let rec".  We
chose to err on the conservative side here.  Notice that your example
can (and should, in the interest of clarity) be written
        let x = fact 5
        let rec even = ... and odd = ...

> Anyway, if this problem is really to complex, or undecidable, or not
> worth the effot, why not allow any variable definition in a 'let rec'
> and print a warning message? Then, the programmer would decide if the
> definition may lead to an error...

We would have no guarantees that the generated code for the "let rec"
is correct, e.g. with the current compilation scheme it could crash
the program.  Better be restrictive here!

- Xavier Leroy



  parent reply	other threads:[~2000-03-24 15:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-22  9:41 David Chemouil
2000-03-23  1:37 ` Max Skaller
2000-03-23 15:57 ` Xavier Leroy [this message]
2000-03-25 14:55 Damien Doligez
2000-03-28  1:03 ` Max Skaller
2000-03-29 11:29   ` Sven LUTHER
2000-03-30  9:52     ` John Max Skaller
2000-03-28 10:01 Damien Doligez
2000-03-30  9:19 ` John Max Skaller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000323165736.05662@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=David.Chemouil@enseeiht.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).