[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a
From: |
Ludovic Courtès |
Subject: |
Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a |
Date: |
Sun, 15 Jan 2012 00:40:08 +0100 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) |
Hello!
Mark H Weaver <address@hidden> skribis:
> Andy Wingo <address@hidden> writes:
>
>> On Wed 16 Nov 2011 04:58, Mark H Weaver <address@hidden> writes:
>>
>>> I think there are better ways to address this problem. I will explore
>>> these in another email.
>>
>> I look forward to this. Please be sure to address the following issues:
>>
>> * Debian upgrading guile to a newer version, without recompiling
>> guile-foo which depends on a hygienically introduced identifier.
>>
>> * A user modifying a Scheme file from Guile, in the spirit of the
>> LGPL, and expecting it to work with program Foo, without recompiling
>> Foo (again, in the spirit of the LGPL).
>
> If we must avoid the recompilations, then I see only one solution:
> simply refrain from introducing hygienic top-level identifiers in the
> expansions of public interfaces. IMHO, this isn't so bad. If a
> top-level variable needs to be expanded in user code, then you'd better
> explicitly choose a stable name for it.
That’s right. However, in some cases, one may want to write a macro,
that introduces an identifier that’s really an implementation detail,
and something the author does not want users to bother with.
See, for instance, ‘define-wrapped-pointer-type’. Initially, I would
have liked to not have a TYPE-NAME argument, because it’s not necessary
for the user, and really an implementation detail. Yet, producing a
hygienic top-level name wasn’t possible, so the TYPE-NAME argument had
to be kept.
This is acceptable in this example, but one could probably come up with
use cases where it’s more embarrassing.
> If you want the name to be programmatically based on some or all of
> the macro arguments, this can already be done using `symbol-append',
> `datum->syntax' et al.
Yes, but it’s not hygienic.
[...]
> To be more specific: I think we need to record, in every syntax
> transformer bound at top-level, the name of the module where it's bound.
> Then, within the dynamic extent of `compile-file', (probably using a
> fluid) we'd need to accumulate the set of modules whose macro
> transformers are used during compilation of the file. This set of
> modules (the compile-time dependencies) would be included in the .go
> file.
Sounds like a good plan!
> I think we need this _anyway_. Right now, if you change the way an
> exported macro works (for example a macro that defines a record type),
> you must _manually_ force recompilation of other modules that expand
> that macro. I actually ran into this problem while working on adding
> new compiler environment types.
Yes, that’s something one quickly encounters when incrementally
modifying code with Geiser, for instance.
Thanks,
Ludo’.
- Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a, Andy Wingo, 2012/01/06
- Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a, Mark H Weaver, 2012/01/14
- Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a, David Kastrup, 2012/01/14
- Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a, dsmich, 2012/01/14
- Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a,
Ludovic Courtès <=
- Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a, Andy Wingo, 2012/01/15