yeah I mean, to be clear, I'm less proposing "What if we add even more syntax and semantics to CSS" and more "what if we steal ideas from CSS, notice their similarity to logic / relational query languages, and use them to build something new". I probably could have articulated some of this better.
means, in English/pseudocode, roughly: "If you have an element X with attribute data-theme="dark", and X has a child Y with attribute data-theme="light", and Y is focused, then the outline-color of Y is black".
so we could write this also as, e.g.:
outline-color(Y, black) if
data-theme(X, "dark") and
parent(X, Y) and
data-theme(Y, "light") and
focused(Y)
that's Datalog, except I went ahead and replaced :- with "if" and "," with "and".
if we want even more syntax sugar, we could do:
Y.outline_color := black if
X.data-theme == dark and
Y.parent == X and
Y.data-theme == dark and
Y.focused
imagine `X.attr == val` <==> `attr(X, val)` as a kind of UFCS for Datalog to make it palatable to Regular Programmers, right
the declaration and scope of these variables is implicit here; if you want something even more ALGOL-family, we could write
forall Y {
Y.outline_color := black if
Y.data_theme == "dark" and
Y.focused and
Y.parent.data_theme == "light"
}
here we've explicitly introduced Y, and made one of our joins implicit, and it looks even more like Regular Programming now, except the Datalog engine (or equivalent) is kind of running all these loops for you, every time one of their dependencies changes, in an efficient way ...
SELECT 'black' AS outline_color
FROM elements parent
JOIN elements child ON parent.id = child.parent_id
WHERE parent.data_theme = 'light'
AND child.data_theme = 'dark'
AND child.focused = true
there's a lot of ways to express the same thing! it's interesting to notice the connections between them, I think, and their strengths and weaknesses, e.g. I probably wouldn't want to write my whole design system in SQL, but since it's relational queries over the elements structure and properties, you could.
yeah sometimes you end up making something very cool almost by accident. i tried to make shell pipelines properly concatenative like forth and friends and that had a lot of unexpected neat digressions in metaprogramming
tbh, this started as a connection of two disparate ideas ("hey, this thing looks like this other thing"), and then just kind of explores it in different directions.
I think the conclusion (which I may not have made clear enough) is less like "These are limitations of modern CSS which ought to be fixed" and more "Maybe a CSS-like syntax could be added to a Datalog-like system and that would be helpful for making it more accessible to more engineers, navigating tree-shaped data, etc"
I broadly agree with you, so I want to pick your brain a bit:
What would your ideal RDBMS / tooling look like, that facilitates 6nf effectively? Do you think it's more a limitation of the query/storage engine, or the query language (SQL), or the user interface? Do you think founding on Datalog (or similar), which kinda lends itself to "narrow" relations, instead of SQL which kinda lends itself to "wide" relations, would help here?
(I ask as one of my personal hobby-horses is trying to design better query languages and tooling, and 6nf/datalog maintains a kinda special place in my heart)
Interesting. Does that mean if you want to say, make an asynchronous http request, you do something like “fire_event(HttpRequestEvent(…))” which returns immediately, and somewhere else define a handler like “on_event(HttpResponseEvent, function (event) { … })” ? So you kind of have to manually break your function up into a state machine composed of event handlers? How do you associate a given HttpResponseEvent with a specific HttpRequestEvent?
So yes, your event loop processes the results of asynchronous work launched because of earlier events the same way.
Part of what makes this work, is the awesome function clause matching. Coordinating origin of async work and result of async work is really easy because you can match on any form of terms your heart desires, and everything is always immutable.
It is a callback of sorts. But most languages do callbacks with some sort of anonymous closure mechanism (or more primitively, pass function pointer/identifiers). What makes BEAM interesting is its prevalence of generalizing callbacks themselves as more events (messages).
You can also define a callback function in, e.g., JavaScript, and pass its name instead of an anonymous closure. Does "BEAM" do anything that JavaScript can't or doesn't?
There are a few very large features that BEAM offers that, as far as I can tell, no other industrial language/VM implements. In particular, BEAM is meant for distributed computation.
You can spawn new processes, communicate between processes (which don't have to be on the same computer), sending any kind of data between them including closures.
BEAM also has an error model designed to handle concurrent and distributed failures, e.g. a process may fail and another process (which, again, may or may not be on the same machine) monitoring it may decide to restart it, or to do some recovery, etc.
BEAM builds into it a number of the features for which we use orchestration, observability, just simpler and (generally) more flexible. And this is a platform that has been used in the industry since the 90s.
I assume they're doing "Structured Generation" or "Guided generation", which has been possible for a while if you control the LLM itself e.g. running an OSS model, e.g. [0][1]. It's cool to see a major API provider offer it, though.
The basic idea is: at each auto-regressive step (each token generation), instead of letting the model generate a probability distribution over "all tokens in the entire vocab it's ever seen" (the default), only allow the model to generate a probability distribution over "this specific set of tokens I provide". And that set can change from one sampling set to the next, according to a given grammar. E.g. if you're using a JSON grammar, and you've just generated a `{`, you can provide the model a choice of only which tokens are valid JSON immediately after a `{`, etc.
