Re: Fixing the slib mess

[Mark H Weaver]

Hi Mikael,

Mikael Djurfeldt <address@hidden> writes:
> On Mon, Oct 22, 2012 at 11:51 PM, Mark H Weaver <address@hidden> wrote:
>> It might be easier to handle this with 'define-syntax-parameter' and
>> 'syntax-parameterize'.  The idea would be that within slib, 'define'
>> would be a syntax parameter.  Its default expansion would turn it into
>> 'define-public', and also parameterize 'define' to mean 'base:define'
>> within the body.  If needed, you could also define 'let' and maybe some
>> other things to parameterize 'define' within the body.
>>
>> Another option would be to make 'export' a syntax parameter, and
>> parameterize it to a no-op within lexical contours such as 'define' and
>> 'let'.
>>
>> What do you think?
>
> Correct me if I'm wrong, but doesn't this involve re-defining the
> syntax for all forms with bodies (in order to introduce the
> syntax-parameterize form)?

Yes, I guess it would, although perhaps you could come up with a smaller
set of forms that would be sufficient for slib.

I'm surprised that slib doesn't have a mechanism for making this job
easier for Scheme systems that support modules.  It seems like
generating the list of exports should not be so difficult.  Why doesn't
slib use something like 'define-public' to facilitate this?

Anyway, here's another idea: after requiring a new slib package, iterate
over the entire list of top-level bindings in the slib module and export
everything.

What do you think?

One more thing: ideally, any logic that peeks into Guile internals or is
likely to change between Guile versions should be in slib.scm, and
anything that's likely to change between slib versions should be in
guile.init.

Does that make sense?

    Thanks,
      Mark