Re: markup->string

[Jean Abou Samra]

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

https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=markup-%3Estring&submit=Search%21&idxname=lilypond-user&max=20&result=normal&sort=date%3Alate

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



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

OpenPGP_signature
Description: OpenPGP digital signature