On Wed 14 Dec 2011 08:50, Mark H Weaver m...@netris.org writes:
I have successfully implemented the (capture-lexical-environment)
special form in the evaluator, and also primitive-local-eval.
I dunno, Mark. That's a neat hack, but why should we have it in Guile?
It can't compile. It's not
Andy Wingo wi...@pobox.com writes:
On Wed 14 Dec 2011 00:45, David Kastrup d...@gnu.org writes:
Andy Wingo wi...@pobox.com writes:
On Wed 14 Dec 2011 00:00, Noah Lavine noah.b.lav...@gmail.com writes:
I haven't really been contributing to this thread, so please take my
opinion with a
Andy Wingo wi...@pobox.com writes:
On Wed 14 Dec 2011 08:50, Mark H Weaver m...@netris.org writes:
I have successfully implemented the (capture-lexical-environment)
special form in the evaluator, and also primitive-local-eval.
I dunno, Mark. That's a neat hack, but why should we have it in
Andy Wingo wi...@pobox.com writes:
On Wed 14 Dec 2011 08:50, Mark H Weaver m...@netris.org writes:
I have successfully implemented the (capture-lexical-environment)
special form in the evaluator, and also primitive-local-eval.
I dunno, Mark. That's a neat hack, but why should we have it in
Mark H Weaver m...@netris.org writes:
Also, I think that it is crucially important to keep the Lilypond
developers happy with Guile. We don't have very many users. We
should make an effort to keep our existing users happy.
Basically, you want to be able to write the following in the FAQ:
Perhaps this is obvious to everyone else, but it just occurred to me
that (capture-local-environment) is just
(call-with-current-continuation), but running in the environment of
the evaluator instead of the program being evaluated. It's as though
the evaluator was going to look in a tree for more
Hi David,
On Wed 14 Dec 2011 11:27, David Kastrup d...@gnu.org writes:
Andy Wingo wi...@pobox.com writes:
On Wed 14 Dec 2011 08:50, Mark H Weaver m...@netris.org writes:
I have successfully implemented the (capture-lexical-environment)
special form in the evaluator, and also
Hello!
Andy Wingo wi...@pobox.com skribis:
But, in the event that David wants to continue with his current
strategy, there are other things that can be done. David, did you know
that Guile's evaluator is implemented in Scheme? That means that if you
want an evaluator with different
Andy Wingo wi...@pobox.com writes:
On Wed 14 Dec 2011 08:50, Mark H Weaver m...@netris.org writes:
I have successfully implemented the (capture-lexical-environment)
special form in the evaluator, and also primitive-local-eval.
Let's call it `(the-environment)', as it is what it was called in
Mark H Weaver m...@netris.org writes:
Personally, I don't view `the-environment' and `local-eval' as an ugly
hack, but rather as a cool feature like delimited continuations. It's
something Guile 1.8 could brag about.
I wish it had bragged about it at all (in the case of the-environment)
or
Mark H Weaver m...@netris.org writes:
Replying to myself:
Andy Wingo wi...@pobox.com writes:
It is my opinion -- and I could be wrong here, either by
misunderstanding (again!) the issues, or for whatever reason -- that
closures are the best solution to the #{#} problem.
I would love to
David Kastrup d...@gnu.org writes:
To be fair: this is what we currently do, and we only actually call
those lambdas that end up actually being recognized by the grammar.
So as long as (primitive-eval `(lambda () ,(read))) is guaranteed to
not ever choke, the potential for error is limited.
Hi Noah,
Noah Lavine noah.b.lav...@gmail.com writes:
Perhaps this is obvious to everyone else, but it just occurred to me
that (capture-local-environment) is just
(call-with-current-continuation), but running in the environment of
the evaluator instead of the program being evaluated. It's as
David Kastrup d...@gnu.org writes:
(define (my-eval form env)
(call-with-current-continuation
(lambda (x)
(env (list x form)
(define-macro (my-env)
(call-with-current-continuation
identity))
(format #t ~a (my-eval '(+ x 3) (let ((x 4)) (my-env
Mark H
On Wed 14 Dec 2011 22:03, Mark H Weaver m...@netris.org writes:
Noah Lavine noah.b.lav...@gmail.com writes:
[(the-environment)] is just (call-with-current-continuation),
In fact it makes me wonder whether `the-environment' and `local-eval'
could actually be implemented this way.
This
On Wed 14 Dec 2011 18:26, Mark H Weaver m...@netris.org writes:
Andy Wingo wi...@pobox.com writes:
It is my opinion -- and I could be wrong here, either by
misunderstanding (again!) the issues, or for whatever reason -- that
closures are the best solution to the #{#} problem.
I would love
Andy Wingo wi...@pobox.com writes:
On Mon 12 Dec 2011 19:29, Mark H Weaver m...@netris.org writes:
You are using Guile in a very unusual way. You have constructed a
hybrid language of both Scheme and Lilypond, where each can be nested
within the other (so far so good), but -- and here's the
Andy Wingo wi...@pobox.com writes:
Did you see my implementation of `local-eval' [1]? It leverages (hah!)
Guile's macro expander, but otherwise is a straightforward interpreter.
If you find it slow, there are some simple, classic optimizations that
can be made. With some work, it could
On Tue 13 Dec 2011 10:02, David Kastrup d...@gnu.org writes:
Lilypond's input language is not David's current strategy.
I was referring to your implementation strategy. Mark describes
another implementation strategy.
It does not help because it requires _advance_ knowledge of when you are
Andy Wingo wi...@pobox.com writes:
On Tue 13 Dec 2011 10:02, David Kastrup d...@gnu.org writes:
Lilypond's input language is not David's current strategy.
I was referring to your implementation strategy.
It's not a strategy. Merely the least painful way to do things at a
given point of
Hello David,
Let us focus on solutions.
If the this realm does have a coin, it is good-will. All participants
start with ample deposits, but yours is draining fast. Please listen to
what people are saying; they are trying to help you.
Specifically:
On Tue 13 Dec 2011 14:56, David Kastrup
Andy Wingo wi...@pobox.com writes:
Hello David,
Let us focus on solutions.
If the this realm does have a coin, it is good-will. All participants
start with ample deposits, but yours is draining fast. Please listen to
what people are saying; they are trying to help you.
Lilypond already
On Tue 13 Dec 2011 16:27, David Kastrup d...@gnu.org writes:
It sounds like `current-bindings' is the thing you need.
It will at least be a year before any solution that does not work with
Guile 1.8 will be accepted into Lilypond.
It is possible to have similar interfaces with different
David Kastrup d...@gnu.org writes:
So I don't think that throwing out _distinguishing_ selling points of
Guile is necessarily doing you a favor. And the transparency with
which it integrates with its language environment and the fact that
one can continue to use its evaluator and debugger
Andy Wingo wi...@pobox.com writes:
On Tue 13 Dec 2011 16:27, David Kastrup d...@gnu.org writes:
It sounds like `current-bindings' is the thing you need.
It will at least be a year before any solution that does not work with
Guile 1.8 will be accepted into Lilypond.
It is possible to have
On Tue 13 Dec 2011 17:08, David Kastrup d...@gnu.org writes:
The current implementation wraps scraps of code into (lambda () ...) and
executes them on-demand. So the expectation is that embedded Scheme
code can have side-effects on the lexical environment like with
(let ((xxx 2))
#{
Andy Wingo wi...@pobox.com writes:
On Tue 13 Dec 2011 17:08, David Kastrup d...@gnu.org writes:
The current implementation wraps scraps of code into (lambda () ...) and
executes them on-demand. So the expectation is that embedded Scheme
code can have side-effects on the lexical environment
Hi Andy,
Andy Wingo wi...@pobox.com writes:
Am I missing something? It has been a long thread :)
In case you haven't carefully read my earlier thread with David, I
wanted to briefly explain the difficulties as I understand them, from a
Schemer's perspective. If I have misunderstood something,
On Tue 13 Dec 2011 17:54, David Kastrup d...@gnu.org writes:
Am I missing something?
Performance, space, simplicity, robustness. Compiling five closures
that do nothing except accessing a single variable each is a bit
wasteful.
Sure.
Let me see if I finally understand the issue here:
You
Andy Wingo wi...@pobox.com writes:
On Tue 13 Dec 2011 18:28, Mark H Weaver m...@netris.org writes:
(let ((xxx 2))
#{ #(set! xxx (1+ xxx)) #})
In the general case, Lilypond needs to _execute_ the outer Scheme code
before the parser/evaluator is able to even _see_ the inner Scheme code,
Andy Wingo wi...@pobox.com writes:
On Tue 13 Dec 2011 17:54, David Kastrup d...@gnu.org writes:
Am I missing something?
Performance, space, simplicity, robustness. Compiling five closures
that do nothing except accessing a single variable each is a bit
wasteful.
Sure.
Let me see if I
Hello,
I haven't really been contributing to this thread, so please take my
opinion with a grain of salt. But it does appear to me that we should
support capturing a lexical environment, as Mark and David describe.
So I took a look at ice-9/eval.scm to see how difficult it would be to
implement.
Noah Lavine noah.b.lav...@gmail.com writes:
Hello,
I haven't really been contributing to this thread, so please take my
opinion with a grain of salt. But it does appear to me that we should
support capturing a lexical environment, as Mark and David describe.
So I took a look at
Andy Wingo wi...@pobox.com writes:
On Wed 14 Dec 2011 00:00, Noah Lavine noah.b.lav...@gmail.com writes:
I haven't really been contributing to this thread, so please take my
opinion with a grain of salt. But it does appear to me that we should
support capturing a lexical environment, as Mark
and that other programs that use Guile for extension will run into
similar difficulties, but as far as I can tell Lilypond is quite
unique here.
Because nobody else uses Guile for serious extensions. And not because
of its performance: that is _irrelevant_ for most extension purposes.
David Kastrup d...@gnu.org writes:
Basically I need to evaluate dynamic code in a given lexical environment
rather than at top and/or module level.
For a language that is supposed to be a building block for extension
languages, not really a concept that is all that unusual I would think.
() David Kastrup d...@gnu.org
() Sat, 03 Dec 2011 16:45:06 +0100
The lack of procedure-environment in Guilev2 implies that I
have to wrap the stuff in (lambda () ...) in order to capture
the lexical environment for evaluation.
Is it possible to have a shortcut (make-closure ...) or
Hi, if I have something read that is evaluated later, the lack of
procedure-environment in Guilev2 implies that I have to wrap the stuff
in (lambda () ...) in order to capture the lexical environment for
evaluation.
Is it possible to have a shortcut (make-closure ...) or so for that
purpose?
On Sat 03 Dec 2011 16:45, David Kastrup d...@gnu.org writes:
Hi, if I have something read that is evaluated later, the lack of
procedure-environment in Guilev2 implies that I have to wrap the stuff
in (lambda () ...) in order to capture the lexical environment for
evaluation.
Is it possible
39 matches
Mail list logo
