Mark H Weaver m...@netris.org writes:
Ideally I'd like to allow the user to specify a precise list of
variables to capture, and perhaps the other two variants should be
implemented in terms of this one.
If you have to specify a precise _list_ of variables, the-environment is
pretty pointless
On Sun 18 Dec 2011 08:11, Mark H Weaver m...@netris.org writes:
So, it turns out that the best place to transform (the-environment) into
standard scheme code is in the macro expander itself.
Are you certain that it is desirable to transform it into standard
Scheme code?
The statement that
Hello,
Indeed, only the macro expander has enough information to generate an
optimal list of reachable lexicals, i.e. lexical variables that are
accessible using normal symbols (as opposed to syntax objects) [more
on this below].
Are you certain that you want to restrict the set of
Let me first state that this thread is arguing at a depth where the only
contributions that remain for me to make are syllogisms without an
actual knowledge of what I am talking about.
In order not to appear ungrateful, I will do that, but there will be
little point in expecting me to be of
Hello,
If I understand correctly, Mark wants to restrict the set of variables
you can access to those you could access through normal Scheme code.
This is an issue because psyntax happens to provide a way to access
more variables than standard Scheme. If this is the case, I think we
should
I wrote:
The compiler-environment would include a list of lexical variable
names (var ...), which must exactly correspond to the closure slots of
the `case-lambda', in order to implement `local-eval'. We _might_ also
need to include some information about how those variables are stored,
Andy Wingo wi...@pobox.com writes:
What are the meanings of these expressions:
I found it amusing to see what my definitions using
with-current-continuation will produce here.
;; Toplevel
(local-eval '(define foo 42) (the-environment))
guile (my-eval '(define foo 42) (my-env))
guile foo
On 16 Dec 2011, at 11:33, Mark H Weaver wrote:
Here's what I currently see:
scheme@(guile-user) (local-eval #'t (primitive-eval '(let ((t 42)) (or #f
(the-environment)
ERROR: In procedure memoize-variable-access!:
ERROR: Unbound variable: t
This is the correct behavior, no?
This
On 16 Dec 2011, at 13:43, David Kastrup wrote:
Here's what I currently see:
scheme@(guile-user) (local-eval #'t (primitive-eval '(let ((t 42))
(or #f (the-environment)
ERROR: In procedure memoize-variable-access!:
ERROR: Unbound variable: t
This is the correct behavior, no?
This
Hi,
The delayed evaluation thread is a bit long and confusing, so I would
like to try to summarize it.
Lilypond has a way to embed Lilypond code in Scheme, and Scheme code in
Lilypond code. The former uses a reader macro, #{#}. The latter uses
specially-marked variables and expressions,
On 15 Dec 2011, at 11:21, Andy Wingo wrote:
The delayed evaluation thread is a bit long and confusing, so I would
like to try to summarize it.
Lilypond has a way to embed Lilypond code in Scheme, and Scheme code in
Lilypond code. The former uses a reader macro, #{#}. The latter uses
On 15 Dec 2011, at 18:24, David Kastrup wrote:
The delayed evaluation thread is a bit long and confusing, so I would
like to try to summarize it.
Lilypond has a way to embed Lilypond code in Scheme, and Scheme code in
Lilypond code. The former uses a reader macro, #{#}. The latter uses
Hello all,
Although it has not yet been decided whether `local-eval' will be
accepted into Guile 2, I've decided to proceed with a proper
implementation that is fully integrated into the compiler.
I hope to demonstrate that this feature can be implemented easily
without creating any significant
13 matches
Mail list logo
