[Prev][Next][Index][Thread]
Re: dylan-user
On Thursday, September 13, 2001, at 04:30 am, natas wrote:
> Anyway, if the intent of the dylan-user module is to import the dylan
> module,
It isn't. Importing is done with use/import statements in class/module
declarations.
It's there to place the top-level-forms (thanks Gabor!) you are writing
in Dylan's universe. It does not import anything, it just says to the
compiler "yeah, don't worry, this stuff is going in the magic user
module so it has somewhere to live".
> then why do example libraries have to have their own
>
> use dylan;
>
> statements within their definition? Why not do _that_ implicitly, too?
Yes, you could do that implicitly.
But it's a good job the language designers didn't, because 'dylan' was
superceded by 'functional-dylan' and the gywdion extensions, which were
unified to become 'common-dylan'.
So what originally must have looked like a silly bit of
ultra-correctness has given the language the flexibility it needed to
mature.
> And, to reiterate, the Module: dylan-user statement at the beginning
> of a
> source file that defines a library and the modules within that library
> _seems_ to contradict the containment hierarchy of libraries containing
> modules.
It doesn't define a module (and it doesn't import anything). It places
the code in a pre-existent module defined by the compiler for our
convenience and sanity.
Let's look at the example of user code.
We go:
file1.dylan
module: dylan-user
define module klin
....
file2.dylan
module: klin
define method blim....
So we've created a module using a macro in file 1, and code is then put
into that module in file 2. Note that whether code is an exposed part of
a module's interface or not, it's still part of *some* module.
But file1 has a problem. Which module do module declarations go in when
we haven't already defined a module for code to go in?
They go in the *magic* dylan-user module. Dylan-user is quite happy to
have all sort of code added to it, and it's good that it is otherwise
we'd have nowhere to put the top-level-forms to declare other modules.
Whilst it may feel like a circularity, and it looks like it breaks the
hierarchy, it's actually there to avoid a circularity. Also, the
library/module scheme is flat (there's no nesting as with C++
namespaces), so there's only really one place libraries/modules go when
they're created.
- Rob.
--
"The idea behind Dylan—to offer a range of dynamism appropriate to each
piece of an application—feels right, and after using Dylan you will
become frustrated with C++ and Java."
- Peter Norvig, Software Developer Magazine.
References: