Re: Syntax checks

[Marius Vollmer]

Lynn Winebarger <address@hidden> writes:

> Sorry for taking so long, I've been browsing guile.

Heh, no problem.  I enjoy not getting e-mail more and more... ;-)

> [...] How will generics interact with the module system? How will
> classes interact with nested modules?  I'll try to write some
> (currently non-interpretable) code to illustrate what I'm thinking
> about and how it should evaluate.

My current stance on this is that generics and classes should not be
treated specially by the module system.  Just like functions, generics
and classes are nameless objects that just happen to be accessible via
some name (or more than one, or none).  Thus, modules should only be
there to manage the name-space, not to create new (merged) generics, etc.

>      It's interesting because the old code continues to refer to the
> variable binding and yet you can't create a new reference to that
> location.  This seems to be the logical result of requiring the
> ability to specify syntax in non-operator positions
> ("identifier-syntax").  My thinking is that while they're logically
> separate environments, they should should be implemented in one
> table, where each entry has 2 possible entries (one for syntax and
> one for variable).

Yes, indeed.  Guile is somewhat confused about this right now: it does
symbol -> variable -> macro instead of symbol -> macro.

> > Also, I think we should extend this to bindings in modules: when
> > the list of exported bindings of a module changes (say), the
> > current proposal is to automatically correct all existing uses of
> > the affected bindings.  I now think it will be better to fix the
> > list of imported bindings when executing a 'define-module' or
> > 'use-modules' (if it survives) statement.  This is Dirk's
> > signatures idea, and I now finally got it, I think.  When you want
> > a changed export list to take effect, you need to reload/recompile
> > the files that are affected by it.
> > 
>      I've looked at signatures.texi, but I don't see how this
> relates.

Not much, I'd say.  The main thing I took away from signatures is that
they are compile-time constructs, not run-time constructs.  (If I
understood them right.)  That is, what binding comes from what module
is fixed at compile time, not at load time.  Knowing at compile time
which module to look in for a given symbol is important for macros,
and also for doing important optimizations (such as inlining of
fixnum-+, say).

>  I'm not actually sure adding bindings to a module _after_ its
> definition/lexical scope should be possible at all.  Redefinition of
> the entire module, yes.  But then the old definition/bindings would
> be still in use by the other modules that used it.

Yes, my view as well.

>       Another issue - how would you direct the compiler to export C
> "bindings" (e.g. a trampoline shared library and header file).

What do you mean?  How to export bindings from a module defined in C?

> This touches on something I've noticed while browsing - why are
> there so many smobs in the core interpreter?  Is it because you
> can't export macros to C automatically, or is there a deeper reason?

I don't understand.  How would macros reduce the need for smobs?