[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: module naming
From: |
Rob Browning |
Subject: |
Re: module naming |
Date: |
06 May 2001 18:26:07 -0500 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
thi <address@hidden> writes:
> i guess i don't see how an `import-from' would work at all w/o doing an
> implicit `use-modules' anyway. maybe we are saying the same thing. :->
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.
> maybe i'm misunderstanding still ... could you explain what you mean
> by "in-line/programmatic"? it seems to me that what you describe is
> the function of `use-modules', which we already have, although w/o
> selection or renaming, both of which are separate and completely
> after loading / definition.
What I mean is that inside a module you can either export things by
listing them in the :export clause of the define-module statement, or
using a more programmatic (export foo) later in the source.
Similarly, I was thinking that for something like import-from, you
could allow the user to specify the symbols they want in the
use-modules statement, or you could allow a more programmatic
import-from interface as well. However, now that I think about it, as
long as you're allowed to put use-modules statements wherever you
like, and aren't limited to "one per used module per file", then
there's probably no need for import-from. use-module would be fine.
Instead of:
(import-from (foo bar) something)
...
...
(define (xxx) ...)
...
(import-from (foo bar) something-else)
...
you could just have:
(use-modules (foo bar) :import-only (something))
...
...
(define (xxx) ...)
...
(import-from (foo bar) :import-only (something-else))
...
etc. The main use of such a style would probably be auto-generated code.
--
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930
- Re: module naming,
Rob Browning <=