Re: [xsl] Is it possible to write an XSLT program that outputs an XSLT program that outputs an XSLT program?

Subject: Re: [xsl] Is it possible to write an XSLT program that outputs an XSLT program that outputs an XSLT program?
From: "Dimitre Novatchev dnovatchev@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 2 Jul 2023 20:07:20 -0000
> This week I got to wondering: is it possible to write an XSLT program
that outputs an XSLT program
> and when the latter is run it outputs another XSLT program? That is,
>
> XSLT program #1 --> run --> outputs XSLT program #2 --> run --> outputs
XSLT program #3 --> run --> solves some problem
>
> Is this even possible in XSLT? Have you ever done this? What types of
problems are suitable for this approach?


It is possible, but is it needed? Or, as some people in the XSLT/XPath 4 CG
ask all the time: "Any use-cases, please?"

If the XSLT transformation to be produced is always the same (doesn't vary)
we do not need any generator for it -- just have it in a file.

If the XSLT transformation to be produced can be different depending on
different values of specific parameters, and if we want the final XSLT
transformation to be simple (not contain logic that handles these
parameters, but be a "projection" of the parameter values) then any such
"projections" of the unified/complex solution are produced by the so called
"XSLT generator".

The complete achievement is less complex, that is the generator +
produced-result is simpler (requires less resources, and the final result
is more easy to understand and maintain) than the all-in one single,
encompassing solution.

If we have achieved the desired simplicity, then we won't need to further
simplify the solution, thus no need to introduce a new Generator that will
produce different Final Generators. And if we do this (add a GeneratorN
producing GeneratorN-1), it may be argued that instead of simplifying, we
are introducing additional, unnecessary complexity, by increasing the
number of generation levels.

This is why we will probably never see a 3D printer that "prints" another
3D printer... This won't be more cost-efficient than simply buying another
one (and may require additional special knowledge and maintenance), or the
cost of the "more-sophisticated" printer-producing printer will be higher
than just buying two ordinary 3D printers.

Thanks,
Dimitre


On Sun, Jul 2, 2023 at 3:58b/AM Roger L Costello costello@xxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Hi Folks,
>
> Years ago I read the source code for the XSLT implementation of
> Schematron. From it I learned how to write an XSLT program that outputs an
> XSLT program. Since that time I have written a number of XSLT programs that
> output XSLT programs. I enjoy writing these kinds of programs. They seem
> almost magical. A program that produces a program - wow!
>
> This week I got to wondering: is it possible to write an XSLT program that
> outputs an XSLT program and when the latter is run it outputs another XSLT
> program? That is,
>
> XSLT program #1 --> run --> outputs XSLT program #2 --> run --> outputs
> XSLT program #3 --> run --> solves some problem
>
> Is this even possible in XSLT? Have you ever done this? What types of
> problems are suitable for this approach?
>
> /Roger

Current Thread