Re: Policy about SRFI usage?

[Bertalan Fodor (LilyPondTool)]

David Kastrup wrote:

"Bertalan Fodor (LilyPondTool)" <address@hidden> writes:

  

Han-Wen Nienhuys wrote:

    On Thu, Nov 5, 2009 at 12:48 PM, David Kastrup <address@hidden> wrote:

        I was wondering what the Lilypond policies are for using
        SRFI, such as SRFI-13 for string functions.  My question was
        triggered by looking at scm/lily-sort.scm (only used at
        document creation time) which could be

    There are no specific policies, except that you have to be
    careful.  For example, there is a GUILE module that provides a
    format function, which also has enormous high rate of garbage
    generation; switching back to a hand-coded format cut memory
    usage in half.
      

I would add: make Scheme code as portable as possible.
    

Hm?  You mean, run on other interpreters rather than Guile?  If so, why?

  

Yes. For example I'm currently integrating the SISC Scheme interpreter into LilyPondTool to make instant error checking more correct. If there is much dependency on Guile-specific modules/code, my task is much harder, because I have to reimplement functionality.
In general, all code should be portable and maintainable, that is
- make sure code is tool-agnostic,
- make sure there are good tool support

That's why it would be a bad idea to adopt R6RS for LilyPond (no tools), and it is a bad idea to make LilyPond code GUILE-dependent (no life outside Guile).

Still, it is ok if the Guile modules used are implemented in pure R5RS - for example the module system is implemented using core R5RS features, so that can be safely used, still producing portable Scheme code.

Bert