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

put library <body> at top-level

This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.



I don't see any rationale for:

(library <lib-path> <language>
     <body>)

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

(library <lib-path> <language>)
<body>

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/