Hi Mike,
I think “Standard Library” should eventually be merged into “Guile
Modules”. The reason it’s separate currently is that its contents are
automatically extracted from the module comments, which is inherited
from Guile-Lib. But merging them also means improving their integration
with the
> From: Ludovic Courtès
> Hi Mike,
>
> I think “Standard Library” should eventually be merged into “Guile
> Modules”.
I could try it. It'll take me a few weeks to geto to it, though.
> Regarding standard/extended/3rd-party library, how about adding
> second-level sections to sort by theme?
Mark H Weaver writes:
> Here's the third version of my simple `local-eval' patch.
> Notable changes from last time:
>
> * Pattern variables are now captured properly.
> * `the-environment' now works as advertised within macro definitions.
> * Added doc strings for `local-eval' and `local-compile'
Hi list,
Attached is a patch that implements a new accessor,
syntax-local-binding. It's like syntax-local-value, but can also
determine if an identifier is a pattern var or a normal lexical.
> (define-syntax local-binding
(lambda (x)
(syntax-case x ()
((_ id) (identifie
Hi Mark,
On Sat 14 Jan 2012 21:37, Mark H Weaver writes:
> If a top-level variable needs to be expanded in user code, then you'd
> better explicitly choose a stable name for it.
Indeed, this is the best solution, for interface stability.
But what should happen when users do introduce top-level
David Kastrup writes:
> I am not altogether comfortable with pushing a "temporary fix" for the
> sake of LilyPond when we'll get another behavioral change with the next
> version.
But there would _not_ be a behavioral change in the next version.
It would only be a change in the internal implement
On Sun 15 Jan 2012 18:00, Andy Wingo writes:
> Attached is a patch that implements a new accessor,
> syntax-local-binding.
Here 'tis!
>From 09ba44abeb47cdf4ec61df6f7386217f0cbe30c7 Mon Sep 17 00:00:00 2001
From: Andy Wingo
Date: Sun, 15 Jan 2012 17:51:02 +0100
Subject: [PATCH] add syntax-local
Mark H Weaver writes:
> David Kastrup writes:
>
>> I am not sure that the reasons for not permitting definition context in
>> local-eval are not of somewhat more theoretical than practical nature,
>
> There's at least one practical reason not to allow it, namely that it is
> _impossible_ to impl
Well, deciding to use my guile checkout not just for reference, I tried
./autogen.sh, ./configure and make on master.
For one thing it is an aggravation that configure stops at the first
unfound library dependency instead of going on and creating a report for
all of them. That means that it take
David Kastrup writes:
> Mark H Weaver writes:
>
>> David Kastrup writes:
>>
>>> I am not sure that the reasons for not permitting definition context in
>>> local-eval are not of somewhat more theoretical than practical nature,
>>
>> There's at least one practical reason not to allow it, namely
David Kastrup writes:
> Well, deciding to use my guile checkout not just for reference, I tried
> ./autogen.sh, ./configure and make on master.
For now, it's best to stay on the "stable-2.0" branch.
That's our current focus.
Mark
Mark H Weaver writes:
> David Kastrup writes:
>
>> Mark H Weaver writes:
>>
>>> David Kastrup writes:
>>>
I am not sure that the reasons for not permitting definition context in
local-eval are not of somewhat more theoretical than practical nature,
>>>
>>> There's at least one practi
Mark H Weaver writes:
> David Kastrup writes:
>> Well, deciding to use my guile checkout not just for reference, I tried
>> ./autogen.sh, ./configure and make on master.
>
> For now, it's best to stay on the "stable-2.0" branch.
> That's our current focus.
Interesting.
--
David Kastrup
David Kastrup writes:
> Mark H Weaver writes:
>
>> David Kastrup writes:
>>
>>> Mark H Weaver writes:
>>>
David Kastrup writes:
> I am not sure that the reasons for not permitting definition context in
> local-eval are not of somewhat more theoretical than practical nature,
Mark H Weaver writes:
> David Kastrup writes:
>
>> What is confusing here? "Obviously, definitions made in the scope of
>> local-eval can't retroactively affect the environment where
>> the-environment was called." And now instead of continuing with the
>> unfriendly "For this reason, they are
David Kastrup writes:
>> You are suggesting that we wrap the expression within a (let () ...),
>> for the dubious benefit of allowing you to wrap the local forms in
>> (begin ...) instead of (let () ...).
>
> Are there even situations where you could put definitions after begin?
> How are they di
Mark H Weaver writes:
> David Kastrup writes:
>
>>> You are suggesting that we wrap the expression within a (let () ...),
>>> for the dubious benefit of allowing you to wrap the local forms in
>>> (begin ...) instead of (let () ...).
>>
>> Are there even situations where you could put definition
David Kastrup writes:
> In the light of local-eval evaluating a _form_ rather than a _body_
> (stupid of me to forget), and seeing the weird semantics of begin, I
> agree that an implicit (let () ...) wrapper for a single form does not
> really appear to add significant gains. It would be margin
Hi Mike!
Mike Gran skribis:
> Much of Slib still works. It does use some removed functions.
Good to know. Though if it “uses” removed functions, it doesn’t
completely work? :-)
> The installation has problems. Its makefile installs slib into
> a directory that Guile doesn't search, and the
Hi Mark,
I had made some noise about preferring an implementation of local-eval
based on primitives from psyntax. But, I didn't clarify my argument by
providing the primitives. Here are some patches that provide
syntax-local-binding, as I noted in my previous mail, and also a
procedure to get al
Hi Andy,
Thanks very much for heeding my call for `local-eval' in 2.0.4, and
for putting so much time into this.
For the record, I still think it's better for `the-environment' to be
implemented within psyntax as a core form. It's a fundamental syntactic
construct with clean semantics, and it be
David Kastrup writes:
> guile> (let ((x 2)) (eval '(begin (define x 4) x) (current-module)))
> 4
> guile> x
> 4
> guile>
>
> Right through to the top. And we couldn't do that in local-eval. But
> it also has no qualms just because previously evaluated forms would have
> used a previous definitio
Mark H Weaver writes:
>> What if the-environment had been taken at top-level (basically just
>> carrying the information of (current-module))? Should local-eval then
>> behave accordingly? If so, could we not just fold eval and local-eval
>> into one function?
>
> This is a good question. Unfo
David Kastrup writes:
> It might come handy to have local-eval not balk upon getting a module,
> but without letting it set the current module.
Agreed, and my implementation of `local-eval' does exactly that.
Mark
24 matches
Mail list logo
