Decker 1.32 focuses primarily on refining Lil and its query syntax.

Fixes (Web):

• The Lil "take" operator was yielding incorrect results when extending empty lists.

New Features:

• The app interface now includes "app.show[]" and "app.print[]" functions which behave exactly like their top-level counterparts "show[]" and "print[]", except they output to the standard output stream (stdout) instead of the Listener. These can be handy for debugging. In Web-Decker, output is sent to the JavaScript console instead of stdout.
• When enabled, the Script Profiler now displays a small histogram of recent activity instead of just an instantaneous bar:

• Lil now includes a product operator ("prod") which reduces a list by multiplying together each value. While a multiply-reduce is less useful than its cousins sum, raze, min, and max, it does occasionally come up in solutions to combinatorics problems.

Breaking Changes:

This release revises the behavior of several query constructs to make them more consistent and general.

Previously, the "except" query form would automatically return the first element of length-1 lists. While this behavior was convenient for some use-cases, it posed very annoying problems for others:

Previously, the "select", "extract", and "update" query forms accepted optional clauses in the order "where", "by", and "orderby", and would carry out queries by filtering ("where"), then grouping ("by"), and finally sorting ("orderby") as needed. Clauses could only appear once, and in that fixed order, so some queries might require two or more chained "subqueries".

This design has been revised to permit any number of repeated clauses, in any order. The clauses are now strictly carried out right-to-left, like Lil expressions in general.

The implicit "gindex" column previously referred to the indices of rows within groups formed by the "by" clause, which would be far less useful with a different order of clauses. Instead, the "gindex" column now always reflects the order of rows from the perspective of successive clauses, essentially being "range count" of the intermediate table. If the query has been grouped, each sub-table's rows have their own gindex column starting from 0. In other words, gindex 0 is always the first row within a given group.

The reference manual includes a more detailed discussion of the new behavior.

Migration:

The changes to "extract" have unfortunately impacted a variety of examples in the Contraption Bazaar; these will all be revised shortly. If you're already using an impacted Contraption, you can remove the prototype from the Resources dialog and then re-import the revised definition, but this may destroy data. An alternative is to open your ".deck" file in your favorite text editor and use the find and replace feature to change any instances of the phrase

 extract first arg where arg..type="image" from

in scripts with

 first extract arg where arg..type="image" from

In your own programs you may find the changes to extract make no difference, or require a similar "lifting" of operators like "first", "last", or "count" to before the "extract" keyword. If you used an idiom like "(),extract ..." to force extracted results to be lists, you can remove the "()," prefix.

Clause generalization should not impact the behavior of any existing queries which do not reference "gindex" and have at most one clause. Queries with multiple clauses may need the clauses reordered to achieve identical results, like in the above high-score table example.

I apologize for any migration-related inconvenience. Please reach out if you encounter any problems and need help.

Learning with Lil:

A few folks have mentioned an interest in trying next month's Advent of Code with Lil. The AoC is a fantastic way to sharpen your programming skills or learn a new language, and the first week or so tends to be accessible even to novices. If you feel like giving it a try, please consider sharing your progress in the Decker Community forum, and reach out if you have any questions! I'll do my best to address bug reports promptly should they arise. In the meantime, you could always try tackling a few of last year's problems to get the hang of it!