[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: module naming
From: |
thi |
Subject: |
Re: module naming |
Date: |
Tue, 8 May 2001 19:45:55 -0700 |
From: Marius Vollmer <address@hidden>
Date: 07 May 2001 13:43:43 +0200
> (use-modules (foo bar) :import-only (something))
But shouldn't we use `use-module' here, not `use-moduleS'? I think
when specifying more arguments, we should restrict one statement to
one module.
good point. another approach would be to do:
(use-modules ((foo bar) :import-only (something))
((bar baz) :import-only (other-thing)))
> (define-module (my module)
> :use-module (ice-9 common-list) :rename (c++-envy-renamer 'cl))
Hmm, isn't the connection between :use-module and :rename a bit
loose? We would have to parse ahead to find all keywords that apply
to a :use-module.
yeah, we could use something like:
(define-module (my module)
:use-module ((ice-9 common-list) :rename (c++-envy-renamer 'cl)))
this has same internal syntax as above so we can share parsers (and
avoid introducing bugs).
> a potential glitch [...]
I'd say, just let it happen. Specify that it is undefined at what
times these procedures are called (just like macro transformers).
the timing is one thing, but i'm also concerned that the procedure names
have to be resolved somehow by the module system machinery... we could
restrict the renamer to be a lambda expression, but that seems kind of
ugly.
For simple and common things like prefixing, we could have dedicated
options like `:prefix SYMBOL'.
i am on the fence w/ this idea because although it is attractive, it
sort of crosses the mechanism/policy boundary too much for my tastes...
i would rather the module system description mini-language evolve
extensibility (at some future point after next release) rather than
accrue overly-specialized syntax. hopefully this "gut feel" explanation
makes sense.
thi