Re: reduce unbound within \context lambda

[David Kastrup]

Aaron Hill <address@hidden> writes:

> %%%%
> \version "2.19.82"
> \paper {
>   #(use-modules (srfi srfi-1))
>   #(display (map + '(1 2 3) '(1 2 3 4)))
> }
> %%%%
>
> ====
> GNU LilyPond 2.19.82
> Processing `map-srfi-1.ly'
> Parsing...WARNING: #f: `break' imported from both #f and (srfi srfi-1)
> (2 4 6)
> Success: compilation successfully completed
> ====
>
> Nope.  I don't like the look of that warning.  :-/

break exists too often for its own good.  Guile already has two (cf the
last paragraph):

-- Scheme Procedure: span pred lst
 -- Scheme Procedure: span! pred lst
 -- Scheme Procedure: break pred lst
 -- Scheme Procedure: break! pred lst
     ‘span’ splits the list LST into the longest initial prefix whose
     elements all satisfy the predicate PRED, and the remaining tail.
     ‘break’ inverts the sense of the predicate.

     ‘span!’ and ‘break!’ are allowed, but not required to modify the
     structure of the input list LST in order to produce the result.

     Note that the name ‘break’ conflicts with the ‘break’ binding
     established by ‘while’ (*note while do::).  Applications wanting to
     use ‘break’ from within a ‘while’ loop will need to make a new
     define under a different name.

and LilyPond has another one.  I think it is a reasonable expectation
that the default imports into LilyPond are also available in the modules
of output blocks.  The setup of those is a pretty murky area: I was not
even aware that this is not the case.  On the other hand, an
unconditional reexport seems like it would limit what we can hope to
achieve when using the module system for separating functionality in
future extension/modularization of LilyPond.

-- 
David Kastrup