[Top][All Lists]

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

Re: Wish/suggestion: \import statement

From: Urs Liska
Subject: Re: Wish/suggestion: \import statement
Date: Fri, 07 Nov 2014 17:45:25 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

Am 07.11.2014 12:31, schrieb David Kastrup:
Urs Liska <address@hidden> writes:

\import harmonic-analysis
would load everything at once (I'd even suggest this command working
with symbolic names and not filenames).

\importFrom harmonic-analysis #'(pitch-class riemann)
would only load the two submodules.
(The submodule would have to \import the main module if it depends on
code in it).

What do you think?
The latter is a complication we can do without in my book.  What we need
is to drag the concept of modules into LilyPond, and those mostly
determine name spaces rather than loaded files.  I don't think we need
submodules: the GUILE module system allows autoloading files
conditionally when a symbol gets referenced:

  -- syntax: define-module module-name option …
      MODULE-NAME is a list of one or more symbols.

           (define-module (ice-9 popen))

      ‘define-module’ makes this module available to Guile programs under
      the given MODULE-NAME.

      OPTION … are keyword/value pairs which specify more about the
      defined module.  The recognized options and their meaning are shown
      in the following table.

      ‘#:use-module INTERFACE-SPECIFICATION’
           Equivalent to a ‘(use-modules INTERFACE-SPECIFICATION)’ (*note
           Using Guile Modules::).

      ‘#:autoload MODULE SYMBOL-LIST’
           Load MODULE when any of SYMBOL-LIST are accessed.  For

                (define-module (my mod)
                  #:autoload (srfi srfi-1) (partition delete-duplicates))
                (if something
                    (set! foo (delete-duplicates ...)))

           When a module is autoloaded, all its bindings become
           available.  SYMBOL-LIST is just those that will first trigger
           the load.

           An autoload is a good way to put off loading a big module
           until it’s really needed, for instance for faster startup or
           if it will only be needed in certain circumstances.

           address@hidden can do a similar thing (*note Using Guile Modules::), 
           in that case an address@hidden form must be written every time a 
           from the module is used.


So loading the module should just imply providing all the interfaces and
functions.  Loading the actual code can be done on-demand in case some
library covers more obscore use cases in separate files.

OK, if I really understand that it would perfectly match my idea of conditional loading (although through a different path).

> What we need is to drag the concept of modules into LilyPond,

What do you mean by this?
Do you suggest to implement a module approach that is somewhat parallel to Scheme's use-module approach?
Or rather try to "package" a module approach in Scheme modules somehow?
My impression is that defining and loading modules should be simpler than defining (and to some extent using) Scheme modules. At least there should be some syntactic sugar so one can use a "\" command to import a library.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]