Re: Policy about SRFI usage?
On Thu, Nov 5, 2009 at 12:48 PM, David Kastrup d...@gnu.org wrote: Hi, 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. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Policy about SRFI usage?
I would add: make Scheme code as portable as possible. Han-Wen Nienhuys wrote: On Thu, Nov 5, 2009 at 12:48 PM, David Kastrup d...@gnu.org wrote: Hi, 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. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Policy about SRFI usage?
Bertalan Fodor (LilyPondTool) lilypondt...@organum.hu writes: Han-Wen Nienhuys wrote: On Thu, Nov 5, 2009 at 12:48 PM, David Kastrup d...@gnu.org 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? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Policy about SRFI usage?
David Kastrup wrote: Bertalan Fodor (LilyPondTool) lilypondt...@organum.hu writes: Han-Wen Nienhuys wrote: On Thu, Nov 5, 2009 at 12:48 PM, David Kastrup d...@gnu.org 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
