Hi Mikael!
It's great to see you on guile-devel again, and it would be good to have
a working slib on Guile 2. Thanks for working on this :)
Mikael Djurfeldt <mik...@djurfeldt.com> writes:
> Comments? Can I add syntax-toplevel? to psyntax.scm and (system
> syntax)?
FWIW, it sounds reasonable to add something like 'syntax-toplevel?'.
However, if it's going to be added as a public API, we ought to be
careful to get it right. Consider this top-level form:
(let-syntax ((foo (syntax-rules () ((foo x) (quote x)))))
(define bar (foo (a b))))
Here, although the 'define' is expanded within a non-toplevel syntactic
environment, after expansion it ends up within a top-level environment,
and indeed 'bar' becomes a top-level binding. That's because the body
of a 'let-syntax' or 'letrec-syntax' gets spliced into the outer
context, sort of like a 'begin' but with some syntax bindings added.
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. I'm not sure
what is the proper term, but for now I'll call it a top-level
_execution_ environment.
I'm also not quite sure how best to test for a top-level execution
environment. I'm not sure whether the wrap contains enough information
to determine that.
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?
> I should also say that I have not yet fixed the slib interface to the
> new Guile uniform arrays, so there's a lot of slib functionality which
> won't yet work.
I happen to be working on the reader lately. Would it help to implement
SRFI-58 in our reader? Note that SRFI-58 array notation conflicts with
Guile's own array notation, e.g. #1a("a" "b") is legal in both syntaxes
and means different things. So we'd need to use a reader-directive such
as #!srfi-58 to change the reader mode on that port. Would that help?
Thanks for working on this!
Regards,
Mark
