Re: Design Patterns and Functional programming
- From: "laynor@xxxxxxxxx" <laynor@xxxxxxxxx>
- Date: Sat, 28 Jul 2007 12:30:26 -0000
ah, I forgot to say, you mark an env as retained when your expression
returns a functional value and you're going to leave that activation,
as in :
let g f x = f x + x in
g (let a = 5 in (function x -> x + a)) 3
in this case, the environment relative to the "let a = 5 in..." will
be marked as retained, because when you exit the activation, you still
need that environment when evaluating (function x -> x + a).
as for determining when you need an environment when exiting an
activation, you do when the expression corresponding to the activation
(here, the let ... thing) evaluates to a function. so (let a=5 in
(function x -> x)) applies as well, the environment will be retained.
On Jul 28, 2:17 pm, "lay...@xxxxxxxxx" <lay...@xxxxxxxxx> wrote:
Hi,
which part of> > if your language doesn't have a heap, you can just check, when exiting
from an activation (e.g., let block or function) looking at the
functional values bound to names in the environment (or still being
used in a "temporary value" memory area, where you hold the
intermediate results of the computation) which one of the retained
envs is not needed anymore, and throw away them.
didn't you understand?
maybe I could be clearer..
let's say you store your functional objects (I'm not talking about
object in the oop sense) as (for simplicity) couples of the like
(f,env), and your activation records contain (a pointer to) the non
local env (static chain).
where f is something representing the function and env represents the
enclosed non local environment. given a retained environment e1, you
can throw it away when exiting from an activation when:
1) it doesn't belong to the dynamic chain of environments (it's not
cyrcular, it's just a stack)
2) you can't find references to the e1 env in the functional objects
stored in the temporary value stacks or bound to a name in other
environments which are in the dynamic chain of envs
3) e1 doesn't belong to the static chain of envs of any functional
object stored in the temporary value stacks or bound to a name in the
dynamic chain of envs.
essentially, you can't throw away the thing in this situation:
envstack:
|S|<- top
|R| S indicates "standard envs"
|R| R indicates "retained envs"
...
|S|
because S could use bindings found in the R environments below it, and
in this situation
|R| <- top (let's call this env e1)
...
|S|
if the environments below R (or the temporary values stacks of the |
S| activations) contain functional objects (f,e') where e'=e1 or e'
belongs to the static chains of f (which you can see following the
static chain of the activation record -again, it's a stack, so nothing
cyclic- of the activations having e' as the enclosed env).
maybe I'm wrong, but this seems to me more like a bunch of linear
searches. no cyclic heaps.
On Jul 28, 11:55 am, Jon Harrop <j...@xxxxxxxxxxxxxxxxx> wrote:
lay...@xxxxxxxxx wrote:
On Jul 18, 9:48 am, Jon Harrop <j...@xxxxxxxxxxxxxxxxx> wrote:
Dmitry A. Kazakov wrote:
Ada is functional, cool.
Ada doesn't support closures. For one thing, closures require a garbage
collector that can handle cyclic heaps.
This seems incorrect to me. A simple functional language doesn't need
a heap (if the language, for example, just handles integer, boolean or
functional values, why whould you need that??). Closures are a matter
of environments, and when the language is statically scoped, of
environment retention.
if your language doesn't have a heap, you can just check, when exiting
from an activation (e.g., let block or function) looking at the
functional values bound to names in the environment (or still being
used in a "temporary value" memory area, where you hold the
intermediate results of the computation) which one of the retained
envs is not needed anymore, and throw away them.
How do you determine which one of the envs is not needed any more?
--
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientistshttp://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
.
- References:
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: laynor@xxxxxxxxx
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: laynor@xxxxxxxxx
- Re: Design Patterns and Functional programming
- Prev by Date: Re: Design Patterns and Functional programming
- Next by Date: Re: Design Patterns and Functional programming
- Previous by thread: Re: Design Patterns and Functional programming
- Next by thread: Re: Design Patterns and Functional programming
- Index(es):
Relevant Pages
|