[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fixing the slib mess
From: |
Mikael Djurfeldt |
Subject: |
Re: Fixing the slib mess |
Date: |
Tue, 23 Oct 2012 10:23:01 +0200 |
On Mon, Oct 22, 2012 at 11:51 PM, Mark H Weaver <address@hidden> wrote:
> It looks to me like your current implementation of 'syntax-toplevel?'
> is actually testing for a top-level _syntactic_ environment, but what
> you ought to be testing for here is slightly different.
You are absolutely right. Thank you for spotting this. Unfortunately
my scheming knowledge is a bit rusty.
> I'm not sure whether the wrap contains enough information to determine that.
I don't think it does either.
> 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)?
> I happen to be working on the reader lately. Would it help to implement
> SRFI-58 in our reader?
While I think SRFI-58 support is great, I don't think slib needs it
because it doesn't, to my knowledge, use read syntax.