[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sun, 13 Jul 2008 08:57:20 +0200
> Hi Maciek,
> Just picking up another point from your original email. You may have
> already worked this out, but just in case...
OK, it's always good to say to much than not to say enough
(at least if it comes to hacking ;])
>> Additionaly, it would be nice to see the possibility
>> of explicit definitions of environments, like:
>> (define env (make-closure (a . 1)(b . 2))
>> (with env (define c 3))
> This is equivalent to:
> (define env (let ((a 1) (b 2)) (the-environment)))
> (local-eval '(define c 3) env)
> except that the last line fails with a "Bad define placement" error.
> That's because there are special rules for defines inside lexical
As the practise shows, although guile documentation says something
different. In section 220.127.116.11 (A Shared Persistent Variable)
"An important detail here is that the `get-balance' and `deposit'
variables must be set up by `define'ing them at top level and then
`set!'ing their values inside the `let' body. Using `define' within
the `let' body would not work: this would create variable bindings
within the local `let' environment that would not be accessible at top
So one might conclude that it _is_ possible to use define inside
a 'let' form.
>> so that we could define the aforementioned
>> counter as:
>> (define counter-env (make-closure (c . 0)))
>> (define ++ (with counter-env (lambda()(set! c (1+ c))c)))
> This one really works:
> (define counter-env (let ((c 0)) (the-environment)))
> (define (++) (local-eval '(begin (set! c (+ c 1)) c) counter-env))
> So, in summary, make-closure wouldn't provide anything more than what
> we already have.
Yes, since there's local-eval and the-environment, everything I've
ever dreamed of is possible :)
But as I've concluded from the discourse, neither of these is
defined in R5RS (and it makes me wonder)