Re: Fixing the slib mess

[Mark H Weaver <mhw@netris.org>]

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 <mikael@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