[Top][All Lists]

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

Re: markup->string

From: Jean Abou Samra
Subject: Re: markup->string
Date: Tue, 15 Nov 2022 16:09:00 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1

Le 15/11/2022 à 15:18, David Kastrup a écrit :
Conversion rules can look at the number of arguments and only revert to
a generic replacement when the number of arguments cannot be determined
(like when the arguments are too complex for the patterns, or
markup-string is not used as a call but as a function).

Yes. That is what !1732 does (with a simple pattern).

Even then, the generic call can be given a name like
headers-markup->string or markup->string can get a #:rest argument that
will get interpreted in the old manner when there are no optional
arguments (in order to encourage only the new syntax but maintain
backward compatibility) or generally (though this would further
proliferation of the old syntax).

I scanned the 91 results of

and did not find a single call to markup->string with
the optional argument.

I think it is of little importance to keep the previous syntax

The "complexity" we are talking about is the length of the output of
convert-ly relative to the input. There is no complex logic at all.
If you are talking about human-readable complexity, for the average user
this is eyes-glaze-over material in most contexts (the average user does
not even know lambda* and it is not a core Scheme construct).

At this point, everybody agrees that the lambda* replacement
was a bad idea. The current debate is between (1) a simple
warning in convert-ly, without automated replacement, and (2)
a new optional/keyword argument to markup->string or a new function.

If you are talking about computer-readable complexity, lambda* is a huge beast.

See above.

If you are talking about conceptual complexity,
headers-property-alist-chain depends on internal data structure details
for the conversion of headers to a property-alist-chain.

What "internal data structure details"?

Since the interface now does optional argument processing, there is no
point in not having

markup->string x #:headers headers

at the very least in order to obviate the knowledge of internal
processing at the call point.

And this is the kind of conversion call that convert-ly should aim for.

See the question above.

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

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