does any other scheme treat the names that way?
Chibi’s module handling is similar to Guile:
modules are searched for in a module load path. The definition of the
module (foo bar baz) is searched for in the file "foo/bar/baz.sld".
http://synthcode.com/scheme/chibi#h3_ModuleSystem
Chicken does not construct a path (but I didn’t delve into their
module system, and the rsr7 mapping to it, to understand what it does
instead):
Some implementations treat library name components as filesystem
paths and attempt to load the library (foo bar baz) from the file
"foo/bar/baz.scm", for example. This [r7rs] egg does not.
https://wiki.call-cc.org/eggref/5/r7rs#library-loading
Chez is similar to Guile and Chibi:
A library to be loaded implicitly via import must reside in a file
whose name reflects the name of the library. For example, if the
library's name is (tools sorting), the base name of the file must be
sorting with a valid extension, and the file must be in a directory
named tools which itself resides in one of the directories searched by
import.
https://cisco.github.io/ChezScheme/csug9.5/use.html#./use:h4
Happy to look at others if it would help guide this. Thanks as ever for
your continued fast responses!
Cheers, Michael
On 26 Jan 2022, at 3:31, [email protected] wrote:
On the guile library filename handling, does any other scheme
treat the names that way? I have added the rest of the built-in
libaries to r7rs.scm: eval, process-context, case-lambda, lazy,
load, and repl. s7 ignores these import statements.
(display "hi" (current-error-port))
works for me. It is the same as (display "hi" *stderr*); since
there is no buffering in this case, the flush-output-port has
no effect, unless someone has redirected stderr.
_______________________________________________
Cmdist mailing list
[email protected]
https://cm-mail.stanford.edu/mailman/listinfo/cmdist
_______________________________________________
Cmdist mailing list
[email protected]
https://cm-mail.stanford.edu/mailman/listinfo/cmdist
