Re: Historical trivia: who introduced into XSLT 1.0 the construct that enables XSLT to generate XSLT (i.e., XSLT's "code generation" capability)?

On Mon, 13 Jun. 2022, 05:13 C. M. Sperberg-McQueen, <
[email protected]> wrote:

>
 But 'makes more convenient' is not the same as 'enables'.
>

In general, no (I disagree): If we say that some steps enable access to a
doorway, that is fine until we consider people in a wheelchair: the steps
prevent access, they disable.  A ramp "makes more convenient", and in doing
so it enables. (As soon as humans are involved, we cannot assume that what
is not strictly needed for some is optional for all.)

Another example, high level languages have enabled us to code up things we
never could have if we were writing in assembler, despite assembler being
the most powerful, as a matter of practicality and finite resources.
(Without adequate modeling sugar we die of complications.)

Other examples: macros or classes or for-loops or symbolic variables or
other syntactic sugar, which are entirely "makes more convenient" but
without which many programs could not have been written and maintained, in
the real world.

(Also, would it go too far to suggest that equating "enables" with "can be
written" is bad engineering? "Can be read" and "can be maintained" need to
be part of the picture.)

In the case of XSLT, is the convenience gained by the alternative namespace
so thin that it has no incremental enabling benefit for humans, that no
project would fail (to be written, to be read, to be maintained) without
it? Quite possibly...

(I am aware that Michael is not writing in terms of software engineering,
but theoretical capability. So I am not disagreeing with him, just
equivocating.)

Regards
Rick

>