David Kastrup d...@gnu.org writes:
Now here is one thing worth considering: currently the predicate scheme?
is defined as
(define-public (scheme? x) #t)
I lean towards defining it instead as
(define-public (scheme? x) (not (eq? x (begin
so that it will accept anything _except_ void
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
It might make sense to introduce a syntax change like that in two
stages: in the first stage, one just complains about embedded Scheme
that could be mistaken for something useful. Only in the second
stage, one does not
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
Graham Percival gra...@percival-music.ca writes:
What happens if somebody writes
{ \with fooc4 \with bard4 }
?
Good catch. I don't think we want anything but a syntax error here.
One approach would be
David Kastrup d...@gnu.org writes:
For a first test, I made Lilypond barf on everything non-unspecified. I
did not get through with make all mostly because of several instances
of module-define! which chooses to return a boolean. What a nuisance.
I changed the error condition such that
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
It might make sense to introduce a syntax change like that in two
stages: in the first stage, one just complains about embedded Scheme
that could be mistaken for something useful. Only in the second
stage, one does not
Hi,
I am currently trying to make music functions more powerful, in
particular their argument predicates. Also I am trying to relieve the
parser from responsibilities.
Now I have a possibly slightly contentious change... I want to let { }
mimic the new functionality of #{ #} instead of
On Wed, Oct 12, 2011 at 05:42:47PM +0200, David Kastrup wrote:
I am currently trying to make music functions more powerful, in
particular their argument predicates. Also I am trying to relieve the
parser from responsibilities.
Looks basically good to me. GLISS was never planned to tackle
Graham Percival gra...@percival-music.ca writes:
On Wed, Oct 12, 2011 at 05:42:47PM +0200, David Kastrup wrote:
I am currently trying to make music functions more powerful, in
particular their argument predicates. Also I am trying to relieve the
parser from responsibilities.
Looks
What about { b' { c'' } \\ { a' } d'' } ?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Graham Percival gra...@percival-music.ca writes:
On Wed, Oct 12, 2011 at 05:42:47PM +0200, David Kastrup wrote:
I am currently trying to make music functions more powerful, in
particular their argument predicates. Also I am trying to relieve the
parser from responsibilities.
Looks
Bertrand Bordage bordage.bertr...@gmail.com writes:
What about { b' { c'' } \\ { a' } d'' } ?
Is there a reason this could be interpreted any different from
currently? c'' and a' might not individually be wrapped in
sequential-music, but that would not affect the interpretation, would
it?
On Wed, Oct 12, 2011 at 06:19:09PM +0200, David Kastrup wrote:
Graham Percival gra...@percival-music.ca writes:
What happens if somebody writes
{ \with fooc4 \with bard4 }
?
Good catch. I don't think we want anything but a syntax error here.
One approach would be not to
Graham Percival gra...@percival-music.ca writes:
On Wed, Oct 12, 2011 at 06:19:09PM +0200, David Kastrup wrote:
Graham Percival gra...@percival-music.ca writes:
What happens if somebody writes
{ \with fooc4 \with bard4 }
?
Good catch. I don't think we want anything but
David Kastrup d...@gnu.org writes:
Graham Percival gra...@percival-music.ca writes:
What happens if somebody writes
{ \with fooc4 \with bard4 }
?
Good catch. I don't think we want anything but a syntax error here.
One approach would be not to ignore Scheme expressions in a
14 matches
Mail list logo
