Hope this clarifies. Not to miss the forest for the trees, to reiterate, the main takeaway is that it may be better to define and use a specific tag to pinpoint a sequence of events in a given period (e.g. settecento) instead of gesturing with something as arbitrary and wide as a century (18th century art).

In other news, is it really a surprise that everything is securities fraud?

Manipulating (e.g. "people who down vote [sic] refuse to believe"), spreading fear (e.g. "[mind manipulation occurs on] an 'industrial' scale"), and inflating one's own ego (e.g. "I am a renegade of thought control") contribute little to the discussion of this article.

That is all.

Wow, you're spending $420 on shipping? How far away are they keeping those slaves?

But seriously, Discourse is good forum software. You can self-host it or pay for a hosted instance. An example instance is IRLO, https://internals.rust-lang.org

Edit: nvm, I read through the rest of the codebase. I see that HVM compiles the inet to a large static term and then links against the runtime.

https://github.com/HigherOrderCO/HVM/blob/5de3e7ed8f1fcee6f2...

Will have to play around with this and look at the generated assembly, see how much of the runtime a modern c/cu compiler can inline.

Btw, nice code, very compact and clean, well-organized easy to read. Rooting for you!

I ask because a while back I was messing around with compiling interaction nets to C after reducing as much of the program as possible (without reducing the inputs), as a form of whole program optimization. Wouldn't be too much harder to target a shader language.

Edit: Oh I see...

> This repository provides a low-level IR language for specifying the HVM2 nets, and a compiler from that language to C and CUDA HVM

Will have to look at the code then!

https://github.com/HigherOrderCO/HVM

Edit: Wait nvm, it looks like the HVM2 cuda runtime is an interpreter, that traverses an in-memory graph and applies reductions.

https://github.com/HigherOrderCO/HVM/blob/5de3e7ed8f1fcee6f2...

I was talking about traversing an interaction net to recover a lambda-calculus-like term, which can be lowered to C a la lisp in small pieces with minimal runtime overhead.

Honestly the motivation is, you are unlikely to outperform a hand-written GPU kernel for like ML workloads using Bend. In theory, HVM could act as glue, stitching together and parallelizing the dispatch order of compute kernels, but you need a good FFI to do that. Interaction nets are hard to translate across FFI boundaries. But, if you compile nets to C, keeping track of FFI compute kernel nodes embedded in the interaction network, you can recover a sensible FFI with no translation overhead.

The other option is implementing HVM in hardware, which I've been messing around with on a spare FPGA.

https://news.ycombinator.com/newsguidelines.html

Satire, in any other universe.

Induction: https://plato.stanford.edu/entries/induction-problem/

     =  500mL
    /_\ 2 cups
    |_| 1 cup 
    |_| zilch

Traditionally, an effect handler is an interpreter for a stream of commands, conforming to a specific interface. Generally, handlers surface in languages as a sort of generalized try/catch mechanism, that receive a "callback" to resume the "exception" that produced the command. In frank, not so.

Frank is based around the idea of operators, which generalize functions with the capability of interpreting multiple streams of commands. A plain function can be seen, in fact, as the special case of an operator that interprets no commands.

Operators are organized around ports and pegs. Pegs are the set of side effects that a computation needs. Each port is an offer to extend that set for downstream callers. Instead of building up a union of effects that each function needs, Frank propogated ambient ability inwards. Operators can then be composed based on the ports and pegs they offer.

operator: X → [peg]Y

This works partially because operators are shallow handlers and not deep handlers. Handlers interpret commands: if the handler itself is in scope when interpreting a command, then the language is said to have deep handlers. Frank has shallow handlers, meaning that commands are interpreted in an environment without the handling operator present. Shallow handlers give greater control to the programmer with respect to how commands are interpreted: operators can propagate ambient ability, or choose not to.

(This is a bad explanation because you already need to know what I'm talking about to understand what I'm talking about, but oh well.)

My one critism of frank is that the effect model is kinda hard for the working programmer to understand. I can explain Koka effects as "exceptions plus multiple resumption". I don't really have a categorical phrase for frank, and that's its innovation. This isn't so much a criticism but a plea for the pedagogical ramp to this research to improve.

do be do be do.

If you're still curious, check out the compiler github repo:

https://github.com/frank-lang/frank

And if anything is wrong in the above explanation, please correct me, because we all benefit from Cunningham's Law in the end. Allow me to be the fool.