On Tue 13 Dec 2011 05:39, Noah Lavine writes:
> Following up on my last email, I am nervously announcing a new branch,
> 'wip-compiler'. I hope that in a few months this branch will contain a
> working compiler. For now, it contains a few new data structures and a
> function that converts Tree-IL
Andy Wingo writes:
> On Mon 12 Dec 2011 19:29, Mark H Weaver 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 kicker -- you
>> appar
I'm a little worried by the amount of file descriptors left opened
after the objcode is mmaped.
I saw this "note to self" from objcodes.c:
/* FIXME: we leak ourselves and the file descriptor. but then again so does
dlopen(). */
So apparently the author was well aware of
Andy Wingo 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 present a simila
On Tue 13 Dec 2011 11:15, ri...@happyleptic.org writes:
> I'm a little worried by the amount of file descriptors left opened
> after the objcode is mmaped.
> I saw this "note to self" from objcodes.c:
>
> /* FIXME: we leak ourselves and the file descriptor. but then again so does
>
On Tue 13 Dec 2011 10:02, David Kastrup 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
> going to
-[ Tue, Dec 13, 2011 at 01:42:35PM +0100, Andy Wingo ]
> If you close the fd, isn't the memory unmapped? Isn't that a bad thing?
>
> Maybe I was just under a big misconception here :)
That's a common misconception. The mapping of VM space to disk storage
is unrelated to the file descriptor s
> Cool. As a quick reaction, I have some doubts about this project. But,
> I guess a WIP branch would be a good thing to have, and it would make
> the discussion more concrete.
Probably so. But if you have time, what are your doubts? I would much
rather talk about problems now than after I've im
Andy Wingo writes:
> On Tue 13 Dec 2011 10:02, David Kastrup 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 time. The given point
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 wri
Andy Wingo 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 has an ug
On Tue 13 Dec 2011 16:27, David Kastrup 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
implementati
David Kastrup 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 even for th
Andy Wingo writes:
> On Tue 13 Dec 2011 16:27, David Kastrup 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 interfa
Andy Wingo writes:
> On Tue 13 Dec 2011 16:27, David Kastrup 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 interfa
On Tue 13 Dec 2011 17:08, David Kastrup 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))
> #{ #(set! xxx
Andy Wingo writes:
> On Tue 13 Dec 2011 17:08, David Kastrup 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
Hi Andy,
Andy Wingo 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, hopefully
Davi
On Tue 13 Dec 2011 18:28, Mark H Weaver 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,
> because it needs to parse/evaluate the Lily
On Tue 13 Dec 2011 17:54, David Kastrup 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 have a
Andy Wingo writes:
> On Tue 13 Dec 2011 18:28, Mark H Weaver 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,
>> because it nee
Andy Wingo writes:
> On Tue 13 Dec 2011 17:54, David Kastrup 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 und
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 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 ice-9/eval.scm to see how di
On Wed 14 Dec 2011 00:00, Noah Lavine 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 David describe.
>
> So I took a look at ice-9/eval.sc
On Wed 14 Dec 2011 00:16, David Kastrup writes:
> guile> '#{ \relative c' { $p 2 \mark #4 } #}
> (#
> parser " \\relative c' { $p 2 \\mark #4 } " #f 2 (list (cons 17 (lambda ()
> p
Ah, thanks for this example. Thanks also for the previous example music
mail.
> The obvious wishlist item
Andy Wingo writes:
> On Wed 14 Dec 2011 00:00, Noah Lavine 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 David describe.
>>
>> So I
Hello!
I finally committed ‘file-system-fold’ (and its new friend
‘file-system-tree’), but I have yet to write ‘scandir’ (unless someone
else does ;-)).
Feedback welcome!
Thanks,
Ludo’.
Andy Wingo writes:
> On Wed 14 Dec 2011 00:00, Noah Lavine 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 David describe.
>>
>> So I to
On Tue, Dec 13, 2011 at 6:39 PM, Andy Wingo wrote:
> On Wed 14 Dec 2011 00:00, Noah Lavine 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
> The details of the interpreter's implementation are not public, I'm
> afraid. The interpreter does its job, but not quickly, and any change
> to make it better would involve a change to the environment
> representation.
>
> Anyway, it's looking in the wrong place. There is a compiler too.
And
Hi Noah,
Noah Lavine writes:
> So I took a look at ice-9/eval.scm to see how difficult it would be to
> implement. Offhand, it doesn't look bad: the eval function there
> already passes around environment objects, so if it hit this special
> form, it would simply return its environment object (pr
I have successfully implemented the (capture-lexical-environment)
special form in the evaluator, and also primitive-local-eval.
Here's a transcript from a test session:
scheme@(guile-user)> (define env1 (primitive-eval '(let ((x 1) (y 2))
(capture-lexical-environment
scheme@(guile-user)>
33 matches
Mail list logo
