caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Andrej.Bauer@andrej.com
Cc: Diego Olivier FERNANDEZ PONS <diego.fernandez_pons@etu.upmc.fr>,
	caml-list@inria.fr
Subject: Re: [Caml-list] More problems with memoization
Date: Tue, 03 Oct 2006 10:50:56 +1000	[thread overview]
Message-ID: <1159836656.8435.91.camel@rosella.wigram> (raw)
In-Reply-To: <45219A06.6080909@fmf.uni-lj.si>

On Tue, 2006-10-03 at 01:00 +0200, Andrej Bauer wrote:

> A recursive function _is_ the fixed point of a non-recursive one with an 
> "extra" argument. You may hide this fact if you wish, but I think it's 
> more honest to admit it to yourself. The "untied" version of fib has the 
> advantage that you can do many cool things to it: memoizing is just one 
> possibility.

There is, however, a good reason this is not practical in general:
for a recursion of N entities (either functions or polymorphic
variants in Ocaml can be 'open-recursioned') you need an 
extra N arguments .. and the result is unreadable, as well
as possibly incurring a performance hit.

I wonder if one can add compiler support: for example given

   let rec fib x = match x with
     | 0 -> 0
     | 1 -> 1
     | n -> fib (n - 1) + fib (n - 2)

The compiler silently generates:

   let @fib fib' x = match x with
     | 0 -> 0
     | 1 -> 1
     | n -> fib' (n - 1) + fib' (n - 2)

   let fib = make_rec @fib

and now you have fib as written .. but you ALSO can do:

   let fib = make_mem @fib

to create a memoised version. 

That's for one argument and can clearly be done easily
by the compiler (in fact, camlp4).

However the extension to multiple arguments is not clear. 
Maybe labelled arguments would help, perhaps using
a record.

Andrei said:

"You may hide this fact if you wish, but I think it's 
more honest to admit it to yourself."

but I think this is misleading: there's a good
reason NOT to open the recursions. There's a fundamental
principle of software design: the open/closed principle (OOSC)
which is not obeyed by either the closed or open form.

We need a form that is simultaneously closed and ready to
use but which is also open and amenable to extension.

FYI: the case that most interests me at the moment is neither
type recursion nor functional recursion -- I'm interested
in whether it is possible to design an open-recursive grammar,
this seems to need both recursive data types *and* recursive
functions in open/closed form.

Interestingly in this case I have actually implemented one
already, allowing Felix to extend it's own parser by combining
an Ocamlyacc parser with an executable RD parser .. but
this really isn't the same as systematic static extension
where, for example you write a basic grammar, and then
extensions to it.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


  parent reply	other threads:[~2006-10-03  0:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-30 18:01 Diego Olivier FERNANDEZ PONS
2006-09-30 19:19 ` [Caml-list] " Tom
2006-09-30 19:26   ` Tom
2006-10-01  0:23 ` Jon Harrop
2006-10-01  0:51   ` Martin Jambon
2006-10-02 15:29   ` Diego Olivier FERNANDEZ PONS
2006-10-02 23:00     ` Andrej Bauer
2006-10-02 23:04       ` Andrej Bauer
2006-10-03  0:50       ` skaller [this message]
2006-10-02 23:37     ` Don Syme

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=1159836656.8435.91.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=Andrej.Bauer@andrej.com \
    --cc=caml-list@inria.fr \
    --cc=diego.fernandez_pons@etu.upmc.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).