[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: reduce unbound within \context lambda
From: |
David Kastrup |
Subject: |
Re: reduce unbound within \context lambda |
Date: |
Sat, 02 Mar 2019 16:09:51 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
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