{"version": "https://jsonfeed.org/version/1.1", "title": "Mimehole Arch", "home_page_url": "https://michael.homer.nz/notes/", "feed_url": "https://michael.homer.nz/notes/feed.json", "description": "Research notes from Michael Homer", "user_comment": "", "authors": [{"name": "Michael Homer", "url": "https://orcid.org/0000-0003-0280-6748"}], "language": "en-NZ", "items": [{"title": "Tinted Windows: Reconstructing Historic Dithering", "language": "en-US", "url": "https://michael.homer.nz/notes/dither-windows-3/", "date_published": "2026-09-25T00:00:00", "id": "https://doi.org/10.59350/wa3f9-pmq48", "authors": [{"name": "Michael Homer", "url": "https://orcid.org/0000-0003-0280-6748"}], "content_html": "

With the capacity only to display a very limited palette at higher resolutions, Windows 3.x used dithering to create the effect of a wider range of solid colours. There are a number of standard dithering algorithms, but these don't match what Windows actually did. The specific approach is documented in U.S. Patent 5485558, but there are a number of errors in the description given there. This is the result of my reverse engineering to produce behaviour correct to the real system, and a practical implementation illustrating it. The algorithm takes three colour coordinates 0\u2013255 for each of the red, green, and blue channels, and produces an 8x8 dither pattern containing up to four palette colours spread across it.

\n

Background

\n

Windows 3 was intended for use with VGA graphics cards, which supported 640x480 resolution with 16 distinct colours chosen from an 18-bit colour space. The standard Windows colour palette used white, black, and darker and lighter shades of red, green, yellow, blue, magenta, cyan, and grey.

\n
\"Full
Full 16-colour palette in two rows, dark above bright version of each colour.
\n

To create the illusion of a broader range of colours, dithering would be used to mix pixels of different palette colours together to approximate the real colour.

\n
\"Side-by-side
Composite image of, left, a dithered version of a colour captured in Windows for Workgroups 3.11's colour picker running under DOSBox-Staging and, right, a solid block of the colour ^1.
\n

Windows combined a selection of up to four colours drawn from 15 palette colours (light grey was excluded) to create any approximation, using an 8x8 pattern.

\n
\"Zoomed-in
Zoomed-in 8x8 dither pattern using dark and bright magenta, bright blue, and grey.
\n

There are a number of standard dithering algorithms, but these give different (and generally worse) results than what Windows did, even with the same palette.\nThere is a (now-expired) patent that describes the approach taken in Windows, but following the code given there doesn't produce matching results to the real system: wrong colours used, wrong proportions, and totally invalid for many colours.

\n
\"A
The result of the code in the patent for a specific colour, next to a swatch of the very different true colour.
\n
\"The
A solid swatch of the same colour, next to a much more similar dither pattern produced by the accurate algorithm.
\n

The next section explores my reconstruction of the true algorithm and correction of the errors in the patent description to replicate actual behaviour.

\n

The Algorithm

\n

U.S. Patent 548555810

Weise, David N. and H-Gunter Zieber. . \u201cMethod and system for displaying color on a computer output device using dithering techniques\u201d. United States Patent 5485558. Online.
\n

The patent was filed May 22, 1990, the release date of Windows 3.0. It's long expired and worth diving into. The whole thing is relevant but I'm going to be referring to Table 14 in particular a lot, which is a C code listing of (purportedly) the algorithm in use. The code isn't the easiest to follow because it relies almost entirely on global variables for passing arguments and return values, and most of it's unnecessarily structured in terms of matrices. It's also just wrong in several places, some of which are simple syntax errors, but others are quite annoying to trace; for the patent's own running example, the code produces a pure-grey dither pattern instead of the purplish colour it is meant to replicate. It uses "pel" for pixels and "super-pel" for the 8x8 dither pattern.

\n

The dither pattern uses 15 colours corresponding to every combination of half, full, and zero strength in each dimension, expressed as 4-bit RGBI (the 8 bit, I, makes the colour brighter). These are numbered 0-15 with 8 unused and the bits correspond directly to channels and intensity, in increasing order of significance RGBI. The patent gives these names with 8-bit values for each channel, but these would have been squashed to 6-bit for display, and on modern displays the dark colours in particular are darker than they would have appeared on contemporary monitors; the table below shows an approximation of how these shades would have looked at the time as well as swatches of the provided RGB values for all colours.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
RGBIBGRDecimalName
0 0 0 0000 0 \"\" Black
128 0 0 0001 1 \"\"\"\" Dark red
0 128 0 0010 2 \"\"\"\" Dark green
128 128 0 0011 3 \"\"\"\" Dark yellow
0 0 128 0100 4 \"\"\"\" Dark blue
128 0 128 0101 5 \"\"\"\" Dark magenta
0 128 128 0110 6 \"\"\"\" Dark cyan
128 128 128 0111 7 \"\"\"\" Grey
- - - 1000 8 \"\" (unused)
255 0 0 1001 9 \"\" Red
0 255 0 1010 10 \"\" Green
255 255 0 1011 11 \"\" Yellow
0 0 255 1100 12 \"\" Blue
255 0 255 1101 13 \"\" Magenta
0 255 255 1110 14 \"\" Cyan
255 255 255 1111 15 \"\" White
\n

The patent uses a working example of colour (r=128, g=31, b=190), but you can choose your own to follow along with.

\n\n\n\n

We'll use this\npurple/blue colour,\nr =\n128, g =\n31, b =\n190,\nfor the rest of this article.

\n
\n \n \n \n \n \n \n \n\n\n \n \n \n \n \n \n \n \n \n \n\n\n \n \n \n \n \n \n \n\n\n \n\n\n \n \n \n\n\n \n \n\n\n\n\n \n \n \n \n \n \n \n\n\n \n \n\n\n \n \n \n \n \n \n \n \n\n\n \n \n\n\n \n \n \n \n \n\n\n\n\n \n \n \n\n\n\n\n\n\n\n\n 0\n 1\n 2\n 3\n\n\n\n\n 4\n 5\n 6\n 7\n\n\n\n\n\n\n\n\n 9\n 10\n 11\n 12\n 13\n 14\n 15\n\n\n\n\n\n\n \n \n \n
The RGB colour cube with the palette colours marked and the example colour shown in place.
\n
\n\n\n\n\n

Mapping into tetrahedral space 0

\n

The algorithm maps the colour coordinates into one of six tetrahedral subregions of the colour cube, using four vertices of the cube. These tetrahedrons are defined by the planes with equal values R=G, G=B, and R=G (these each cross white, black, and one other opposite pair of vertices). The tetrahedron is then divided again into four subspaces, defined by colours on the vertices. It gets into that first tetrahedron by swapping coordinates such that r >= g >= b, remembering the swaps so that they can be undone at the end. This is:

\n
swapRB = r < b\nif swapRB:\n    r, b = b, r\nswapGB = g < b\nif swapGB:\n    g, b = b, g\nswapRG = r < g\nif swapRG:\n    r, g = g, r
\n

The swapXY values are used later to transform colours back. For our running example, we start with (r =\n128, g = 31, b = 190),\nso swapRB is\ntrue, swapGB is true, and swapRG is false,\nand for the rest of the algorithm the three values are (r =\n190, g = 128, b = 31).\nThey will be swapped back at the end.

\n\n
\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n \n \n \n \n\n\n \n \n \n \n \n \n \n \n \n\n\n\n\n\n\n\n\n \n \n \n\n\n \n \n \n \n \n \n \n\n\n \n \n \n \n \n \n \n \n \n \n\n\n \n \n \n \n \n\n\n \n\n\n \n\n\n \n\n\n 0\n 1\n 2\n 3\n 4\n 5\n 6\n\n\n 7\n\n\n 9\n 10\n 11\n 12\n 13\n 14\n 15\n\n\n\n\n\n\n\n\n \n \n \n
Tetrahedral subregion 0, bounded by vertices 0, 9, 11, and 15, includes colours 0, 1, 3, 7, 9, 11, and 15. The running example colour is shown plotted into this space.
\n
\n\n\n

Finding the subspace

\n

The subspace is determined by inspecting the coordinates. The ComputeSubspace function in the patent code is written very opaquely, but what it comes down to is:

\n\n\n\n

For the running example, we're thus in subspace\n2.

\n\n

Remembering that the values are ordered r \u2265 g \u2265 b, this subspace calculation is essentially "how bright is this colour".

\n

Determining the vertex colours

\n

The four colours to use are the vertices of the subspace tetrahedron. Every subspace contains grey (the centre of the overall colour cube) and three others from those included in tetrahedral space 0. Subspace 0 is all dark colours, subspace 3 is all bright colours, and the others are in between.

\n\n\n\n

This corrects subspaces 0\u20132 from the patent code, which lists colour 2 instead of 3 (table 3 has them correct). For the example, the colour values are\n3, 9, 11, and 7.\nRemember, these are the colours as reflected into space 0 at the start, not the final dither colours.

\n
\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n \n \n \n \n\n\n \n \n \n \n \n \n \n \n \n\n\n\n\n\n\n\n\n \n \n\n\n \n \n \n \n \n \n \n\n\n\n\n \n \n \n \n \n \n \n \n\n\n \n \n \n \n \n\n\n\n\n\n\n \n\n\n 0\n 1\n 2\n 3\n 4\n 5\n 6\n\n\n 7\n\n\n 9\n 10\n 11\n 12\n 13\n 14\n 15\n\n\n\n\n\n\n\n\n \n \n \n
Colour cube with the example colour's tetrahedral subspace 2 highlighted.
\n
\n\n\n

Scaling the values

\n

Every colour coordinate is scaled down from 0-255 to 0-64 inclusive, with 255 going to 64, 251-254 to 63, and 0-2 going to 0, which isn't quite the 6-bit mapping you'd expect. The calculation is ((n / 2) + (n % 2) / 2, or more straightforwardly the first division rounds up rather than truncating.

\nscale(n)=\u230a\u2308n2\u23092\u230b\n\n\n\n
r = floor(ceil(r / 2) / 2)\ng = floor(ceil(g / 2) / 2)\nb = floor(ceil(b / 2) / 2)
\n

The example's scaled-down coordinates are r =\n47, g = 32, b = 8.

\n\n

Transforming the coordinates

\n

Next, a coordinate transformation and inner product is used to calculate the number of pixels that will be in each colour. The coordinates are transformed by the origin of the subspace, which is (64, 0, 0) for subspace 3 and (32, 32, 0) in the others. The net effect is that in subspace 3 the calculation uses r - 64 and in the others it uses r - 32 and g - 32. These transformed values are multiplied by values from a matrix to calculate three counts, but the matrix from the code listing has some incorrect values. The code also mixes up its tempB and tempG variables. The corrected and simplified calculations are

\n\n\n\n

For the example, in subspace\n2,\nthe result is c1 =\n15, c2 = 15, c3 = 16.

\n\n

Pixel counts

\n

These computed values determine the number of pixels for each specific colour. There can be between one and four colours with pixels allocated to them. A table of (colour, count) pairs is calculated as:

\n\n

In the example,\n15 +\n15 +\n16 =\n46, so there are\n18 pixels assigned to colour\n3,\n15 to 9,\n15 to 11, and\n16 to 7.

\n\n \n \n \n \n \n
ColourCountBit pattern
3180011
9151001
11151011
7160111
\n\n\n

Projecting these pseudo-colours back

\n

These "colours" aren't the ones used for the final dithering output, however: instead, their bits are permuted according to the three "swap" operations determined earlier.

\n

For each colour:

\n\n

The SwapRG/SwapGB/SwapRB values chosen at the start are now used to rearrange these, in that order. That is, these actually correspond to swapping the low two bits, the 2 & 4 bits, or the 1 & 4 bits respectively, to match when the numeric red/green/blue channels were swapped at the start. The 8 bit is left as it is.

\n
if swapRG:\n    R, G = G, R\nif swapGB:\n    G, B = B, G\nif swapRB:\n    R, B = B, R\ncolour = R + G * 2 + B * 4 + I * 8
\n\n

Since the example has swapRG =\nfalse, swapGB =\ntrue, and swapRB =\ntrue,\nthe calculation runs like this:

\n\n \n \n \n \n \n
OldI (8)B (4)G (2)R (1)NewCountColour
001100110101185
1001100111001512
1011101111011513
011101110111167
\n\n\n

These are now the palette colours for the final dither pattern. The table has the same counts corresponding to the new colours.

\n

Sorting the colours by decreasing darkness

\n

The table is then sorted according to a predefined ordering of darkness, with the darkest first. The colours ultimately sort into this order:

\n\n\n\n

That is, dark blue is earlier and dark yellow is later, and the same with intense blue and intense yellow.

\n

The patent body has a table of the sorted elements for its example, but it's in the wrong order and has the wrong counts.\nIf you skip this step entirely, the end result looks pretty much as good of a match to the target colour; this Stack Exchange answer suggests the ordering (presumably combined with the specific Bayer matrix below) is to avoid discontinuities when transitioning between nearby colours in different (sub)spaces, but I haven't found any confirmation of that. In any case, to match the expected behaviour it's necessary.

\n\n

For our example, the final order should be:

\n\n \n \n \n \n \n
ColourCount
518
716
1215
1315
\n\n\n

Filling the pattern

\n

Finally, the 8x8 grid is filled with the chosen colours. Each colour appears as many times as its calculated count, spread throughout the pattern according to a pre-determined Bayer matrix. The matrix of allocation orders ^2 is given as:

\n(0328402341042481656245018582612444361446638602852206230542233511431339415119592749175725154773913455376331552361295321)\n\n\n\n

This corresponds to filling in position (x, y) in this order:

\n
[\n    (0, 0), (4, 4), (4, 0), (0, 4),\n    (2, 2), (6, 6), (6, 2), (2, 6),\n    (2, 0), (6, 4), (6, 0), (2, 4),\n    (0, 2), (4, 6), (4, 2), (0, 6),\n    (1, 1), (5, 5), (5, 1), (1, 5),\n    (3, 3), (7, 7), (7, 3), (3, 7),\n    (3, 1), (7, 5), (7, 1), (3, 5),\n    (1, 3), (5, 7), (5, 3), (1, 7),\n    (1, 0), (5, 4), (5, 0), (1, 4),\n    (3, 2), (7, 6), (7, 2), (3, 6),\n    (3, 0), (7, 4), (7, 0), (3, 4),\n    (1, 2), (5, 6), (5, 2), (1, 6),\n    (0, 1), (4, 5), (4, 1), (0, 5),\n    (2, 3), (6, 7), (6, 3), (2, 7),\n    (2, 1), (6, 5), (6, 1), (2, 5),\n    (0, 3), (4, 7), (4, 3), (0, 7)\n]
\n

Each colour gets as many pixels as the count calculated in the colour count table,\nassigned in that order. For the example, that's a final pattern of:

\n\"\"
\n  5   7   5  12   5  12   5  12\n 12   5  13   7  13   7  13   7\n  5  12   5  12   5  12   5  12\n 13   7  13   7  13   7  13   7\n  5  12   5  12   5   7   5  12\n 13   7  13   7  13   5  13   7\n  5  12   5  12   5  12   5  12\n 13   7  13   7  13   7  13   7\n
\n\n\n\n

The final pattern, compared to the solid colour, looks like this:

\n
\"Zoomed-in
Zoomed-in view of the final 8x8 pattern.
\n\n

It's mostly a pretty good match, though certainly more so on modern high-resolution displays.

\n\n\n

Implementation

\n

I built a web-based tool for calculating and displaying these patterns that should run in any recent browser.

\n

Dither

Choose a colour, and see a swatch of the colour, one of the resulting dither pattern beside it, and an 8x-zoomed view of the pattern, calculated in-browser.
\n
\"Screenshot
The tool also allows downloading a PNG image of the dither pattern, copying a data: URI, or copying the image itself, and charts the distribution of each colour in the pattern.
\n

The library behind it is also available:

\n

mwh/dither3x on GitHub

Generate accurate Windows 3.x dither patterns for any colour in-browser.\nA JavaScript library.
\n

It tries to tread the line between paralleling the patent's code \u2014 matching the function names and structure \u2014 and being understandable. It's reasonably heavily commented.

\n

While putting this article together I also built a (much-less-tested) Python version that's available for what it is:

\n

Python implementation of the algorithm.

This implementation is a pretty close match to the description here, and it's intended to be correct but has not been tested as much as the other.
\n

The HTML version of this article also has a live implementation backing the running interactive example.

\n
\n

Endnotes

\n\n\n
\n
\n

References

\n \n
\n", "attachments": [{"url": "https://michael.homer.nz/notes/dither-windows-3/dither-windows-3.html", "mime_type": "text/html", "title": "Single-file archive of article: Tinted Windows: Reconstructing Historic Dithering", "size_in_bytes": 245702}]}, {"title": "On Accidental Time Travel and Delimited Continuations", "language": "en-US", "url": "https://michael.homer.nz/notes/time-travel-delimited/", "date_published": "2026-04-12T00:00:00", "id": "https://doi.org/10.59350/fwccr-w2162", "authors": [{"name": "Michael Homer", "url": "https://orcid.org/0000-0003-0280-6748"}], "content_html": "

A number of my Grace ^1 implementations using the AST embedding I introduced recently are in continuation-passing style, either because they have to be (Haskell) or to avoid blocking.\nIn combination with Grace's block semantics and non-local returns, the na\u00efve implementation of this inadvertently enables "time travel": the program can "go back in time" to return from a function that already returned, continuing execution from then again.\nThis leads to some interesting outcomes.

\n

What this looks like is a block containing a return statement { x -> return x } that is stored into a variable somewhere.\nThe method it's inside returns normally, but later on, the block is applied\u2014 and the method returns again, and the program keeps going.\nThis is a bug in those implementations, not a Grace language feature, but it arises in an interesting-enough way to be worth discussing.\nThe next sections will briefly introduce the Grace semantics and the core of continuation-passing style, then explore what falls out of these on simple CPS implementations.

\n

Grace blocks

\n

Grace is a "curly-brace" language, but control structures like if and for are actually Smalltalk-style multi-part method names. if (true) then { x } else { y } is a three-part method name if-then-else with three parameters, a boolean and two "blocks": first-class lambdas that can be applied (or not) later, or repeatedly.\nThese result in more-or-less normal-looking imperative code, while user-defined structures can be on par with those shipped with the language.\nPart of supporting that is non-local returns: a block can contain a return statement, which determines the return value not of the block itself but of the lexically-enclosing method.\nThat allows, for example, an early return from a search loop:

\n
method does(lst) contain(value) {\n    for (lst) do { x ->\n        if (x == value) then {\n            return true\n        }\n    }\n    return false\n}
\n

The "then" block above will return from the whole does-contain method, just as would happen in typical curly-bracket languages like Java.\nIn doing so, it jumps over the stack frame of the block itself, of if-then, of the outer block, and of for-do, exiting the method itself.\nWith normal code, everything here just works as expected and nobody notices anything out of the ordinary.\nBlocks can be used for control structures, event handlers, and anything else where reifying a piece of code is useful.

\n

On the implementation side these non-local returns are a bit tricky, depending on the paradigm of the host platform:

\n\n

It's the last of these that we're looking at here.

\n

Continuation-passing style

\n

In brief, this implementation style models every step of computation as a function that has access to another function representing the next step of the program.\nThese represent the continuation of the program and so are called "continuations".\nAt least conceptually, the result of any (sub)step is passed as an argument to the next function, and there's a straightforward translation from SSA form: for every assignment, the right-hand side is the "first" function, and its continuation is the assignment itself; the assignment's continuation is the next line's right-hand side, and so on.\nWhen calling a function, it's given the continuation of where it was called from to return to.\nSome languages (mostly Lisps) allow reifying those continuations, but Grace isn't (intended) to be one of them.

\n

Accidental time travel

\n

While Grace doesn't allow obtaining or storing a continuation, Grace blocks are first-class, storable values.\nThe also have two ^2 exit paths: their own return value (which gives a value to the code that requested the apply method on the block), and returning from the method the block was written within (giving a value back to the code that requested that method).\nIn combination, under a continuation-passing implementation, it's possible to store a value that can attempt to return from a method that has already finished:

\n
var blk\nmethod test {\n    blk := { x -> return x }\n    return 1\n}\n\n\nvar n := test\nprint(n)\nblk.apply(n + 1)
\n

The code above is, surprisingly, an infinite loop ^3.\nIt prints out an unbounded list of integers.\nThat's because when blk is applied to an argument, it invokes the return continuation of the test method it was created in \u2014 resuming execution in the var n := test line and continuing from there, with a new value in n and eventually reaching the blk.apply line again to jump back one more time.\nChanges to any visible mutable state persist between invocations, but the call chain and program counter (which line of code we're currently at) resets.

\n

On its own, this is unlikely code to write and just a worse way of obtaining while (true) ^4.\nIt's surprising, but perverse, and probably you'd never run into it in practice.\nHowever, it would be possible to make deliberate use of it for speculative angelic non-determinism, for example.\nThe implementations where this works probably ought to detect and reject it, but it's uncommon enough to write and complex enough to detect that none of them do so far.

\n

Building delimited continuations

\n

We can even construct standard shift-reset\u2013style delimited continuation operators, which will allow any of the many structures definable on those to work.\nThe definitions are a little awkward, but they're remarkably short for what they're doing.

\n
var resetPoint := { x -> x }\nmethod reset(blk) {\n    def origReset = resetPoint\n    resetPoint := { val ->\n        resetPoint := origReset\n        return val\n    }\n    def v = blk.apply\n    resetPoint.apply(v)\n}\n\n\nmethod shift(blk) {\n    def cont = { val -> return val }\n    def origReset = resetPoint\n    def v = blk.apply(object {\n        method apply(v) {\n            resetPoint := { val -> return val }\n            cont.apply(v)\n        }\n    })\n    resetPoint := origReset\n    origReset.apply(v)\n}
\n

These methods work on any of the CPS implementations, and are used like:

\n
reset {\n    print(1 + shift { k ->\n            k.apply 10\n            k.apply 20\n        })\n}
\n

Here k is the reified continuation: whenever it's applied, shift will return that value, and control flow continues until the end of the enclosing reset, whereupon it will jump back to right after after k.apply.\nThe code above will print 11 21.\nFor a single small use like this it's obviously not useful, but we can create McCarthy's amb operator trivially too:

\n
method amb(many) {\n    shift { k ->\n        many.do(k)\n    }\n}
\n

Whenever this function is used within a reset, it will return each of the values in many in turn, and execution will continue from that return each time.\nThe code will treat amb as returning a single value \u2014 which it does, in any given timeline \u2014 and doesn't need to be layered in a loop.\nWhen the control flow reaches the enclosing reset, amb will return the next value in a new timeline, or we can abort by returning to outside the reset scope.\nThere can be multiple amb calls and they will all fork the timeline when reached.

\n

Consider the following Pythagorean triple finder:

\n
method pythag {\n    reset {\n        def a = amb [2, 3, 4, 5, 6]\n        def b = amb (2..14)\n        def c = amb (2..14)\n        if (((a * a) + (b * b)) == (c * c)) then {\n            return object {\n                def l1 = a\n                def l2 = b\n                def l3 = c\n            }\n        }\n    }\n}\ndef sol = pythag\nprint "Solution is {sol.l1}^2 + {sol.l2}^2 = {sol.l3}^2"
\n

This will return the first correct Pythagorean triple in that range (3, 4, 5).\nIf we add a print "{a} {b} {c} right above the if, it will show that all the prior values were tested, and those timelines abandoned because they didn't correspond to triples.\nWhen one was found, the return chose the current timeline as the one to continue, and only one set of values came out of pythag so only one solution is printed ^5.\nLater combinations were not evaluated at all because we abandoned the reset.

\n

This is a fairly standard demonstration for delimited continuations, and not so remarkable on its own.\nWhat's interesting about this result is that we obtained it "for free": it comes via not performing some checks on blocks' non-local returns.\nA block, na\u00efvely implemented, provides the primitive for building out these structures in a language that didn't intend to have them (and probably doesn't want them).

\n

Coroutines

\n

We could also build a simple coroutine system.

\n
var next := done\nreset {\n    shift { k -> next := k }\n    print(1)\n    shift { k -> next := k }\n    print(2)\n    shift { k -> next := k }\n    print(3)\n}\n\n\nprint "A"\nnext.apply(done)\nprint "B"\nnext.apply(done)\nprint "C"\nnext.apply(done)
\n

The code above will output, in order, "A 1 B 2 C 3", with execution passing back and forth between the code within and outside the reset with each shift or next.apply.\nThese could be wrapped up into objects affording a tidier interface, potentially built out of the non-locally-returning blocks directly (i.e. using them as unrestricted continuations) instead of via shift-reset.

\n

Discussion

\n

Experimentally, I've added native shift and reset to most of the wg CPS implementations, so the examples above will work even without defining your own methods, but if they are defined then they will override the built-in control structures and verify that the lifting really does work as described.\nThe native implementations are generally a little faster and in some cases keep better track of stack traces for use in exceptions and other reporting.

\n

Probably, exposing continuations at all is not suitable for a language like Grace; potentially some of the things that can be built out of them are worthwhile to promote to language features.\nFor now, though, creating reified unrestricted continuations through this strange dance with blocks is a path to experimentation.

\n

CPS implementations of other programming languages might inadvertently expose the same loophole.\nThe main unusual requirement is the non-local return semantics; if there are first-class lambdas and non-local return then it should in principle be possible to reconstruct a reified continuation out of them.\nWhere the underlying continuations are single-shot, the strangest outcomes above are out of reach, though a single time travel might still be possible.\nIf they are multi-shot, either deliberately or by default (e.g. because they are composed straightforwardly out of functions), the full range should in principle be possible.\nExcept when this is deliberately part of the language semantics, return continuations should probably at least be invalidated upon first use, in effect turning those single-shot, though this isn't quite enough to escape all the issues.

\n
\n

Endnotes

\n\n\n\n\n\n
\n
\n

References

\n \n
\n", "attachments": [{"url": "https://michael.homer.nz/notes/time-travel-delimited/time-travel-delimited.html", "mime_type": "text/html", "title": "Single-file archive of article: On Accidental Time Travel and Delimited Continuations", "size_in_bytes": 50618}]}, {"title": "Avoiding Accidents in Structural Types", "language": "en-US", "url": "https://michael.homer.nz/notes/structural-accident-prevention/", "date_published": "2025-05-31T00:00:00", "id": "https://doi.org/10.59350/rs6yn-0y530", "authors": [{"name": "Michael Homer", "url": "https://orcid.org/0000-0003-0280-6748"}], "content_html": "

This short survey arose from a Stack Exchange question Language constructs to reduce inadvertent interface implementation in purely structural type systems?, about ways to step out of structural type-compatibility when program logic required it. I've done some work in that area myself, but there are several other versions that make different trade-offs, so this post surveys all those. There are also some "loopholes" to construct pseudo-nominal types, which were part of what we considered as alternatives in my prior work. We argued that adding a nominal recovery on top of a structural base was preferable to adding structural types within an existing nominal type system, and that it's better to have the discretion to expose or not the abilities to create and detect these objects.

\n
\n

The general solution to this problem is known as "brands", also "trademarks" or "tags", and does essentially amount to adding a nominal system on top, but in various different ways that may be more (or less) palatable. This goes back at least as far as Modula-3's branded record types in practical languages. A few examples of this to refer to:\n

\n

All of these make some different tradeoffs and are more or less invasive to the rest of the language, and would be useful to look at when considering adding this functionality. I can speak more to the last one than the others; the goal there was to make use of existing language features (pattern matching and annotations), with the static checking layered on top, so the language semantics itself doesn't change, and to separate the ability to brand a value from the ability to discuss a brand type. Others introduce what amount to Java-style nominal classes that can also match structural types, type system extensions that allow more behavioural integration, and other changes that may be interesting to examine.

\n
\n

One of the common example use cases given for this sort of feature, and one that separates things from the "encoding business logic" part that some people have disputed, is encoding abstract syntax tree nodes. It's not uncommon to have multiple syntax elements that are structurally equivalent \u2014 variable and constant declarations, for example \u2014 but have distinct meanings and can't be interchanged. It is useful to be able to distinguish those types even within a generally structural system. Another common example is things like exception hierarchies: IOError and MemoryError are intended to be distinct, but may have the same shape. These go beyond business logic, but even making business-logic illegal states unrepresentable through the type system is a desirable property to allow in many cases.

\n

"Make invalid states unrepresentable" isn't always the right thing to do, and sometimes that just makes the whole program more complicated, but being able to do that validation where it matters, and have the system enforce that it's consistent, is very useful.\nThere are a wealth of other reasons to want some sort of brand on a subset of your object types, while leaving the rest extensible, and the systems above make different tradeoffs in how they use that.

\n
\n

There are some other techniques that don't involve nominal types and were considered in the Grace design, although they do mostly look like workarounds for the lack of a branding system.\n

\n

I think both the brand model and pattern matching offer reasonable language ergonomics, depending on what you're trying to do elsewhere in the language. The singletons & phantom method approaches feel like a hack you use when the language hasn't given you what you need for the task, but they are quite cheap inclusions to the language.

\n
\n

References

\n \n
\n", "attachments": [{"url": "https://michael.homer.nz/notes/structural-accident-prevention/structural-accident-prevention.html", "mime_type": "text/html", "title": "Single-file archive of article: Avoiding Accidents in Structural Types", "size_in_bytes": 44734}]}, {"title": "What does it really mean to say a programming language has \"strong\" or \"weak\" typing?", "language": "en-US", "url": "https://michael.homer.nz/notes/strong-weak-typing/", "date_published": "2025-01-05T00:00:00", "id": "https://doi.org/10.59350/syzm8-2tz51", "authors": [{"name": "Michael Homer", "url": "https://orcid.org/0000-0003-0280-6748"}], "content_html": "

This survey started from a Stack Exchange question How are "strong" and "weak" typing defined?, asking what is meant by describing a programming language as "strongly-typed" or "weakly-typed". The question pointed at the Wikipedia article on the subject and to a blog post by Curtis Poe featuring this quote:

\n
\n

Probably the most common way type systems are classified is "strong" or "weak." This is unfortunate, since these words have nearly no meaning at all. It is, to a limited extent, possible to compare two languages with very similar type systems, and designate one as having the stronger of those two systems. Beyond that, the words mean nothing at all.

\n

Therefore: I give the following general definitions for strong and weak typing, at least when used as absolutes:

\n\n
\n\n

This note collects my survey results looking at how these terms were actually used, and whether we could assign any valuable meaning to either of them.

\n
\n

The Wikipedia article, and the blog post, are correct that these terms are not well-defined and are not useful for communicating in general, and at best can be used in a relative way within a particular context. Sometimes they refer to accessing the bit representation of a value as another type, sometimes they are about implicit type coercions, sometimes they refer to polymorphism, sometimes they refer to the presence of static types at all, sometimes they are about expressivity or dependent properties like bounds checking, and sometimes they are just a subjective impression of quality ("A type system that I like and feel comfortable with", indeed).

\n

You will see these terms used with quietly different meanings, and you'll see those meanings explicitly disputed, sometimes both by what you might consider experts. That doesn't mean that they aren't used or can't be useful within narrow contexts where the relativity and the elements under comparison are understood and help, but it does suggest that they're not useful as freestanding terms.

\n

I'm going to look at some uses of these terms from academic literature over time, and then highlight some conflicts that arise within it, both explicitly and implicitly.

\n
\n

Firstly, let's try to look for an actual definition, and then see whether that tracks with usage.

\n

The Oxford Dictionary of Computer Science defines "strong typing" as:

\n
\n

A feature of some programming languages that requires the type of each data item to be declared, precludes the application of operators to inappropriate data types, and prevents the interaction of incompatible types.

\n
\n\n

It does not have a definition for "weak typing". This is probably the closest thing to an "authoritative definition" (at least, it's trying to be), but you might find points to question in there already, and many times the term is used will not be entirely consistent with it; it also depends on the meanings of several other terms, like "type".

\n

Strongly-, weakly-, and even statically- and dynamically-typed just are not as firmly-defined as people tend to think while they're using them. To highlight this I sometimes put forward the case that "C is strongly-typed ^1, Perl is statically-typed ^2": both of these claims are obviously definitionally false, and yet... they seem to be true, from a certain point of view, under conventional descriptions of what those terms mean, and many definitions inadvertently include them.

\n
\n

A historical wart here is also that "strong typing" and "static typing" have at times been used as essentially exact synonyms; for example, see this Bertrand Meyer abstract from OOPSLA 1992, Ensuring strong typing in an object-oriented language:

\n
\n

Static typing, also known as strong typing, has a long and rich history in programming languages.

\n
\n\n

On the other hand, we can look to Strong typing of object-oriented languages revisited from OOPSLA/ECOOP 1990:

\n
\n

We regard this as a continuum where weakly typed means that the type of an expression carries little or no information. Smalltalk is an example of such a language where the type of instance variables convey very little information on what messages are legal to send to the denoted object. A perfectly strongly typed language would exclusively have expressions where its type carries all information about the denoted object.\n...\nLanguages with a hierarchical type system and qualified references serve as a compromise since some, but not necessarily all, operations on an object can be inferred from the qualification of the reference.

\n
\n\n

So, here, typical object-oriented polymorphism is contrary to strong typing. Among users of functional languages, this is a common concept of strong typing.

\n

Further back, Type equivalence in strongly typed languages: one more look from 1979 says:

\n
\n

In a strongly typed language, each value has a unique type. The key impact of this is that, starting with the knowledge of the type of each identifier and constant appearing in the program, it is possible to determine the type of every expression in the program.

\n
\n\n

This is more or less just a description of sound static typing. It may rule out polymorphism again, although the languages being discussed simply didn't have it and that probably wasn't in mind.

\n

A direct, if handwaved, definition is given in this paper:

\n
\n

Type systems may be static (compile time), dynamic (run time), strong (strict), or weak (loose). The type system of C/C++ is static and weak,\nmeaning that it is up to the programmer to prevent type errors from occurring at runtime

\n
\n\n

followed by

\n
\n

The C/C++ type system is intentionally weak, i.e., allowing for arbitrary pointer casting

\n
\n\n

thus definining "weak typing" as memory reinterpretation. This is also a fairly conventional meaning for strong & weak typing.

\n

We can see discussion of the very conflict you bring up as well, such as in Assessing the ripple effect of CS1 language choice in 2000:

\n
\n

Some say that C++ is strongly typed but this statement should be taken only with respect to the default static typing done on calls made through base class pointers. Otherwise, C++ is weakly typed like C, full of implicit casts, the interpretation of any type as a boolean, and the treatment of all primitives as integers -- language constructs that fail to reinforce the notion of a type to a novice.

\n
\n\n

We can see that there are some pretty divergent uses of "strong" and "weak" already. If these uses are sufficiently disjoint, maybe that would be ok.

\n
\n

There are direct conflicts in the uses of the terms. Let's zoom in on just one language and see how it's been described. We can see identification of Python as strongly-typed:

\n
\n

In contrast, using strongly typed text languages (even dynamically like Python) requires the understanding of data types and the respect of languages grammar and syntax

\n
\n\n

And we can see identification of Python as not strongly-typed:

\n
\n

This is rather difficult to detect in Python due to the lack of strong typing, and as such, there are additional uses that are not included in the results

\n
\n\n
\n

TensorFlow used Python\u2019s weak typing system to construct graphs from Python functions

\n
\n\n

We can see a set of languages classified as strongly- or weakly-typed in A Large Scale Study of Programming Languages and Code Quality in GitHub, FSE 2014:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
StrongWeak
C# C
Java C++
Python Objective-C
Ruby CoffeeScript
Clojure JavaScript
Erlang Perl
Haskell PHP
Scala
\n

Once more, Python is identified as strongly-typed. We can also find many other real-world uses that classify it in both directions, give conflicting definitions, and argue quite intensely.

\n

You might agree or disagree with some others of those listed languages as well \u2014 and you'll see that reflected in the literature too, including directly in\nOn the Impact of Programming Languages on Code Quality: A Reproduction Study in TOPLAS from Emery D. Berger, Celeste Hollenbeck, Petr Maj, Olga Vitek, Jan Vitek in 2019:

\n
\n

The Type category is the most counter-intuitive for programming language experts as it expresses whether a language allows\nvalue of one type to be interpreted as another, e.g., due to automatic conversion.\nThe CACM paper\nattempted to clarify this definition with the example of the ID type. In Objective-C, an ID variable\ncan hold any value. If this is what the authors intend, then Python, Ruby, Clojure, and Erlang\nwould be weak as they have similar generic types.

\n
\n\n

The CACM paper referred to changes the name of that category to "Implicit type conversion", so clarifying that as the meaning they intended by "strong/weak typing" the first time (and likely reflecting pushback in between on this very controversy over the terms!). This is one meaning of "weak typing", but as we have seen above it's not the only one.

\n
\n

JavaScript given there is one of the categorical examples of weak typing, used all over the place, because of its many implicit coercions. On the other hand, another conventional perspective is that weak typing is about reinterpreting a value's memory representation as another type \u2014 this is where C falls \u2014 and you definitely can't do that in JavaScript \u2014 is it strongly typed? On yet another hand, C does define some types that can't be reinterpreted that way (function pointers) so is it strongly-typed too? We are stretching the terms beyond meaning at this point, but it highlights where these handwaves don't hold up when pushed.

\n

Even this perspective that it's the implicit coercions that make JavaScript weakly-typed isn't as particular as it seems on the surface.

\n\n

On the other hand, in Perl there is no need for such a string\u21d2number conversion, because numbers and strings are the same type all along: is it then strongly-typed? Or perhaps all those other languages are weakly-typed too \u2014 but clearly that perspective is not universal, so we'd need to be explaining what we meant, and one wonders why we want to use these specific words for that.

\n

Even other answers to the very question that led to this investigation pick out JavaScript as obviously without question one or the other. They give entirely contradictory rationales that let us distinguish the meanings in use, but clearly the terms then don't tell us anything themselves. We need to explain what properties we are concerned with, and then the explanation can stand on its own instead.

\n

We can also look to Eric Lippert, a designer of C#, to comment on that language:

\n
\n

Well if I'm an authority then: I agree with Curtis. Is C# strongly typed? It has many features that people describe as "strong" and many features that people describe as "weak". If you mean "allows casting", say "allows casting", not "weak". If you mean "objects can describe their types" then say "objects can describe their types", not "strong".

\n
\n\n

This is highlighting where these terms are not useful on their own: it would be better to say what you actually mean about the type system, rather than bundling it up into "strong" or "weak", if you want to communicate something. Someone else will have a different meaning and a different understanding. The Python examples above highlight that it simply isn't useful to say "strong typing": you need to say what you're actually talking about, or you'll be talking past one another.

\n
\n

I wanted to sum up with a general high-level description of things that were suggestive of each category, but I'm not sure I can even do that. We might try to say that:

\n\n

We can see a pattern there that "weak typing" is mostly negative framing, and I think that brings us back around to the quote from the original question:

\n
\n\n
\n\n

Yes, that seems about right for how people use those terms. In context, it can make sense to contrast different approaches in that way, with a particular value system as a frame of reference, but in the abstract "strong typing" and "weak typing" don't communicate much more.

\n
\n

Endnotes

\n\n\n
\n
\n

References

\n \n
\n", "attachments": [{"url": "https://michael.homer.nz/notes/strong-weak-typing/strong-weak-typing.html", "mime_type": "text/html", "title": "Single-file archive of article: What does it really mean to say a programming language has \"strong\" or \"weak\" typing?", "size_in_bytes": 83454}]}, {"title": "What factors make a programming language more (or less) beginner-friendly?", "language": "en-US", "url": "https://michael.homer.nz/notes/beginner-friendly-pl/", "date_published": "2024-06-13T00:00:00", "id": "https://doi.org/10.59350/4qw7b-60q70", "authors": [{"name": "Michael Homer", "url": "https://orcid.org/0000-0003-0280-6748"}], "content_html": "

Building from an answer I wrote to a Stack Exchange question What makes a language 'beginner-friendly'?, asking what aspects of a programming language made it more (or implicitly less) suitable for a beginner, here I discuss what's in the literature about this topic.\nMy PhD and a lot of my subsequent work has been with Grace, intended as an educational language, but this is a more complex question than it seems on the surface.

\n
\n

One challenge with addressing this question is that the evidence base is much thinner than you might expect, and much of the wisdom floating around isn't based on anything much, and quite often does not hold up when examined \u2014 but so little is examined that we don't necessarily know which.

\n

There just aren't as many actual experiments looking at programming-language design in total as you might expect \u2014 Antti-Juhani Kaijanaho's 2012 PhD thesis identifies somewhere between 37 and 137, depending on your inclusion criteria, and there haven't been vast numbers since then. Many of those are not specifically relevant to beginners.

\n
\n

The most significant recent study on language syntax and keywords for novices comes from Andreas Stefik and Susanna Siebert in 2013, An Empirical Investigation into Programming Language Syntax. Some of the results there are likely to be surprising, while others are obvious at least in retrospect. Overall, the major takeaways are that

\n\n

When experimenting on whole languages, Ruby, Python, and their Quorum language performed best. However, these experiments were still only in an artificial environment and did not measure learning, only accuracy.

\n
\n

There is a reasonable amount of evidence that static typing produces better results for novice programmers by catching their errors, but also that type annotations produce more syntax errors for them. The most well-known work in this vein is by Stefan Hanenberg, but it has been replicated a few times. Pedagogical experience reports often highlight the latter point as more significant at the very beginning \u2014 it's that "more tokens" issue again.

\n

Block-based programming environments, which prevent the creation of various kinds of syntax and type error, have been shown to perform better with novices than textual languages even when the language is otherwise identical, such as by Thomas W. Price and Tiffany Barnes in 2015, Comparing Textual and Block Interfaces in a Novice Programming Environment; there has also been significant work by David Weintrop and others. However, while these provide good support in the early stages of learning, they can also impose meaningful exit friction when the novice advances beyond what the block environment gives them. Most block environments also provide very easy access to graphical or interactive primitives, and may show live stepping or other debugging affordances.

\n

"Good" error messages do increase learner performance, but those that are "too helpful" are counterproductive, especially if they can make a bad guess about the user's intent. A substantial number of novices will "freeze" when there are many error or even warning indicators given to them, but presenting all errors at once outperforms one-at-a-time reporting. Allowing erroneous programs to run partially has shown some effectiveness. Improvements to error reporting have been studied among others by Becker, Brett A., Graham Glanville, Ricardo Iwashima, Claire McDonnell, Kyle Goslin, and Catherine Mooney in 2016, Effective Compiler Error Message Enhancement for Novice Programming Students. Negative responses to error messages perceived as directed at the user are common in new learners and the phrasing and content needs to be balanced carefully.

\n

Limited sub-languages that progress towards the unrestricted language have shown value as far back as SP/k, but it is Racket more recently that has brought them to the fore. The advantage these systems provide is that learners do not "stumble" into advanced functionality they didn't intend to reach; this sometimes happens when error messages lead them astray (a common anecdote is a novice who turns their entire Java program static after they try to fix an error saying they are unable to access an instance method or field from main). However, these limited languages also introduce more kinds of error and more ways for the learner to go wrong.

\n

Although the language "paradigm" seems like it should form a major component of the answer, the evidence for and against functional, imperative, object-oriented, procedural, ... models for learners is very mixed over time. There does not seem to be a strong recommendation that could be made in isolation backed by anything but personal assertion (and many have done so). The other aspects already mentioned, and any structured teaching wrapped around it, are much bigger factors.

\n

Localisation is a significant issue, particularly for younger learners. Learning keywords and following already-opaque error messages in an unknown language is challenging and new programmers understandably tend to perform better when the language keywords, library elements, word order, and diagnostic messages match their native language. For beginners who are non-English speakers (or are also beginners there), a localised language of some kind will probably help them at first. However, in many cases those localised languages that do exist have limited progression paths out of them and limited library support. Hedy is a language that tries to navigate this, with detailed localisation including the complex elements like word and writing order, but representing Python behind the scenes, and there's been quite a bit of study of how that works out.

\n

Finally, and this is a bit out of left field, the programming language that the most beginners pick up unassisted and to productive use is the spreadsheet, a spatial dataflow language. These do have very high error rates, but immediate accessibility that virtually no other programming environment matches. The true answer for a randomly-selected "beginner" is probably Excel.

\n
\n

Other topics I won't touch on more, but are worth keeping in mind also:

\n\n

Broad overviews of the long-standing research on learning programming are in

\n\n
\n

References

\n \n
\n", "attachments": [{"url": "https://michael.homer.nz/notes/beginner-friendly-pl/beginner-friendly-pl.html", "mime_type": "text/html", "title": "Single-file archive of article: What factors make a programming language more (or less) beginner-friendly?", "size_in_bytes": 52145}]}, {"title": "What evidence exists about brace- and indentation-based syntax for novice programmers?", "language": "en-US", "url": "https://michael.homer.nz/notes/novice-braces-indentation/", "date_published": "2024-03-19T00:00:00", "id": "https://doi.org/10.59350/0xy8d-5vb59", "authors": [{"name": "Michael Homer", "url": "https://orcid.org/0000-0003-0280-6748"}], "content_html": "

A Stack Exchange question (Studies on learnability of braces vs. indentation for code blocks for beginners?) asked for information about what evidence existed about the impact on new programmers of different ways of delimiting block structure in code.\nThis is the literature survey I composed in response, which finds there really isn't very much around at all.

\n
\n

I don't believe that there is any systematic pedagogical study on braces versus indentation specifically. Studies of actual learning are complex, time-consuming, and expensive, and I don't think any has been done (or likely would be) on that difference in isolation. The totality of human-factors studies comparing language design decisions likely numbers in the dozens (depending on your counting criteria, somewhere between 35 and 137 existed in 2012, per Antti-Juhani Kaijanaho's PhD thesis).

\n

However, there has been work on program comprehension and reproduction under different indentation and delimiting modalities, and on learning performance in different languages and editing environments. These are more mixed on indentation than you might expect: it's widely accepted that correctly indenting to match structure is helpful, but in fact empirical studies often show limited or no impact in practice. My high-level summary of the state of the art for block structure for novice programmers is that

\n
    \n
  1. indentation is somewhat valuable, but they don't use it unless enforced;
    2. \n
  2. keyword-based systems are more effective than symbol-based systems; and
    3. \n
  3. redundancy enables enhanced errors and thus improves effectiveness.
    4. \n
\n

None of these are strongly results. It is not clear that the benefits of keywords survive to expert programmers or with editor support for delimiting symbols, while indentation may well be more valuable to experts than novices. There has also been a lot of work with Lisps for novices, which are all delimiter and no indentation. It is likely that the ideal system for learners at this stage will both use delimiters and enforce that indentation is consistent with those delimiters (and this is the approach that recent novice-targeting languages like Pyret and Grace have taken, albeit without specific evidentiary basis).

\n

I will point to some specific studies below, although they are mostly not as strongly-grounded as I would like. None of the indentation-focused ones are comparing to brace-based languages or to semantically-significant indentation, though there are some suggestive pointers. I think the most relevant result is from the Quorum studies, suggesting that braces in particular perform poorly.

\n
\n\n

These studies looked at Pascal (keyword blocks, but all begin-end) programs with different indentation levels. The findings were that moderate indentation was beneficial for novice comprehension over both no indentation and greater levels of indentation. These are not brace-based programs and participants were already learning or programming in Pascal; the effect size is also surprisingly large for the difference between four- and six-space indents. There were a number of indentation studies around this time, with generally similar results, but not with novices in pure indentation-structured languages.

\n\n

This was a partial replication of the previous study, using curly-brace Java instead of Pascal, with students, and eight instead of six spaces. They found no impact from indentation at all on any of their measures: even zero indentation gave similar performance.

\n\n

This compares an IF-GOTO-based structure with (non-semantic) indentation with a variety of block-structured systems, using genuine novices in a controlled trial. The closest to braces is the begin-end variant of the language, and the programs in the GOTO version looked like an off-side-rule language, but the line labels were semantically significant; the other variants used IF-OTHERWISE and IF x-NOT x. The methodology had participants review a short tutorial on the language condition in use, and then write programs to implement a specific condition table. Indentation helped for all but one of their variants, but the version with distinguished start and end markers for each conditional performed worse. Participants had a lot of difficulty getting the indentation right in the GOTO case, but when they did their programs were no worse than others.

\n\n

This study measured defect detection rates from inspection of Java code with mid-level students, and found that bad indentation impaired detection more than bad naming. This was inconsistent indentation, rather than none, which the other studies haven't touched. These programs would likely be static errors in an indentation-based language, but might misbehave instead.

\n\n

These studies look at the time taken to comprehend braced Java code (not edit it) with different indentation structures. The result is that indentation reduces the time taken for the reader to react to a prompt about the control flow of a piece of code substantially, incorrect responses were provided more often in unindented code, and higher TLX difficulty was associated with lack of indentation; the suggestion then is that indentation makes the code more understandable. All the programs were artificial nested-if-statement structures operating on integers, and all had braces (a similar set of authors also examined indentation of JSON instead of control flow, with comparable results).

\n

There was an interesting inter-group analysis result: professional programmers were the most accurate group by a long way in the indented condition, and the least accurate group in the unindented condition, while undergraduate students were the fastest in both cases. This may be another point for reduced effect of indentation for learners in particular, but it's not clear what to take away from it, and it did not examine any effects on learning. There's also quite a high level of variation between individuals.

\n

I think this last one is the highest-quality study that isolated indentation as a factor, and none of them approach your question directly. We can take some hints that indentation is probably useful and can be sufficient, but that delimited block structure can also be sufficient on its own, and learners seem if anything to get less benefit from indentation than others.

\n
\n\n

This is part of the Quorum project, a focal point for modern empirical language design for novices (and the source of the famous "randomly-generated language more usable than Perl" claim). Most of this relates to keyword choices and indentation was not studied specifically, but of relevance here was a finding that block constructions that did not use braces had better performance metrics than those that did, although that subgroup included both the indentation-only Python and the keyword-end Quorum and Ruby.

\n

The best performers, very close together, were Ruby and then Python, with Perl and Java not statistically significantly different from Randomo, which was Quorum with braces and random ASCII keywords. Some issues writing the end keyword correctly were reported, but Quorum still uses that keyword today, so it wasn't found to be that bad of an issue.

\n

In all cases, "correct" indentation was presented in the learning material, but I don't believe it was required in what was produced except for Python. Indentation is encouraged but not required in Quorum, I think to reduce unnecessary errors during editing. Follow-up work on Quorum has reinforced these results for it.

\n

There are various other studies on teaching language pairs that I'm sure you've seen, but they don't generally get to this level of granularity and there are significant confounds for teasing out anything like this.

\n
\n

To conclude here, I don't believe such a study exists. I am confident that there isn't one prior to 2014, and I am not aware of and couldn't find any since either. I am sceptical that it would be worthwhile to run one for novices, because the value of that one factor is unlikely to be worth the substantial cost of running a genuine learning study, though a comprehension study that gets deeper than Hanenberg, Morzeck, and Gruhn is plausible.

\n

The general direction of the literature is that braces are not highly effective for novices, although lexically substituting an explicit end-of-block delimiter word for } seems to do better, and omitting any opening delimiter has some support too. Semantic indentation isn't supported one way or the other by this, but there is some evidence that matching end delimiters presents a difficulty, which is a matter that doesn't arise for semantic indentation. I don't think there is sufficient evidence to draw a conclusion one way or another.

\n
\n

References

\n \n
\n", "attachments": [{"url": "https://michael.homer.nz/notes/novice-braces-indentation/novice-braces-indentation.html", "mime_type": "text/html", "title": "Single-file archive of article: What evidence exists about brace- and indentation-based syntax for novice programmers?", "size_in_bytes": 53600}]}, {"title": "How often do variables in dynamically-typed code actually change type?", "language": "en-US", "url": "https://michael.homer.nz/notes/dynamic-type-changes/", "date_published": "2023-12-09T00:00:00", "id": "https://doi.org/10.59350/6qc07-pcv74", "authors": [{"name": "Michael Homer", "url": "https://orcid.org/0000-0003-0280-6748"}], "content_html": "

I've decided to self-archive some of my Stack Exchange answers that contain real research work, particularly the surveys that represent a lot of synthesis of the literature, so that I've got them here even if Stack Exchange goes away and I can extend and annotate them further.\nThis investigation grew from an answer I wrote to a Stack Exchange question Are there metrics on how often variables in dynamically-typed languages change their type (not "parametrically") about programmers in dynamically-typed languages using the same variable with multiple data types, outside of generic functions and automated type coercions.

\n
\n

A lot of work on type inference for dynamically-typed languages faces this issue, and often enough in practice that it comes up as something to be dealt with, while rarely enough that it's sometimes explicitly excluded from support. Some work has looked specifically at the use of dynamically-typed features on their own.

\n

In most cases the relevant results are on the side of something else, either an inference engine or analysis of more complex dynamic features. It doesn't seem like anyone has looked specifically at reassignment, which I do find a little surprising.

\n

Further down I'll note some limitations, and other cases that may or may not be in scope here. Exactly what it means for a variable to hold a new type is potentially a bit tricky to nail down. For example, what constitutes a type in these languages? is it necessary that the variable be reassigned?

\n
\n

Xia et al. performed an empirical study on dynamic-typing behaviours in Python programs on a substantial corpus of popular real Python systems, finding that at least 6.9% of identifiers had multiple types, and another 13.4% were undetermined by their methodology, while at least 79.7% of identifiers had only a single type. They show that even assigning two different types of literal to a variable sequentially has real incidence, while still being uncommon. They present a heat map of this matrix in Figure 5, but unfortunately an "expression" category squashes together what could be many different kinds of conversion into one (and I think the table over-eagerly aligns changes of type with changes of expression kind).

\n

Chen et al. performed another Python study and found an average of 311 instances of variables being given different types across their benchmark. I don't think this average metric they reported is particularly useful, but all but one of the systems under study had more than 50, and these were the most common dynamic-typing behaviours they measured by a large margin. Excluding the low and high outliers, between 10% and 25% of methods they examined in each system contained one or more of the traits they examined, and these would primarily be variable typing. However, most instances found did combine string with another type, noting that

\n
\n

It is often the case that the value of a variable\nis parsed from the user inputs and its type is determined by the\nsource of the inputs (e.g., XML files, database or command line).

\n
\n\n

They do present examples from real-world systems that show other replacements of values with different types, however, including strings. An example is given from IPython where a variable holding a dictionary is assigned one of the values from that dictionary. The reporting does not have enough detail to distinguish all of the cases desired to rule out.

\n

Furr et al. studied Ruby programs using a profile-guided tool to infer static types for unannotated code. To produce typecheckable programs, the tool required refactoring of the benchmark programs to remove precisely this issue: they performed 11 refactorings to break multi-typed variables into multiple uni-typed variables, out of 226 total refactorings across their suite (a number of these related to specific limitations of this version of the tool, like support for dynamic type tests, so the "true" proportion would be higher). They also note 12 instances of fundamentally untypeable code, notably within the optparse module that parses command-line options: while these issues are string->other conversions, the problem is that the repeated control flow gives variables multiple values for different options, so you might count these as well. However, both classes are relatively rare and do not occur in the majority of their benchmark programs.

\n

Pradel et al. produced a tool for finding type inconsistencies in JavaScript code, and benchmarked it against a suite of published code. This system was focused on finding potential bugs, rather than observing idioms, but it did encounter several cases of mixed types within functions that seem intentional; most of these involve the "undefined" type and another, which is meaningful within JavaScript's type model but could be analysed as a single nullable type as well. Other combinations also existed, but were less common.

\n

I believe one of the Vitek analyses of R also touches on this question, but I haven't been able to find which one, if it does exist. I have seen a presentation on the incidence of this pattern in PHP code (quite common), but can't find any archival publication of the result; it's an explicit motivator for much of the Hack work, so I expect it has been measured to matter on the Facebook codebase too.

\n
\n

One limitation that all of these face is that they are benchmarking against published code, which may tend not to use some of these features as much. It is likely that this overwriting is much more common in interactive use, which is inherently ephemeral and so not included in benchmarks. For example, a significant amount of R usage is entirely interactive, and maintaining a single variable for the in-progress results of where the user is up to is not uncommon, notwithstanding that the variable may hold different types internally as further analysis steps are run (and these different types may or may not be significant or known to the user). Some of this sort of interactive use may persist into non-published scripts calcified from interactive sessions.

\n

It's also the case, though, that code where a variable has type X up to a point, and type Y thereafter, isn't necessarily resting on dynamic typing at all: without loss of generality, this can be taken as two separate variables that have the same name, one shadowing the other. It's only cases where the variable is accessed from a loop or through lexical capture, or the type changes conditionally, where the ability to mix types together really matters. This is what the refactoring from the PRuby work above rested on. The reverse can also be true: idiomatic JavaScript will declare uninitialised variables before a loop to be set inside, such as in a search \u2014 but this is strictly a change of type within JavaScript's type model, because "undefined" is its own type! Similarly, Python None is used in the same role, and is not a bottom type either. It's necessary to drill down very specifically into what is meant by type changes in order to quantify them.

\n

I haven't touched here on another sort of "type" change: meta-mutable object values may be seen to have a different type each time one of their properties is added or removed. This could happen either as a value is built up originally (consider idiomatic JavaScript let x = {}; x.a = 1; x.b = 2;), either inline or by passing it to other code to populate; it can also happen long afterwards while the variable is still in scope somewhere. A change could also arise from modifications made to inheritance parents. Richards et al. showed that all of these sorts of change are very common in JavaScript code, and many are also possible and idiomatic in other languages on the more dynamic end of the spectrum. In Ruby, both monkeypatching existing types and eigenclass modifications are normal parts of using the language. These would be changes of a variable's type from some perspectives, and not others, and I'm not sure whether they're in scope of this question or not.

\n
\n

References

\n \n
\n", "attachments": [{"url": "https://michael.homer.nz/notes/dynamic-type-changes/dynamic-type-changes.html", "mime_type": "text/html", "title": "Single-file archive of article: How often do variables in dynamically-typed code actually change type?", "size_in_bytes": 45464}]}, {"title": "Live 2D Compositional Programming", "language": "en-US", "url": "https://michael.homer.nz/notes/compositional-2d/", "date_published": "2022-10-20T00:00:00", "id": "https://doi.org/10.59350/hsm7b-2jh64", "authors": [{"name": "Michael Homer", "url": "https://orcid.org/0000-0003-0280-6748"}], "content_html": "

Introduction

\n

This system started out as an experiment in making an obtuse\nprogramming paradigm more approachable.

\n

Sometimes regarded as "write-only languages",\nstack-based concatenative ^1\nlanguages rely on implicit argument\npassing and return values, with programs often just a bare\nsequence of function names, but they provide a very concise\nexpression of pipelines.

\n

A two-dimensional layout showing both the functions and the\ncorresponding values on the stack could help to make clear\nwhere values are coming from and going.\nHaving built it, though, it turned out to naturally express\nprograms outside of that paradigm as well\u2014and perhaps more usefully.

\n

In fact, artificial restrictions were necessary to ensure\nthat programs did remain concatenative, while the non-concatenative\nconstructions had clear meaning.

\n\n

This system lends itself to live editing of a program and\ndisplaying intermediate (and final) values throughout, and\nto exposing exactly the operations that are available at\nany given time.

\n

The following sections will discuss the background,\ndemonstrate usage, explore what can be done with it,\nand divert to investigating the uncovered semantics\nof the language.

\n

Compositional Programming

\n

Concatenative languages are those taking two programs\nand appending them together forms a new program,\nperforming the operation of one on the results of the other.

\n

This operation is composition, and is exactly\nanalogous to composition of mathematical functions, or to\ncomposition operators in functional languages like Haskell.

\n

In fact, concatenative languages can be analysed as\nfunctional languages where the default (juxtaposition)\noperation is function composition, rather than application

\n

Many concatenative languages are stack-based (e.g. Forth, Joy, Factor),\npassing arguments\nand return values implicitly between functions, though there are\nnon-stack-based languages as well ^2;\nwe (largely) do not deal with those here.

\n

The Concatenative wiki\nlists and provides information about a number of concatenative\nlanguages.

\n

Composing sequences of (sub)programs into larger programs\nis also analogous to Unix pipelines, and composition can be\na core operation without being strictly concatenative.

\n

One useful feature that these languages tend to have is the\nability for functions to have multiple return values, and\nsend some of them on for further processing.

\n

This particular aspect of compositional programming is key\nin what this system does.

\n

The next section will discuss the origins of this system\nin trying to support concatenative programming, before\nrelaxing that requirement and exploring what else can be\ndone with it.

\n

Origins

\n

The original motivation\nfor this system was to provide a more\napproachable way to read and write concatenative programs.\nConcatenative languages are sometimes seen as "write-only", because\nreading unknown code often requires simulating the parameter-passing\nstack mentally for each function, and knowing at least the arities of\nevery function involved.

\n

This two-dimensional notation can represent any of these\nconcatenative programs with all arguments and return values\nexplicitly manifest in the display: each function cell is laid out\ndirectly below its arguments, and stretched above its return\nvalues.\nThe grid thus alternates row-by-row between functions and values.\nA linear concatenative program can be rendered directly\ninto the grid:

\n\n

Either the types or concrete values can be displayed for the\nargument/return values.\nSimilarly, it is possible to linearise\na program back into conventional textual form.

\n\n

This notation permits editing the programs as well:\nBecause adjacent stack elements are side-by-side, a single drag\ncan select arguments to give to a function, and a menu of available\nfunctions that can consume those arguments offered to select from.\nIf the values are not in the right order, the option to swap is always\navailable.

\n\n

However, for purely concatenative use there is one further\nlimitation: the rightmost argument chosen must be the rightmost output\nof another function, in order for these values\never to be on top of the stack together.

\n

Relaxing this rule results in programs that do not\ncorrespond to typical concatenative programs, but which still have\nclear meaning: each function consumes the values from above, and\nproduces the values below, and only lacks the ability to turn into\na \u2014 fairly inscrutable \u2014 textual concatenative program.\nThis relaxed non-linearisable system is what we are interested in\nhere, as it provides a number of convenient features for live\nand exploratory programming, despite an execution model that is\nquite strange in conventional terms.

\n

Live Programming

\n

The interface allows displaying either the types accepted/produced\nby each function, or the concrete values of the arguments/returns.\nIn the latter case, true live programming is available: the user\ncan select a value, or a series of consecutive values,\nand choose the operation to process it or to combine them, and\nthe result is also displayed.

\n

Working in this way, available operands are always visible and\ntangible.\nThis is useful both for manipulation, and potentially for the\ndisplay itself, which may be the purpose of the program in the\nfirst place.\nAt any point the user can stop, and has a program that calculates\nand displays some values.

\n

This representation also shows the <em>provenance</em> of the\nresults innately: all of the precursor steps, and precursor\nvalues, are explicitly part of the display.

\n

High-level Data Types

\n

Examples so far have used primitive types, but arbitrary values\ncould be displayed for the user to work with, including\ncompound types or images.\nDisplaying these higher-level types may again be the purpose, but\nalso provides the opportunity for further affordances.

\n\n

Exploratory Programming

\n

Because all available values are always visible, the user can\nengage in undirected exploration of the program space.\nSelecting a value, or range of values, and seeing what functions\ncan be applied to them, enables discovering available pathways\nto experiment with.

\n

A function can be chosen, its results seen, and then be either\ncontinued with, or reverted.\nAny function can also be replaced in-place with another of the\nsame type proferred from the menu.

\n

The nullary functions for literals are also editable live,\nso that a numeric or string constant can be experimentally\nreplaced and the impact on the program seen.

\n\n

Comments

\n

The grid structure opens up an interesting possibility for\ncomments: the user can select a range of cells, and add a\ncomment to them.\nThese need not cover the entire row, and can be applied\nto only particular <em>values</em> rather than functions,\nlines, or blocks.\nOf course, it is still possible to select the entire row\nto comment, but additional flexibility is provided.

\n\n

Working with Functions

\n

So far we have looked only at building a whole program at once\nout of built-in functions, but user-defined functions can work\nin the same way.

\n

Another option provided when choosing a sequence of arguments is\nto create a new function that could accept them.\nThis function will be in a new tab, with the chosen parameter\ntypes set out across the top, and all the usual affordances\navailable as well.\nThe values left over at the end of the function will be what\nit returns, and the function can be used anywhere that those\nparameter types are available.

\n\n

As in concatenative programming, abstracting sequences of\noperations to named functions of their own is encouraged,\nto keep the program clear and comprehensible.\nIn this system in particular, the sheer amount of space\ntaken up by the grid layout provides added incentive.

\n

Lifting Functions

\n

This environment provides no looping constructs, and not (so far)\nhigher-order functions.\nGiven a list of values, there is thus no way to apply some\noperation across the list (neither a map nor a fold).

\n

Instead, user-defined functions have a "lifting" configuration\noption, accessible in their sidebar.\nThese liftings, in effect, wrap the function in a higher-order\noperation: the "Mappable" lifting applies the Functor map\noperation to it, for example.

\n\n

A Mappable function that takes in a single string and returns\na single int can be applied to a list of strings, a set of strings,\nor an optional of string, and will return the same wrapper type\nwith the produced int value(s) inside.\nSimilarly, a Foldable function that takes in an integer\nand a string can be applied to a list of strings and an integer\ninitial value (in the opposite order for compositional convenience).\nThis appproach provides the power of common higher-order functions\nwithout needing users to understand that sort of abstraction,\nand without requiring a more complex "syntax".

\n

Additional higher-order operations are possible,\nbut it is likely that at some point they introduce\ntoo much complexity to the type system and user\ninterface.\nSo far, the system does not support first-class functions\nthemselves, but they may be appropriate for a future version.

\n

Identifying Inputs and Outputs

\n

For functions with multiple inputs or outputs, it is not\nalways obvious which order these will be in.\nTo make this easier, some functions have a label configured\nfor each argument and return value position, which is\ndisplayed within the cell of the corresponding value,\nas smaller text above the value or type for a\nreturn value label, and below for a label given\nby the function consuming the value.

\n\n

These annotations are quite noisy and it is not\nclear that they are always advantageous, but the\ncurrent implementation includes them for arithmetic\nfunctions, built-in functions with many arguments,\nand accessors for record types.

\n

The user can also apply one of these labels to\nany stack value using a special <code>@<i>label</i></code>\nfunction.\nA manual label may be just a note for the programmer,\nbut will also be carried through as a label for a\nreturn value of a user-defined function, and is\npreserved by operations such as swap and dup.

\n\n

Language Semantics

\n

While stack-based concatenative programs are expressible in this\nsystem, the non-linearisable programs have an unusual execution\nmodel that would be difficult to express in a conventional\ntextual language.\nWe describe two ways of analysing the execution of\nprograms in this model,\nbut neither is notably useful ^3;\nthe visible vertical dataflow\nshould be the primary understanding of the approach,\nand we identify these here for completeness only.

\n

There is a linearisable representation of the semantics,\nbut it is queue-based rather than stack-based.\nFunctions shift their arguments from the queue and push their\nreturn values onto it, and are executed in order left-to-right\nrow-by-row.\nThe "empty" function cells where values span multiple rows are\nrepresented by the identity function in this linearisation,\nso the pushes and pulls will add up but corresponding operations\nwill virtually always be distant from each other.

\n

It can also be analysed as each row defining a function\nperforming the operations of all its cells, from\na tuple of arguments to a tuple of outputs to be consumed by\nthe next row.

\n

In either case, this is still actually concatenative: a program\nthat transforms A B to C D can be concatenated with one\ntransforming C D to E F to get a program that transforms A B to E F.\nIn terms of the 2D representation, this concatenativity is\nrow-by-row\u2014cutting off the final rows of a program results in a\nnew program that consumes the outputs of the first.\nHowever, the value of this fact is limited and the direct\nargument-function-outputs mapping represented by the\ngrid layout is always likely to be most useful.

\n

Inspirations

\n

A significant inspiration for this work was\ndataflow programming environment.\nUserland's approach to shell pipelines in particular, where\nconsecutive stages of the pipeline were laid out horizontally,\nthe standard output of each phase below, showed a path for this\nsort of composition.

\n

Another of course is the spreadsheet, the most widely-used\ndataflow programming system, and a grid-based one as well.\nThe actual execution of this system is not similar to\nspreadsheets, but some of the affordances for working with\nthe grid are.

\n

Live dataflow systems like Natto,\nand Ink &amp; Switch's\nproject, also inspire the approach to live updating and high-level data types.\nThe Hazel environment and its "typed holes" also\ncontributed to the interaction design.

\n

The Kitten was an\nentry point into statically-typed concatenative functional\nprogramming languages and influenced the approach taken in the\noriginal version of this system.

\n

The animations between the textual and visual representations\ndraw on my past work on Tiled Grace,\nwhich introduced this mechanism for making clear the relationship between sides\nin multiple-representation environments.

\n

Alexander Obenauer's\n"itemized operating system"\nproject also influences the approach to very high-level data types.\nIt would be interesting to integrate with external systems that expose their\ndata in this way, so that it can be programmatically accessed with\nthe pathway to obtain the result being explicit.

\n

Implementation

\n

The working environment is accessible in any web browser\nAll programs execute client-side, and the grid is manipulated\nwith the pointer: drag to select values (or click on single values),\ntap on functions to replace, remove, or edit them, and tap on the\nplus button on the right to add a new constant value.\nFunctions and programs are accessed via the tab bar at the top,\nand all functions are saved in the browser's local storage upon\nswitching.

\n

A working version of the system is also below, although it has\nsome limitations in this environment and is less full-featured here.

\n\n
\n\n\n\n

As it runs in the browser, the implementation is in JavaScript and\nis limited by the browser sandboxing in what it can provide.\nWhen running from a local file (rather than over HTTP) there are further\nlimitations.

\n

Future Work

\n

The present system serves as a demonstration of the concept, and\nhas a range of functionality to explore the ideas. However, there\nare a number of areas for future work, including simply building\nout more comprehensive functionality in the present sphere.

\n

The core interaction modality seems like it would be a good fit\nfor a mobile device or other touch-screen interaction, and it would\nbe interesting to explore this further.\nSwipe and tap gestures are typical interactions on such devices\nand align directly with the grid and function selection.\nThis approach could provide a mechanism for programming on these\ndevices, in the vein of what\nTouchDevelop\naimed at.\nSome preliminary work\nextending this system for tablets\nhas shown satisfying interactions.

\n

The system is currently limited to a single grid, and it would be\ninteresting to explore the possibility of multiple grids visible at once,\nwith\nthe ability to connect them together. This would allow for\nmore complex dataflow systems, and would also allow for\nthe possibility of multiple users working on the same system\nat the same time.

\n

Additional data types, and richer affordances for working with\nthem, would also be useful.\nEspecially in the exploratory programming context, it would be\nhelpful to have a wide range of operations and clear discovery\nmechanisms, while more direct manipulation of displayed\nhigh-level values to produce code outputs would also be good.

\n

Connecting to external systems would also be interesting, and the\ndesign of functions permits live-updating inputs for reactive\nprogramming.

\n
\n

Endnotes

\n\n\n\n
\n
\n

References

\n \n
\n", "attachments": [{"url": "https://michael.homer.nz/notes/compositional-2d/compositional-2d.html", "mime_type": "text/html", "title": "Single-file archive of article: Live 2D Compositional Programming", "size_in_bytes": 2910512}]}]}