Re: Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

[dak]

On 2020/04/12 10:59:21, hanwenn wrote:
> On 2020/03/30 12:20:17, dak wrote:
> > > > Ugly and a maintenance burden since the code is used twice. 
Anything
> > > > wrong with my proposal?
> > > 
> > > I didn't understand your proposal.
> > > 
> > > > It does not have duplicate code, makes
> > > > define-markup-command compilable (while requiring its toplevel
use) and
> > > > provides a way of doing the same consistently for
module-specific rather
> > > > than toplevel use.
> > > >
> > > > It sacrifices, like your proposal, non-toplevel-performance for
the sake
> > > > of compilability in Guilev2.  It's just that what the parser
then uses
> > > > is in a form that could also be used in a reasonably natural
manner from
> > > > Scheme.
> > > >
> > > > Should I write up a patch doing that?
> > > 
> > > Yes please.
> > > 
> > 
> > Working on it.  
> 
> Any update?

Sorry, got lost among other stuff.  I have something working in a branch
which I'll rebase and upload presently.  It illustrates the point I was
trying to make though I'll have to admit that this looked more
worthwhile "on paper" so far: I am still not all too clear about how
this would help with the byte compilation situation even though it
cleans up the current situation.  Also, making the call of
(current-module) explicit may help in finding a macro invocation that
delays the actual call until it can actually work.

Also it is more of a sketch, and since the sketch was about
define-markup-command, it starts out reverting your union of
define-markup-command and define-markup-command-list.  Since there is
not much of a point in having different implementations for either, this
is of course something that ultimately needs addressing.

So in short, it's not ready for submission in the current form, but it
certainly spells out what I tried expressing in the above comment.  Even
though I am still fuzzy about whether it will be more helpful in finding
a solution for the byte compilation.

https://codereview.appspot.com/577720043/

Re: Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

[hanwenn]

On 2020/03/30 12:20:17, dak wrote:
> > > Ugly and a maintenance burden since the code is used twice. 
Anything
> > > wrong with my proposal?
> > 
> > I didn't understand your proposal.
> > 
> > > It does not have duplicate code, makes
> > > define-markup-command compilable (while requiring its toplevel
use) and
> > > provides a way of doing the same consistently for module-specific
rather
> > > than toplevel use.
> > >
> > > It sacrifices, like your proposal, non-toplevel-performance for
the sake
> > > of compilability in Guilev2.  It's just that what the parser then
uses
> > > is in a form that could also be used in a reasonably natural
manner from
> > > Scheme.
> > >
> > > Should I write up a patch doing that?
> > 
> > Yes please.
> > 
> 
> Working on it.  

Any update?

https://codereview.appspot.com/577720043/

Re: Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

[hanwenn]

On 2020/03/30 12:20:17, dak wrote:
> On 2020/03/29 14:35:43, hanwenn wrote:
> > On Sun, Mar 29, 2020 at 4:12 PM  wrote:
> > >
> > > On 2020/03/29 13:55:41, hanwenn wrote:
> > > > On 2020/03/29 13:52:48, hanwenn wrote:
> > > > > retain existing
> > > >
> > > > how's this? This leaves things backward compatible.
> > >
> > > Ugly and a maintenance burden since the code is used twice. 
Anything
> > > wrong with my proposal?
> > 
> > I didn't understand your proposal.
> > 
> > > It does not have duplicate code, makes
> > > define-markup-command compilable (while requiring its toplevel
use) and
> > > provides a way of doing the same consistently for module-specific
rather
> > > than toplevel use.
> > >
> > > It sacrifices, like your proposal, non-toplevel-performance for
the sake
> > > of compilability in Guilev2.  It's just that what the parser then
uses
> > > is in a form that could also be used in a reasonably natural
manner from
> > > Scheme.
> > >
> > > Should I write up a patch doing that?
> > 
> > Yes please.
> > 
> 
> Working on it.  By the way, it just occured to me that a whole lot of
trouble
> with byte-compilation is caused by the markup macro.

Yes, it was the next thing I wanted to look at, but you beat me to the
punch.


https://codereview.appspot.com/577720043/

Re: Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

[dak]

On 2020/03/29 14:35:43, hanwenn wrote:
> On Sun, Mar 29, 2020 at 4:12 PM  wrote:
> >
> > On 2020/03/29 13:55:41, hanwenn wrote:
> > > On 2020/03/29 13:52:48, hanwenn wrote:
> > > > retain existing
> > >
> > > how's this? This leaves things backward compatible.
> >
> > Ugly and a maintenance burden since the code is used twice. 
Anything
> > wrong with my proposal?
> 
> I didn't understand your proposal.
> 
> > It does not have duplicate code, makes
> > define-markup-command compilable (while requiring its toplevel use)
and
> > provides a way of doing the same consistently for module-specific
rather
> > than toplevel use.
> >
> > It sacrifices, like your proposal, non-toplevel-performance for the
sake
> > of compilability in Guilev2.  It's just that what the parser then
uses
> > is in a form that could also be used in a reasonably natural manner
from
> > Scheme.
> >
> > Should I write up a patch doing that?
> 
> Yes please.
> 

Working on it.  By the way, it just occured to me that a whole lot of
trouble with byte-compilation is caused by the markup macro.

git grep '(macro\($| \)' scm |wc -l

counts 65 occurences.  Those could certainly be replaced with
make-...-markup functions without causing too much trouble, leaving the
markup macro as only a user-level "feature".  That should significantly
cut down on our problems, right?  The markup macro framework appears to
be one of the worst corners for byte-compilation.

The performance loss due to run-time argument checking instead of
compile-time argument checking (which is likely the motivation for the
markup macro design) is likely insignificant compared to the cost of
actually typesetting markup.

https://codereview.appspot.com/577720043/

Re: Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

[Han-Wen Nienhuys]

On Sun, Mar 29, 2020 at 4:12 PM  wrote:
>
> On 2020/03/29 13:55:41, hanwenn wrote:
> > On 2020/03/29 13:52:48, hanwenn wrote:
> > > retain existing
> >
> > how's this? This leaves things backward compatible.
>
> Ugly and a maintenance burden since the code is used twice.  Anything
> wrong with my proposal?

I didn't understand your proposal.

> It does not have duplicate code, makes
> define-markup-command compilable (while requiring its toplevel use) and
> provides a way of doing the same consistently for module-specific rather
> than toplevel use.
>
> It sacrifices, like your proposal, non-toplevel-performance for the sake
> of compilability in Guilev2.  It's just that what the parser then uses
> is in a form that could also be used in a reasonably natural manner from
> Scheme.
>
> Should I write up a patch doing that?

Yes please.

>
> https://codereview.appspot.com/577720043/



-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

[dak]

On 2020/03/29 13:55:41, hanwenn wrote:
> On 2020/03/29 13:52:48, hanwenn wrote:
> > retain existing
> 
> how's this? This leaves things backward compatible.

Ugly and a maintenance burden since the code is used twice.  Anything
wrong with my proposal?  It does not have duplicate code, makes
define-markup-command compilable (while requiring its toplevel use) and
provides a way of doing the same consistently for module-specific rather
than toplevel use.

It sacrifices, like your proposal, non-toplevel-performance for the sake
of compilability in Guilev2.  It's just that what the parser then uses
is in a form that could also be used in a reasonably natural manner from
Scheme.

Should I write up a patch doing that?

https://codereview.appspot.com/577720043/

Re: Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

[dak]

On 2020/03/29 13:55:41, hanwenn wrote:
> On 2020/03/29 13:52:48, hanwenn wrote:
> > retain existing
> 
> how's this? This leaves things backward compatible.
> 
> Note that we're currently incoherent, because you can't do 
> 
>  (let ((n 0)) (define sym val))

"incoherent" means in conflict with oneself.

> so coherency is probably not a great argument for keeping things as
is.

You can do

(define sym (let ((n 0)) val))

however.  Including replacing val inline with a lambda expression making
use of a lexical capture of n.

You can also do
(define sym #f)
(let ((n 0)) (set! sym (lambda () ... n ...))

There is also letrec and various other things, all of which we don't
have available for the somewhat complex semantics of actually defining a
named markup function.

https://codereview.appspot.com/577720043/

Re: Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

[hanwenn]

On 2020/03/29 13:52:48, hanwenn wrote:
> retain existing

how's this? This leaves things backward compatible.

Note that we're currently incoherent, because you can't do 

 (let ((n 0)) (define sym val))

so coherency is probably not a great argument for keeping things as is.


https://codereview.appspot.com/577720043/

Re: Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

[dak]

On 2020/03/29 00:35:02, dak wrote:
> Retaining define-markup-command-internal in order to allow defining
markups in
> LilyPond syntax in a manner that stops being supported from Scheme
seems like
> incoherent design.
> 
> markup-lambdas can be created from within LilyPond using \markup ...
\etc . 
> Having them unusable from Scheme for the purpose of defining a markup
function
> seems inappropriate.
> 
> If unsupporting the functionality via define-markup-command is
desirable (which
> I am not convinced of) or independently, it would seem that a more
> regular/prominent module-define-markup-command! with appropriate
semantics would
> be warranted (and used from the parser) instead of retaining
> define-markup-command-internal as a non-internal of
define-markup-command.

By the way: that would also provide at least a workable way of making
input/regression/pattern-markup-evaluation.ly work again without
requiring a global definition of n .

https://codereview.appspot.com/577720043/

Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

[dak]

Retaining define-markup-command-internal in order to allow defining
markups in LilyPond syntax in a manner that stops being supported from
Scheme seems like incoherent design.

markup-lambdas can be created from within LilyPond using \markup ...
\etc .  Having them unusable from Scheme for the purpose of defining a
markup function seems inappropriate.

If unsupporting the functionality via define-markup-command is desirable
(which I am not convinced of) or independently, it would seem that a
more regular/prominent module-define-markup-command! with appropriate
semantics would be warranted (and used from the parser) instead of
retaining define-markup-command-internal as a non-internal of
define-markup-command.

https://codereview.appspot.com/577720043/