[Prev][Next][Index][Thread]

Re: dylan-user

On Thu, 13 Sep 2001, natas wrote:
> > > I don't understand why the Module: statement is needed, if libraries
> > > are at the top of the hierarchy, i.e., libraries contain modules.
> > > Doesn't this statement say that the time library is in the
> > > dylan-user module?
> >
> > I should know this one. :-) I think it's also because code has to be in
> > modules. :-) Hopefully someone can give a better answer than this.
>
> *sigh*, this semi-circular-chicken-and-egg stuff is really bugging me!  :-)
> Some of my confusion is coming from the fact that in my mind, the define
> library isn't really "code" (is it?).  Sure it's code, but it's not
> _executable code_.
> Anyway, if the intent of the dylan-user module is to import the dylan
> module, then why do example libraries have to have their own
>
> use dylan;
>
> statements within their definition?  Why not do _that_ implicitly, too?
> 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.
>
> Someone needs to chime in authoritatively on this before I go nuts.
> Is there a language lawyer in the house?

Well, IANALL ;-) but ...


Bascially, the *text* of a Dylan /program/ consists of zero or more
/source records/, each of which contains zero or more /top-level forms/.
A top-level form is essentially a "define something ... end" macro call or
an expression (including, for example, function calls or "begin ... end"
statement blocks).  The only thing you can't really have at top level are
exception handlers.  Definer macro calls *are* conceptually executable
code but (at least for libraries and modules) they're always executed at
compile time, and they're pretty much independent of order (in theory --
Your Compiler May Vary).

The "Module: foo" line is not part of the Dylan language itself, but of
the "Dylan Interchange Format" (also defined in the DRM) for storing Dylan
in text files.  Each text file constitutes a source record.  If you had a
development environment like Apple's Technology Release, source records
might be in a database, which would store and display the module of that
source record in some other way.

The compiler has to know which module a source record belongs to, so that
it knows which bindings are visible and where their definition comes from.
The *only* /special form/ is "define macro", which can't be renamed or
shadowed.


That describes the text of a Dylan program but not the
library/module/binding *containment*.  Libraries are compile-time entities
which are created by calls to "define library" (or, to any macro whose
expansion calls that, but I'll ignore that for now).  The library itself
lives in a global namespace, outside any modules, but the *definition* has
to happen in a module where "\library-definer" is visible.

(Similarly modules are created by calls to "define module".  Which library
they exist in just depends on which other source records they're compiled
with -- there must be exactly one "define library" for it to be a valid
Dylan program.  The module might be exported by the library, but it might
not -- it might be a utility module imported by other modules in the
library.)

The dylan-user library exists so that you can create a source record in
which "\library-definer" is definitely visible; in that source record you
can define your library.

Theoretically you could write something like this:

----------------------------------------------------------------
Module: my-module

define library my-library
  use dylan;
end;

define module my-module
  use dylan;
end;
----------------------------------------------------------------

and then require the compiler to prove that the calls to
"\library-definer" and "\module-definer" here are really calls to the
macros with those names exported from the "dylan" module.  However, that's
(even) more hassle for compiler writers and you could probably increase
the complexity of "circular" examples like these until some compilers
could cope and others couldn't.


Lastly, the reason for not doing "use dylan;" implicitly is that you might
want to use an implementation-specific library/module which exports all
the bindings of the Dylan library/module, plus some of its own.  FunDev
has "functional-dylan" as well as versions of "dylan" which do some magic
on "\+" etc. to support generic arithmetic; both FunDev and Gwydion have
"common-dylan".


So, does that help any, or are you now even more confused? ;-)

Hugh


-- 
Version 3.1 GCS/IT d- s+:+>+: a- C++$ UL P+ L+(++) E W++$ N++ o K++ w(++) O?
M V? PS(+) PE Y+ PGP->++ t(+) 5+(++) X(+) R tv b++ DI+ D+ G e++ h- r>++ y+
(Removed reversed spam from my email address to reply)
Follow-Ups: References: