Allow Scheme functions to be called inside of markup

Allow Scheme functions to be called inside of markup

[thomasmorley651, 2016-01-16 19:54:54]

After some testings I'm quite happy with it, apart from one use case:

fooII = 
#(define-scheme-function (arg)(markup-list?) 
#{ 
  \markup \column $arg 
#})

%% doesn't work:
\markup \line { "xy" \fooII { "does" "not" "work"} }
%% works
\markup \line { "xy" \fooII \markuplist { "whatever" "else" } }
\markup \line { "xy" \fooII #'("whatever" "else") }

I think I know why the first case doesn't work. Though, I have no good idea how
to explain it in the docs without telling a very technical story, likely very
confusing to the average-user.
Additionally, having to add \markuplist as in the second example is not nice.
Only a little better is the need to revert to scheme as done in the third
example.

What other problematic cases can you predict deductively?

[dak, 2016-01-16 20:37:23]

On 2016/01/16 19:54:54, thomasmorley651 wrote:
> After some testings I'm quite happy with it, apart from one use case:
> 
> fooII = 
> #(define-scheme-function (arg)(markup-list?) 
> #{ 
>   \markup \column $arg 
> #})
> 
> %% doesn't work:
> \markup \line { "xy" \fooII { "does" "not" "work"} }
> %% works
> \markup \line { "xy" \fooII \markuplist { "whatever" "else" } }
> \markup \line { "xy" \fooII #'("whatever" "else") }
> 
> I think I know why the first case doesn't work. Though, I have no good idea
how
> to explain it in the docs without telling a very technical story, likely very
> confusing to the average-user.
> Additionally, having to add \markuplist as in the second example is not nice.
> Only a little better is the need to revert to scheme as done in the third
> example.
> 
> What other problematic cases can you predict deductively?

Sigh.  This looks like a can of worms.

Arguments of type markup?/markup-list? will obviously be problematic (apart from
the trivial case of strings) without explicit \markup/\markuplist.  I am afraid
that one would need to teach markup-mode internal arguments to generic function
argument lists.  That would appear to be a likely user expectation.

However, `{' and `}' are mode-independent, and so { } already stands for an
empty sequential music expression and making it stand at the same time for an
empty markup list...  Ugh.

So much for the triviality of the change.

[thomasmorley651, 2016-01-16 21:19:08]

On 2016/01/16 20:37:23, dak wrote:
> On 2016/01/16 19:54:54, thomasmorley651 wrote:
> > After some testings I'm quite happy with it, apart from one use case:
> > 
> > fooII = 
> > #(define-scheme-function (arg)(markup-list?) 
> > #{ 
> >   \markup \column $arg 
> > #})
> > 
> > %% doesn't work:
> > \markup \line { "xy" \fooII { "does" "not" "work"} }
> > %% works
> > \markup \line { "xy" \fooII \markuplist { "whatever" "else" } }
> > \markup \line { "xy" \fooII #'("whatever" "else") }
> > 
> > I think I know why the first case doesn't work. Though, I have no good idea
> how
> > to explain it in the docs without telling a very technical story, likely
very
> > confusing to the average-user.
> > Additionally, having to add \markuplist as in the second example is not
nice.
> > Only a little better is the need to revert to scheme as done in the third
> > example.
> > 
> > What other problematic cases can you predict deductively?
> 
> Sigh.  This looks like a can of worms.
> 
> Arguments of type markup?/markup-list? will obviously be problematic (apart
from
> the trivial case of strings) without explicit \markup/\markuplist.  I am
afraid
> that one would need to teach markup-mode internal arguments to generic
function
> argument lists.  That would appear to be a likely user expectation.

Agreed. Users would be surprised to find the following not working:

fooVI = #(define-scheme-function (arg)(markup?) arg)
\markup \line { "xy" \fooVI \with-color #red "bla" }

> 
> However, `{' and `}' are mode-independent, and so { } already stands for an
> empty sequential music expression and making it stand at the same time for an
> empty markup list...  Ugh.
> 
> So much for the triviality of the change.

Well, it would be some syntactic sugar. No real need for it.
Bury it?