> 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 > scopes. As the practise shows, although guile documentation says something different. In section 3.1.4.7 (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 level." 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)
