|
From: | Bertalan Fodor (LilyPondTool) |
Subject: | Re: Policy about SRFI usage? |
Date: | Mon, 09 Nov 2009 16:41:00 +0100 |
User-agent: | Thunderbird 2.0.0.23 (Windows/20090812) |
David Kastrup wrote:
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."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? 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 |
[Prev in Thread] | Current Thread | [Next in Thread] |