[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: |
Mon, 7 May 2001 01:32:55 -0700 |
From: Rob Browning <address@hidden>
Date: 06 May 2001 18:26:07 -0500
We are, more or less. I was just speculating about how an import-from
function would have to work, and as you mention, (import-from (foo
bar) baz) would have to perform an implicit (use-modules (foo bar)
:no-default-exports) before grabbing baz.
yes. in current parlance:
"(use-modules (foo bar) :no-default-exports)"
==
(resolve-module '(foo bar))
that is, the module is loaded and its exported interface determined, but
bindings are not created for the using (dependent, "calling") module.
[`(define-module ... :export ...)' and `(export ...)' duality]
Similarly, [...]
you could just have:
(use-modules (foo bar) :import-only (something))
(import-from (foo bar) :import-only (something-else))
etc. The main use of such a style would probably be auto-generated
code.
assuming you meant "use-modules" in the second form, i think i
understand what you mean now. would it be correct to phrase this as:
"the functionality of "granular import" should also be available as a
top-level form." ?
if that's the case, i propose we extend `use-modules'-type functionality
to handle selection and renaming (in that order) and provide both
`define-module' and top-level `use-module' interfaces. additionally,
we can provide some "conventional" renamers:
;; we provide
(define (c++-envy-renamer prefix)
(lambda (sym)
(symbol-append prefix ':: sym)))
;; the programmer writes
(define-module (my module)
:use-module (ice-9 common-list) :rename (c++-envy-renamer 'cl))
(cl::find-if even? '(1 2 3 4 5))
(use-modules (ice-9 regex) :import-only (string-match)
:rename (lambda (sym)
(string->symbol
(string-upcase
(symbol->string sym)))))
(STRING-MATCH "^[a-z]+" "text is beautiful")
i propose this approach because i've already written most of the code
and just need to check it (and its documentation) in. ;->
a potential glitch is that the renamer proc should be relatively
restricted (no side effects, no dependencies on other modules, etc),
which is easy to specify but hard to detect. (and if detected, what is
the exception model?)
thi