lilypond-devel
[Top][All Lists]
Advanced

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

Re: Wish/suggestion: \import statement


From: David Kastrup
Subject: Re: Wish/suggestion: \import statement
Date: Fri, 07 Nov 2014 12:31:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

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
          example,

               (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::), 
but
          in that case an address@hidden form must be written every time a 
binding
          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.

-- 
David Kastrup



reply via email to

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