Policy about SRFI usage?

On Thu, Nov 5, 2009 at 12:48 PM, David Kastrup dak@... 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.

"Bertalan Fodor (LilyPondTool)" lilypondtool@... writes:

Han-Wen Nienhuys wrote:

    On Thu, Nov 5, 2009 at 12:48 PM, David Kastrup dak@... 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?

	Policy about SRFI usage? by David Kastrup :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 vastly simplified (probably one order of magnitude) and sped up (probably two) using SRFI-13. The speedup is likely not all too important in this particular case. But less code to maintain is an advantage. And there may be other areas which profit more from the SRFI modules of guile. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@... http://lists.gnu.org/mailman/listinfo/lilypond-devel
	Re: Policy about SRFI usage? by Han-Wen Nienhuys-5 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Thu, Nov 5, 2009 at 12:48 PM, David Kastrup <dak@...> 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 - hanwen@... - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@... http://lists.gnu.org/mailman/listinfo/lilypond-devel
	Re: Policy about SRFI usage? by Bertalan Fodor (LilyPondTool) :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 dak@... 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@... http://lists.gnu.org/mailman/listinfo/lilypond-devel
	Re: Policy about SRFI usage? by David Kastrup :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message "Bertalan Fodor (LilyPondTool)" <lilypondtool@...> writes: >> Han-Wen Nienhuys wrote: >> >> On Thu, Nov 5, 2009 at 12:48 PM, David Kastrup <dak@...> 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@... http://lists.gnu.org/mailman/listinfo/lilypond-devel
	Re: Policy about SRFI usage? by Bertalan Fodor (LilyPondTool) :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message David Kastrup wrote: "Bertalan Fodor (LilyPondTool)" lilypondtool@... writes: Han-Wen Nienhuys wrote: On Thu, Nov 5, 2009 at 12:48 PM, David Kastrup dak@... 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@... http://lists.gnu.org/mailman/listinfo/lilypond-devel

Policy about SRFI usage?

Policy about SRFI usage?

Re: Policy about SRFI usage?

Re: Policy about SRFI usage?

Re: Policy about SRFI usage?

Re: Policy about SRFI usage?