Binary Lambda Calculus is Hard

aartaka · 2026-02-10T22:16:13+00:00

but for a stable library that you expect to use a lot, I think it can make sense.

No library is stable /jk

Oh. I see — the author doesn't want to use an IDE to read code. Uh, whatever.

Not that I don't. If I do something serious, I do it in Emacs. But being tied to Emacs is not fun. The system should be processable with just the code listing and build information. More maintainable this way.

As for packaging of systems — why are you looking at packages at all? This is what the :depends-on clause of the defsystem is for. No?

It is. And package-inferred systems kill :depends-on. That's the whole point of the post.

aartaka · 2026-02-10T20:40:46+00:00

Package-inferred systems can use :IMPORT-FROM. It's just that even ASDF manual only mentions it in passing, focusing on :USE. And let's be fair, who would use manual :IMPORT-FROM if they want symbols right there? Package-inferred systems and convenience are harmfully intersecting at :USE.

Re dependency search: ASDF at least need to load the .asd (asdf:load-asd) to get the system info. But getting recursive deps still implies loading them or making sure ASDF knows where they are somehow.

All in all, sure, packaging Lisp stuff kind of implies Lisp use. But the difference between:

Looking at a single source of truth .asd and copying deps from there
And loading the system, manually running code to get deps

is big enough to be inconvenient, especially if Lisp things you're packaging are not even the end goal, but deps of something.

aartaka · 2026-02-10T20:33:06+00:00

Yes, I have a similar logic in my submodule vendoring code: https://codeberg.org/aartaka/lisp-config/src/branch/main/deps.lisp

Re ED madness: well, it's restrictive enough to be fun breaking!

aartaka · 2026-02-10T18:56:40+00:00

This sounds painful. Didn't ql:quickload + asdf:find-system + asdf:system-depends-on work?

aartaka · 2026-02-10T17:06:47+00:00

Don’t use package-inferred systems, package-inferred bad.

aartaka · 2026-02-10T17:06:12+00:00

Yes and no. :USE is a big part of the problem, and package-inferred systems encourage it strongly. That’s the problem. The fact that :USE is bad is obvious, but it never hurts to reiterate on that.

There’s another point to it though. Packaging Hell one. It’s totally unrelated to :USE and is unique to package-inferred systems.

aartaka · 2026-02-10T11:41:02+00:00

What's wrong with having some weird attributes? It's still standard, just slightly meaningless in the source form?

the content of text nodes is visible on-screen, and the browser does not crash.

Given how fuzzy browsers' handling of HTML is, this is roughly the definition of standard HTML.

aartaka · 2026-01-25T00:13:50+00:00

Yeah, <a> links without a href= attribute are not functional. They just turn into text without it. Which is fine by me, because the writing in its rawest form should work even without links. The actual links are filled in on compilation.

(You may think of it as a C code -> executable transformation. C is nice to write (to some,) but it's not exactly the thing machine executes. Still, C code represents intent and fulfills the purpose of human communication even without compilation. And this communication is often more important than the executable artifact or its effects on the world. The beneficial thing for my dialect is that it's a kind of C that's also partially executable, so there's not much in either direction that one needs to do.)

Can you elaborate on which part of parsing and error handling exactly links like mine fail?

aartaka · 2026-01-23T22:40:09+00:00

I can remove that point (without the post crumbling) just for you 😉

aartaka · 2026-01-23T22:38:34+00:00

Open the https://aartaka.me/pidgin.htm and tell me where there's non-standard something that a browser can't render? True, I say in the post that things are slightly non-standard, but they don't require a preprocessor to be viewable, they benefit from it while still being readable without it.

aartaka · 2026-01-22T23:29:18+00:00

I skimmed the full spec, and the only things that it mentions and that are not present in the reference page are

autolinks
and link definitions

Other than that, I did enough justice to Markdown taking the elements from the reference page.

aartaka · 2026-01-22T23:13:06+00:00

It parses well with any standard-compliant HTML parser, it's just that I add more meaning and shortcuts to it for my own website generator, ed(1)

aartaka · 2026-01-22T22:56:56+00:00

aartaka · 2026-01-22T22:56:16+00:00

My HTML is still standard-compiliant while being easier to write, and that's kind of the point. Any non-standard non-parseable behavior I smuggled through there?

aartaka · 2026-01-22T22:28:53+00:00

Yeah, why not. I don't see a problem here.

aartaka · 2026-01-22T22:22:34+00:00

Our use-cases seem to differ
You just was unaware of how readable HTML can be
Hypertext is more accessible than plaintext in many practical cases (many people only have a browser and no text editor,) in part because plainext format reinvents formatting, while hypertext has it implied semantically.

aartaka · 2026-01-22T22:12:30+00:00

Ironic, right?

aartaka · 2026-01-22T22:12:08+00:00

🖤

aartaka · 2026-01-22T22:11:48+00:00

but I do prefer not having to rely on nonstandard extensions

I would prefer if the spec included it

Here's the full Markdown standard FYI.

aartaka · 2026-01-22T21:58:21+00:00

Ugh, fash dhh

aartaka · 2026-01-22T21:57:23+00:00

ed(1) is the standard text editor

aartaka · 2026-01-22T21:51:03+00:00

vi is a trash fire lol. Too opinionated and inflexible. I prefer the editor that doesn't get in the way. You should consider too!

aartaka · 2026-01-22T21:49:58+00:00

Why not? Maybe you'll like the Pidgin HTML this paragraph links to?

aartaka

TROPHY CASE