Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(1302)

Issue 577720043: Define Scheme markups using define-public

Can't Edit
Can't Publish+Mail
Start Review
Created:
4 years ago by hanwenn
Modified:
3 years, 11 months ago
Reviewers:
dak
CC:
lilypond-devel_gnu.org
Visibility:
Public.

Description

GUILE2: Introduce define-markup-command-[list-]compilable This variant of define-markup-command[-list] generates define-public expressions, making the result compilable. For compatiblity, the existing define-markup-command (which uses module-define) is retained.

Patch Set 1 #

Patch Set 2 : retain existing #

Unified diffs Side-by-side diffs Delta from patch set Stats (+193 lines, -150 lines) Patch
M scm/accreg.scm View 1 1 chunk +1 line, -1 line 0 comments Download
M scm/define-markup-commands.scm View 1 144 chunks +144 lines, -144 lines 0 comments Download
M scm/markup-macros.scm View 1 3 chunks +46 lines, -3 lines 0 comments Download
M scm/tablature.scm View 1 1 chunk +1 line, -1 line 0 comments Download
M scm/time-signature-settings.scm View 1 1 chunk +1 line, -1 line 0 comments Download

Messages

Total messages: 11
dak
Retaining define-markup-command-internal in order to allow defining markups in LilyPond syntax in a manner that ...
4 years ago (2020-03-29 00:35:02 UTC) #1
dak
On 2020/03/29 00:35:02, dak wrote: > Retaining define-markup-command-internal in order to allow defining markups in ...
4 years ago (2020-03-29 00:37:53 UTC) #2
hanwenn
retain existing
3 years, 12 months ago (2020-03-29 13:52:48 UTC) #3
hanwenn
On 2020/03/29 13:52:48, hanwenn wrote: > retain existing how's this? This leaves things backward compatible. ...
3 years, 12 months ago (2020-03-29 13:55:41 UTC) #4
dak
On 2020/03/29 13:55:41, hanwenn wrote: > On 2020/03/29 13:52:48, hanwenn wrote: > > retain existing ...
3 years, 12 months ago (2020-03-29 14:03:55 UTC) #5
dak
On 2020/03/29 13:55:41, hanwenn wrote: > On 2020/03/29 13:52:48, hanwenn wrote: > > retain existing ...
3 years, 12 months ago (2020-03-29 14:12:42 UTC) #6
hanwenn
On Sun, Mar 29, 2020 at 4:12 PM <dak@gnu.org> wrote: > > On 2020/03/29 13:55:41, ...
3 years, 12 months ago (2020-03-29 14:35:43 UTC) #7
dak
On 2020/03/29 14:35:43, hanwenn wrote: > On Sun, Mar 29, 2020 at 4:12 PM <mailto:dak@gnu.org> ...
3 years, 12 months ago (2020-03-30 12:20:17 UTC) #8
hanwenn
On 2020/03/30 12:20:17, dak wrote: > On 2020/03/29 14:35:43, hanwenn wrote: > > On Sun, ...
3 years, 12 months ago (2020-03-30 21:18:17 UTC) #9
hanwenn
On 2020/03/30 12:20:17, dak wrote: > > > Ugly and a maintenance burden since the ...
3 years, 11 months ago (2020-04-12 10:59:21 UTC) #10
dak
3 years, 11 months ago (2020-04-12 11:22:24 UTC) #11
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.
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b