New library-search feature for scsh -- comments requested 
Author Message
 New library-search feature for scsh -- comments requested

I'm adding a new feature to scsh to support scripting, and I'd really
appreciate feedback -- now is the time to get it right, before it's
released out into the world.

There's a long-standing problem with scripting in scsh that I'd like to fix
for scripts that need to load modules. In scsh, you can cause a script to load
in a file of code for a module by using the the
    -lm <module-file>
switch on the command line (on the #! trigger line). But this requires you to
specify *too much* information, actually: you have to give the *complete* file
name, which is simply handed to LOAD. This turns out, in practice, to be a
real pain, because the system libraries may live in different directories
on different systems.

What you'd like to do, really, is say something like "look around for the
module file geometric-utils.scm, and load it in." That is, you'd like a
search path for the loader to go find libraries in some standard set of
library directories... where the definition of that "standard set" might
vary from installation to installation, or user to user.

Now, a really solid solution to this issue is going to need a real
redesign of the module loading system, which has to come from the S48
folks. But I am going to propose an interim fix for scsh users.

I am planning to add some new switches to the command-line parser.
    -ll <module-file-name>
        Load library module into config package.
        This is just like the -lm switch, except that it searches the
        library-directory path list for the file to load.

        Specifically, it means: search through the LIBRARY-DIRECTORIES list of
        directories looking for a module file of the given name, and load it

        The LIBRARY-DIRECTORIES list defaults to an installation-specific
        value, which is typically

        If the environment variable $SCSH_LIB_DIRS is set, it is used
        to determine the library search path. The value of this environment
        variable treated as a sequence of s-expressions, which are "read"
        from the string.

             - A string is treated as a directory.

             - #F is replaced with the default list
               of directories.

        A SCSH_LIB_DIRS assignment of this form
          SCSH_LIB_DIRS='"." "/usr/contrib/lib/scsh/" #f "/home/shivers/lib/scsh"'
        would produce this list of strings for the LIBRARY-DIRECTORIES list:
          ("." "/usr/contrib/lib/scsh/"

        Here is a sample bit of bash code that will add a subdir from
        your home and project directories to the default list:

          SCSH_LIB_DIRS="\"$HOME/lib/scsh\" \"/usr/project/lib/scsh\" #f"

        Notice we had to backquote each string's double-quotes for bash.
        Let's add the scsh process' current working directory to that list:

          SCSH_LIB_DIRS="\".\" $SCSH_LIB_DIRS"

        [One might consider allowing symbols as well as strings. The problem
        is that this requires knowing how the reader deals with case when
        reading symbols. Scsh's reader is case-preserving; R5RS's reader is
        case-folding. I try to minimise scsh' *dependence* on case-preserving
        symbol reading; the process notation is currently the only place where
        it ever really matters.

        The advantage is that setting the environment variable in bash
        .profile or other init files becomes easier. The above example
            SCSH_LIB_DIRS="$HOME/lib/scsh /usr/project/lib/scsh #f"
        The backquoted-double-quotes go away, which is nicer.]

        When searching for a directory containing a given library module,
        nonexistent or read-protected directories are silently ignored;
        it is not an error to have them in the LIBRARY-DIRECTORIES list.

        It *is* a startup error if reading the $SCSH_LIB_DIRS env var causes
        a read error, or produces a value that isn't a string or #f.
        E.g., these are values of $SCSH_LIB_DIRS that will blow up scsh:
              SCSH_LIB_DIRS="3.14 foo (3)"    [Bogus values]
              SCSH_LIB_DIRS="\"/usr/lib/scsh"    [read error -- no close-quote]
              SCSH_LIB_DIRS="."               [read error -- illegal sexp]

        Directory search can be recursive. A directory name that ends
        with a slash is recursively searched. So this list
                  ("/usr/local/lib/scsh/modules/" "/home/shivers/lib/scsh")
            1. First search /usr/local/lib/scsh/modules and all its
            2. Then search /home/shivers/lib/scsh *non*-recursively.
        Recursive search is depth-first, with directories ordered by the
        Unix directory ordering, that is, the order in which ls(1) prints
        out directories: ASCII alphabetical/lexicographical (which places
        capitalised filenames before lower-case filenames), but dot files
        sort before non-dot files.

     +lp <lib-dir>
     lp+ <lib-dir>
         Add directory <lib-dir> to the beginning or end of the
         LIBRARY-DIRECTORIES path list, respectively.

         <lib-dir> is a *single* directory. It is not split at colons or
         otherwise processed.

         As above, except that ~ home-directory syntax and environment
         variables are expanded out.

        Set the LIBRARY-DIRECTORIES path list to the empty list and the system
        default, respectively.

        These two switches are useful if you would like to protect
        your script from influence by the $SCSH_LIB_PATH variable.

        In these cases, the SCSH_LIB_PATH environment variable is never
        even parsed, so a bogus value will not affect the script's
        execution at all.

These switches and the $SCSH_LIB_PATH environment variable allow you to dump
useful modules into a central repository in, say /usr/local or your home
directory; your scripts can easily access them from these places.

As a design note, one might consider encoding the $SCSH_LIB_PATH variable in a
more tradtional Unix way, as a colon-delimited path list. There are some
problems with this approach, that would require us to "patch" the standard
Unix technique:
    - Directories containing colons in them are not allowed -- which
      is a problem, as /usr/foo:bar is a perfectly legal Unix file name.
      We would need to make backslash a special quoting character to
      handle this.

    - Unix path lists usually use colon to *separate* file names,
      not to *terminate* filenames. This is ambiguous in the empty-string
      case. Is the empty string the empty list, or the singleton list
      of the empty string -- i.e. does it parse as path list () or ("")?

      We can patch this by going with a non-conventional colon-terminator
      grammar for the path list encoding.

    - We need a way to encode the system default path list.
      We could adopt the TeX convention of using the empty string
      to signify this. But this means we can't use empty string
      as the root directory. We could either accept this limitation,
      or change our slash-terminator-means-recursion convention to
      a double-slash-terminator-means-recursion convention. Now we
      can use "/" for the root directory, and empty string becomes
With these three patches -- which give us a system rather different from
the standard (broken) Unix convention, we have something workable. This
strikes me as being neither fish nor fowl. If you are going to break with
convention, you might as well do something that makes it clear you have
departed from the standard method.

But I'm interested to hear people's opinions.

I am going to hack this into the development sources. As I said, I'd like to
hear from people what they think of the particulars of this design -- comments
or suggestions or criticisms would be greatly appreciated.


Sat, 13 Apr 2002 03:00:00 GMT  
 [ 1 post ] 

 Relevant Pages 

1. Comments requested on F95 deleted/obsoleted features list

2. Bang Comments Feature Request

3. Bang Comment Feature Request

4. Request for comments: Search and replace script

5. exec path searching (feature request)

6. 4th and final posting : List of new features requested by the Clarion community

7. New -for- loop construct [long, revision 2, request for comments]

8. Request for Comments: A new n-ary function construction

9. new Perl feature request: call into shared libs

10. New Feature Request: Pass the results of thel

11. New Feature Request: Compression in Tcl-DP???

12. new pd oop library site request


Powered by phpBB® Forum Software