[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Define Scheme markups using define-public (issue 577720043 by addres

From: dak
Subject: Re: Define Scheme markups using define-public (issue 577720043 by address@hidden)
Date: Mon, 30 Mar 2020 05:20:17 -0700

On 2020/03/29 14:35:43, hanwenn wrote:
> On Sun, Mar 29, 2020 at 4:12 PM <mailto:address@hidden> 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. 
> > 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)
> > provides a way of doing the same consistently for module-specific
> > than toplevel use.
> >
> > It sacrifices, like your proposal, non-toplevel-performance for the
> > of compilability in Guilev2.  It's just that what the parser then
> > is in a form that could also be used in a reasonably natural manner
> > 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]