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.
Per Bothner wrote: > 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> "Source code in files. How quaint. How 70's." (Kent Beck) R5RS doesn't supply much detail about constructs such as files and directories. They are implementation-specific, non-first-class constructs that are vaguely mapped to ports by section 6.6. Neither directories nor notions of file-system naming hierarchy are mentioned. Scheme code doesn't have to live anywhere in particular - it can be sourced from anywhere, from files, from stdin, from an email message, from a database - the only constraint on scheme code is that it is an S-expression. List syntax is already suitable for sequencing S-expressions within an S-expression. Files provide a second-class means of sequencing S-expressions. Recovering a complete list of S-expressions from a file requires some small-but-nonzero amount of work. A file is not always the best granularity for a library - sometimes many small libraries are best expressed in a single file, and sometimes a single library is best expressed in multiple files. The scoping of the |library| form can be unclear if forms /following/ the declaration are to be considered part of the library: (library "mylib" "scheme://r6rs") (define library (compose write list)) (library "otherlib" "scheme://r6rs") (define number 17) Regards, Tony