Jean Abou Samra <j...@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
