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

put library <body> at top-level

I don't see any rationale for:

(library <lib-path> <language>

rather than identitying a library with a file, as in:

(library <lib-path> <language>)

The former is syntactically awkward: Moving definitions from
a top-level file to a library requires re-indenting.  There is
too much indentation and parentheses as it is; I think top-level
definitions in a library really should be top-level.

A minor advantage: It also opens up for non-Scheme read syntax:

(library "my-lib" "xml-scheme://")
<define-function name="fact">...</define-function>
<!-- I don't claim this is terribly useful! -->

Also, the proposal is unclear about non-libraries:  Can I import
a library into "the top-level"?  Would everything be a library
in this new world?  In that case, having to wrap eveything
in a library form would be a pain.  Instead, I propose we
view the "top-level" as an library that just has imports
but no exports.

More importantly, there are practical advantages of declaring
that library==file.  It allows library-name==file-name.  This
means you can search for libraries without having to scan them
or build a "library database".  This has worked pretty well for
Java - and for Kawa.

In Kawa a module is a source file that get compiled to a main class
file (and possibly auxilliary classes).

You would still have that the "way that URIs for library references are mapped to library declarations is implementation-specific." However,
the most common mechanism would make use of file naming: Relative
lib-paths would be interpreted by searching an implementation-specific
library search path, but the default initial component of the search
path is relative to the current library, using URL resolution.

I.e. assume library "util/stack" imports "vector".  Then that would
resolve to "util/vector", in the normal cases.

No configuration files or separate data-base needed: The file-system
hierarchy is the library data-base.

Note in my proposal you don't really need the <lib-path> to be specified
in the library form.  The <lib-path> is inferred from the file-name.
This is just like you don't have to specify a file's URL - it's just
there.  This makes the (library ...) form optional.
	--Per Bothner
per@xxxxxxxxxxx   http://per.bothner.com/