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
next prev 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