Re: QT4CG meeting 145 draft agenda, 9 December 2025

> > I currently have a gut feeling that many of the use cases could be
satisfied by a simple function such as
>   >
>   > generate-sequence($initial-state, $step)
>   >
>   > returning a sequence of states, where $step is a function that
computes the next state from the current state.
>
> This reminds me a lot of the proposal made by Reece two years ago [1].
Several interesting questions had been asked in this thread, for example if
"count(generate-> sequence(...))" would work, or, more generally, if the
function would introduce a new value type that has no fixed size.
>
> [1] https://github.com/qt4cg/qtspecs/issues/708


A few quick observations:


   1. The cited issue (#708) proposes that each value returned is an
   `item()`. And this excludes a value being a sequence. By definition, any
   value in a generator's yield can be a sequence. Thus no limitations and no
   sacrifices.
   2. This seems problematic: Passing around and mixing/processing
   different instances of different intermediate results of several
   generate-sequence() instructions. With Generators this is done naturally.
   And "all these functions" are the "mixers" that produce any imagined, and
   even unanticipated processing and result.


On Tue, Dec 9, 2025 at 10:36 AM Christian Grün <cg@basex.org> wrote:

> > I currently have a gut feeling that many of the use cases could be
> satisfied by a simple function such as
> >
> > generate-sequence($initial-state, $step)
> >
> > returning a sequence of states, where $step is a function that computes
> the next state from the current state.
>
> This reminds me a lot of the proposal made by Reece two years ago [1].
> Several interesting questions had been asked in this thread, for example if
> "count(generate-sequence(...))" would work, or, more generally, if the
> function would introduce a new value type that has no fixed size.
>
> [1] https://github.com/qt4cg/qtspecs/issues/708
>
>