Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a

[Ludovic Courtès]

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’.