caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Neel Krishnaswami <neelk@alum.mit.edu>
To: "Caml-List" <caml-list@inria.fr>
Subject: Re: [Caml-list] [q] on implementing of "memoization"
Date: Sat, 12 Apr 2003 11:54:09 -0400	[thread overview]
Message-ID: <16024.13985.991950.862044@h00045a4799d6.ne.client2.attbi.com> (raw)
In-Reply-To: <000e01c30091$b66bc580$fe00a8c0@hama>


SooHyoung Oh writes:
> 
> In testing "memoization" of fib function, it is OK on
>     let rec fib = ... and memo_fib n = memoize fib n;;
> but it makes the ERROR on
>     let rec fib = ... and memo_fib = memoize fib;;
> 
> The error message is
>       This kind of expression is not allowed as right-hand side of `let rec'
> 
> Why does this error occur? I can't find good description on ocaml
> manual.

The sorts of values you are allowed to use as the right-hand side of
a let rec expression is intentionally restricted, in order to prevent
people from being able to ever use an unitialized variable. If random
ML code were permitted, then you could write forms like this:

  let rec x = x

There's no sensible value x can be bound to! So there is a restriction
that you can only bind the rhs of a let rec to expressions that the
compiler can be sure will not lead to users accessing unitialized
variables. Currently, there are two classes of those, of which only
one is really important.[*] In particular, you can bind them to recursive
functions. Eg,

  let rec fact = fun n -> if n = 0 then 1 else n * fact (n - 1)

Here, we can be sure that fact will be defined before use, because it
is only referenced inside the body of the function, and the compiler
must obviously build the function before it can be called. 

That's why the first version of your code was accepted, and the second
didn't -- you defined a syntactic function expression in the first
version, and not in the second.

[*] The second legal kind of rhs is a constructor application -- eg,
you can write 'let rec ones = 1 :: ones' to get an infinite list of
ones. Kind of neat, but the manual is explicit that this is an
implementation-specific extension, and might go away. 

-- 
Neel Krishnaswami
neelk@alum.mit.edu

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


      parent reply	other threads:[~2003-04-12 15:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-12  1:20 SooHyoung Oh
2003-04-12 14:34 ` Yaron M. Minsky
2003-04-12 15:54 ` Neel Krishnaswami [this message]

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=16024.13985.991950.862044@h00045a4799d6.ne.client2.attbi.com \
    --to=neelk@alum.mit.edu \
    --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).