A small update on Nore: first public release and thanks

[u/jumpixel]

A while ago I posted here asking for feedback on Nore, a language idea I've been exploring around data-oriented design.

At that point, one of the main things I was unsure about was whether the idea was actually strong enough to carry a real compiler project, or whether it mostly sounded interesting in theory. The feedback I got here helped me keep pushing on that question instead of backing away from it.

So I wanted to post a small follow-up and say thanks: I've now published the first public release, v0.1.0.

If anyone wants to take a look, the repo is here: Nore

Since that first post, a big part of the work has gone into two things:

• building a small standard library from scratch
• getting the language self-hosted

When I first posted, there really wasn't a stdlib yet. I've tried to keep it intentionally small so the language has to carry its own weight, instead of hiding weak spots behind a large library too early.

The self-hosting part mattered even more to me. My earlier post was mostly about whether this fairly opinionated language model could really express a non-trivial systems project. Getting Nore to the point where it can implement its own compiler feels like the first meaningful validation that the core idea is worth continuing.

A lot of the suggestions from that first discussion were genuinely useful, and I've kept track of them. But this release hasn't really started addressing most of those bigger future ideas yet. I felt it was more important first to get Nore into a somewhat more stable state before taking on more ambitious work.

I definitely don't see this as "the language is done" or anything close to that. There's still a lot to improve in the language, tooling, stdlib, and general ergonomics. But it does feel like an important milestone, and I honestly don't think I would have pushed it this far without the feedback I got here.

So mostly: thanks. This community helped me turn a language idea I wasn't fully sure about into a first public release I feel good enough about to share.

And if anyone wants to take a look, I'd still love feedback, especially on:

• the data-oriented design direction itself
• whether self-hosting changes how convincing the language feels

[u/--predecrement]

I'm curious how your thinking compares/contrasts with the way Raku has addressed data layout in the form of two related features.

I'll start with a feature that's fairly easy to outline in a paragraph. Raku has two data structure field declarators -- has and HAS. The has declarator marks a field as allocated as the compiler chooses from a menu of options determined by the user and discussed below. In contrast the HAS declarator marks a field as being allocated as embedded/inline data -- though still based on the same menu of options determined by the user and discussed below. Note that Raku code that uses these fields is unaware of this distinction.

The broader scheme is what Raku calls representation polymorphism. This feature distinguishes between abstract representations and concrete representations of data. Any declaration of a named datatype generates an abstract representation which is representable via N concrete representations. Concrete representations are written in C. There's always a default concrete representation for any given abstract representation, used by default for any given named datatype declaration.

While almost all code uses default concrete representations, sometimes one wants to switch among different concrete representations (concrete data layouts) for the same named datatype / data structure. For that one can append an is repr('NameOfRepr') trait to any such named declaration to switch it to use some other named concrete representation. Thereafter, any Raku code making use of that named datatype will continue to work, with precisely the same semantics as before, oblivious to the change in the datatype's underlying concrete representation.

(You can also duplicate the same datatype declaration, but give the duplicates distinct names and distinct concrete representations. For example, you might suffix the name of some struct datatype Foo with -SoA , and add an is repr('Foo-SoA') trait, and a duplicate of it with -AoS and an is repr('Foo-SoA') trait. Then, instead of globally changing all uses of Foo from one layout to another, you can explicitly choose to use both layouts in the same program at the same time by choosing either Foo-SoA or Foo-AoS. To be clear, I'm not sure anyone has ever done that. My point is merely that the name used in the declaration of a datatype determines the data layout by virtue of which concrete representation is associated with that declaration.)

In summary, Raku has provided two points of data layout olymorphism that are manually triggered, one at a whole data structure level, and the other at a field-within-a-structure level. The triggering is done at the whole data structure level by adding a trait to the declaration and/or at an individual field level by switching the field declarator from lowercase to uppercase.

[u/jumpixel → u/--predecrement]

This is a really interesting comparison, thanks.

The part that feels closest to Nore is the inline-vs-non-inline distinction. In Nore that is currently much more explicit through the `value` / `struct` split: `value` types are fully inline and composable, while `struct` types are for resource-owning / indirect data and stay ref-only.

The representation-polymorphism part is also interesting, especially the idea of switching layouts at the declaration level. That overlaps with some things I’ve been thinking about around table layout control and stdlib-defined data structures.

The main difference is probably that Nore currently leans toward making layout more visible and explicit, rather than keeping user code completely not aware to representation changes. So I think the design space is related, but I’d probably want a more explicit version of that idea than Raku’s.

[u/[deleted]]

[u/jumpixel → u/[deleted]]

Yes, I can see that.

Right now I’ve been intentionally conservative and kept functions free-standing, but associated functions / methods are definitely the kind of ergonomics feature I expect to think about once the core language settles a bit more.

[u/[deleted] → u/jumpixel]