|
put library <body> at top-level Per Bothner (30 Nov 2005 20:33 UTC)
|
||
|
(missing)
|
||
|
(missing)
|
||
|
(missing)
|
||
|
(missing)
|
||
|
Re: put library <body> at top-level
Per Bothner
(03 Dec 2005 16:16 UTC)
|
||
|
Re: put library <body> at top-level
Ray Blaak
(03 Dec 2005 16:17 UTC)
|
||
|
import suggestion
Ray Blaak
(03 Dec 2005 16:17 UTC)
|
||
|
Re: put library <body> at top-level
Matthew Flatt
(30 Nov 2005 22:20 UTC)
|
||
|
Re: put library <body> at top-level
Per Bothner
(30 Nov 2005 22:29 UTC)
|
||
|
Re: put library <body> at top-level
Bradd W. Szonye
(03 Dec 2005 16:16 UTC)
|
||
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
xxxxxx@bothner.com http://per.bothner.com/