Thank you for the link to Infra @Garth Goldwater. I hadn't come across this before. I went on a little rabbit-hole and it looks very promising! It doesn't seem to have been updated since 2017, any idea if it's still active? I think I'll email Chris to see what its status is. (Is it the same @Chris Hall on this server? Apologies for the ping if not.)

I looked into Infra myself, and posted my opinion elsewhere. I'll re-post it here in case anyone is interested:

Ok, so my conclusion after reading the 18 page Infra paper (a condensation of the thesis): there is nothing I can learn/steal from Infra. It doesn't seem to have many new innovations: it's a mishmash of a structured editor, binary format, and programming-by-example system, all of which have traditionally been addressed as separate research areas. It doesn't make a substantial contribution in any of those areas, IMO.

Thanks for adding your take. If the idea is to take ideas to use in your own projects then that's probably true. As a base format, though, it seems like a useful synthesis that would solve/improve a number of present-day problems. I'd consider the editor as separate, but an easily-parseable, compact, recursively self-descriptive, structured data format with s-expression-like "commands" seems like it has a lot of potential for improving user experience without a heavy abstraction cost. If the data has structure then I assume a general-purpose editor would need to be structured as well. (correct me if I'm misusing the term). The current alternatives seem to be a plethora of subpar general-purpose text formats or custom binary formats for each use-case. I'd be happy to be proven wrong here if there are other, better alternatives! 😄 Both Infra and UTF-8 purport to be general-purpose binary formats, but Infra seems to allow for many more use-cases.

all of which have traditionally been addressed as separate research areas

This jarred for me slightly: siloed research presumably has some benefits for investigating orthogonal concepts, but surely at some point the lessons need to be synthesized for real-world use-cases. In order to have a structured editor or programming-by-example system you need to have some format, and a binary format with the above-described benefits doesn't seem like a bad choice. (I'm open to being corrected here btw)

I think its awesome work. I’m seeing a lot of parallels between this and what we are working on. Especially the notion of patch based commands for derivative structures from trees and graphs. A few observations: 1. this is a great fit for WASM. The heap format for WASM can mirror this, and there is a strong association with capabilities the host provides (for example, even mathematical computations) 2. Portions of the structure are mappable to virtual dom to provide a good way to do reactive UI’s.

I agree, if you're looking at Infra as a product, then you might determine it has practical utility. However, I'm only interested in Infra as a research artifact, and from that perspective I personally don't find it very interesting.

In order to have a structured editor or programming-by-example system you need to have some format, and a binary format with the above-described benefits doesn't seem like a bad choice.

A structured editor (by definition) presents and allows manipulation of the abstract structure of a document (usually, we talk about ASTs). An abstract structure is a format for a human to consume. This is orthogonal to a serialization ("binary") format, which is a format for hardware to consume. A binary format's only purpose is to instruct the computer how to encode data in its transistors, capacitors, electrons and photons. Only low-level engineers (ideally: OS engineers) need to concern themselves with binary formats, and that's why I consider them orthogonal to structured editing. My conclusion: they are best researched separately. If you are making a product, aimed at allowing low-level engineers to manipulate binary formats using structured editors, then that's all well-and-good, but it's not research unless you're doing HCI. (I'd extend my argument to include programming-by-example but this is getting quite wordy.)

i see the conversation that nick and i have been having in DM has spilled into the real world! i’m definitely on the “infra is an important piece of work from a research perspective” side and i’ll just copy paste my latest message from DMs here: i think the core of the infra project is about structural editing done homoiconically. the binary format is just the logical bottom for the homoiconic part. so the reason i don’t see it as a mishmash is that all the structural actions are in the same language as normal data updates. so instead of type.addCase or whatever, you interpret the data structure of a table as representing cases and do a primitive table add when you want to add a case. it’s the same as any other table. having trouble articulating it and maybe it’s something all structure editors have—idk. but infra’s symbol semantics and patch datatype also represent functions in the same plain old data structures—so a function is just a partially interpreted table where some symbols evaluate to themselves. that seems pretty different to me

I agree, if you're looking at Infra as a product, then you might determine it has practical utility. However, I'm only interested in Infra as a research artifact, and from that perspective I personally don't find it very interesting.

👍

i’m definitely on the “infra is an important piece of work from a research perspective” side

re: how novel Infra is from a research perspective: I don't really consider myself versed enough in the current research landscape to have an informed opinion.

An abstract structure is a format for a human to consume. This is orthogonal to a serialization ("binary") format, which is a format for hardware to consume

I would partially disagree. I would suggest that they are correlated insofar as you need the binary format to be capable of (efficiently) representing the concepts invoked by the abstract structure. You need to be able to map your intent into something the machine can actually do, and the strength of this mapping matters.

Only low-level engineers (ideally: OS engineers) need to concern themselves with binary formats

This requires there to be a better higher-level format that other people can work with instead. This seems to be what Infra is aiming to provide.

If you are making a product, aimed at allowing low-level engineers to manipulate binary formats using structured editors then that's all well-and-good

I wouldn't describe either the format or the editor (or the use of either) that way. If you're referring to the editor as the product, I would describe it as aimed at allowing users of a variety of proficiency-levels to view & describe their data in a structured way. The format is the same, but for allowing programmers to create programs that users in turn use to create & browse this structured data. I can't tell if we disagree on the significance of binary formats in general. As I see it, everything on a computer is based on a binary format plus some layers of abstraction/indirection/meaning, so at some level Infra has to be represented in binary. All other things being equal (which of course they tend not to be! 😛), fewer layers is normally better.

binary format is just the logical bottom

☝️

[Abstracting over binary formats] requires there to be a better higher-level format that other people can work with instead. This seems to be what Infra is aiming to provide.

Infra doesn't achieve this abstraction. It allows you to define "unallocated memory regions" in your data structure to enable more efficient modification of the serialized data. In other words, users will still be thinking about the serialization process -- it's not managed by the OS. That's why I describe it as "a structured editor for manipulating binary formats".

As I see it, everything on a computer is based on a binary format plus some layers of abstraction/indirection/meaning, so at some level Infra has to be represented in binary.

Everything on a computer is based on silicon wafers doped with boron and arsenic. We don't need to think about that when we're manipulating data, and we shouldn't need to think about binary formats either -- serialization to binary should be handled by the OS. The only exceptions are when you're doing very low-level software engineering like developing a cryptosystem, a compression format, or a network protocol. Infra can try to be an OS, or it can try to be a data editor, but it should clearly delineate those goals (keeping them as separate layers), or it won't do well at either. At the moment it's asking users to think about binary formats whilst they edit their data.

Ah thanks for explaining more, I think I better understand your objection.

unallocated memory regions

Without creating a new OS, AFAIU the "file" abstraction assumes/requires a single linear block of space. Given that constraint, the option of having blank sections is a useful concession to performance. Hall mentions conceptual layers for Infra in his dissertation (attached image), although I don't think he does in the Onward! paper. The free sections are only significant at the encoding layer, which end users aren't intended to interact with. The tree & graph layers are more abstract.

To be honest, I have no idea what the author is trying to explain with that table. The phrases "encoding layer", "tree layer", "graph layer", and "interpretation hierarchy" (referenced in the text surrounding the table) appear literally nowhere else in the dissertation. At best, I can conclude that the dissertation is poorly-written. (Other evidence to support this: their "related work" section is only 3 pages of text written in a very large font).

The file abstraction needs to burn and die 🙂

haha that could indeed be the solution re layers, yeah I think he's just distinguishing between logical structure & "physical" file layout. I agree it would benefit from some more exposition around this. It's also a little frustrating that a number of the pages on the website that should be describing the format have no content...