Re: markup->string

[David Kastrup]

Jean Abou Samra <jean@abou-samra.fr> writes:

> Le 15/11/2022 à 14:43, David Kastrup a écrit :
>> If it's "mundane", why would the conversion result in a complex
>> replacement?
>
>
>
> Have you looked at the replacement?
>
> It is
>
> (lambda* (m #:optional headers)
>   (if headers
>       (markup->string m #:props (headers-property-alist-chain headers))
>       (markup->string m))
>
> which is the only thing convert-ly can programmatically
> replace markup->string with to make the change equivalent to
>
> (markup->string x) -> (markup->string x)     [no change]
> (markup->string x headers) -> (markup->string x #:props
> (headers-property-alist-chain headers))

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).

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).

> 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).  If you
are talking about computer-readable complexity, lambda* is a huge beast.
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.

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.

-- 
David Kastrup