Do I really want a lambda calculus cyberdeck?

A cyberdeck is an inconvenient portable computing device, often with a retro sci-fi aesthetic. Lambda calculus is an inconvenient mathematical model of computing. A lambda calculus cyberdeck, therefore, is an inconvenient device for inconvenient computing.

I envision a handheld device, maybe a bit bigger than a scientific calculator, and with a bigger screen and fewer keys. Here's my concept sketch:

I want you to imagine that instead of a crude freehand sketch, you are looking at a beautiful 3D rendering with maybe a shiny metal case and some cool diagonal air vents on the side.

Then we can imagine that the keys have satisfying Cherry MX blue switches, the display is maybe e-Ink, or something else equally cool-looking (because looking cool is most of the point of a cyberdeck), and there's an integrated battery with USB charging. I also thought it would be cool to have a lambda calculus reference sheet that slides into the back of the case.

The runtime could have some way to detect when the final evaluation of an expression is a Church encoding and pretty-print the output, and maybe it could accept input over USB serial to save me from having to type everything out perfectly every time I want to test it.

There are just a small handful of problems.

Lambda calculus problems

It turns out that programming directly in lambda calculus is really hard. I actually don't know how to do it yet, so the stuff I wrote on the display in the concept sketch may be meaningless. (I think (λx.λy.x)x means something like "a function of x that returns a function of y that returns x, applied to the symbol x", which would yield a function that ignores its argument and always returns our symbol x?).

You can add useful features to lambda calculus (such as support for numbers, and functions that take more than one argument) but those things aren't strictly necessary. And besides, if you carry on down that road then you just end up at Lisp. And noone wants a Lisp machine cyberdeck.

And to be honest, being difficult to program is a big part of the appeal for me, so maybe this isn't such a bad thing.

I was struggling with how to handle variable names, but I think what I've settled on is that the only letter available is x, and you make other variable names by appending apostrophes, so you can have x, x', x'', etc. (copied from the "austere" version of typographical number theory). This way we only need 2 keys to express arbitrarily many variable names, with no ambiguity about the end of one name and the start of the next.

Display problems

Most of the electronics and software is easy enough (take input from the keypad, handle line editing, evaluate lambdas), so everything only really has to fit around operating the display.

I have a Pimoroni "inkyWHAT" 400x300-pixel e-Ink display lying around unused.

The inkyWHAT is intended for use with a Raspberry Pi. I'd rather not drive the display with a Raspberry Pi though, that seems a bit too heavyweight. I'd rather this thing wasn't secretly running Linux underneath.

I also have a Raspberry Pi Pico lying around, which might be suitable for the cyberdeck.

So far I have tried to program the Pico using MicroPython in Thonny, but I found it to be a pretty bad experience. Firstly because the Python library for driving the inkyWHAT is only compatible with a normal Raspberry Pi, which for a Pico means ripping out all the parts that use numpy and RPi.GPIO, and rewriting them to suit MicroPython.

Secondly I found that either Thonny or MicroPython or both are pretty buggy. There seems to be only a very weak link between the code shown in the IDE and what is running on the hardware. The code you type in your main file seems to be reloaded OK whenever you click the green "RUN" button, but any code you put in other module files seems to be loaded only the first time you use that module, and subsequent changes have no effect until you unplug it and plug it back in. Even the big red "STOP" button doesn't do the trick.

After spending a couple of hours (unsuccessfully) porting the inkyWHAT display driver to MicroPython for the Pico, I concluded that I was going too far into yak-shaving and gave up.

Probably I'd just use a Pi Zero and tolerate the fact that it takes a couple of minutes to boot up. Or maybe stick with the Pico but write everything in C instead. The Pico's C SDK installation instructions don't look too complicated, but they are more complicated than "launch the Arduino IDE", which is what I'm accustomed to.

So the question is: do I really want a lambda calculus cyberdeck?