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/
