Nothing stopping someone from deciding to migrate VCSs (or even just repos) and all of a sudden end up in the place that 15 years of codebase history is squashed down to a single new starting commit. :(

Don’t forget that most modern version control systems are distributed. The same can not be said for ticketing systems.

On the other hand, ifnt is fun to say outloud.

Huge shout out to Small Computer Central/Steven Cousins. I have four or five machines designed by him, with various main boards and backplanes. The parts are all tested working, and the build instructions are comprehensive. It’s a very enjoyable project to go from a pile of parts to connecting to the UART and blinking some LEDs.

Do you have any written posts or documents about this language and your design decisions?

I gave a talk about the design: https://www.youtube.com/watch?v=wrl9foNXdgM

As the sibling comment mentioned, you can find documentation on Elvish itself on the website https://elv.sh. There are tutorials and (not 100% but fairly complete) reference documents.

What?

I don't come from TS, but this seems like a good intro to zig from that sort of perspective. There's a whole lot of paradigms to relearn when you switch to something like Zig and this kind of content is useful.

I'll nitpick with one complaint though...

    const values = std.AutoHashMap(Point, u32);
    defer values.deinit();
    try values.put(Point{ .x = 0, .y = 0 }, 1);
    //  ~~~~~~^~~~ error: expected 3 argument(s), found 2

> The mistake here isn't on that line, and it doesn't have to do with the number of arguments. Rather, it's that I forgot to call .init() on the hash map

Well...

    >>> class MyType():
    ...    def test(self, a, b): return a + b;
    ... 
    >>> x = MyType
    >>> x.test(1, 2)
    Traceback (most recent call last):
       File "<stdin>", line 1, in <module>
    TypeError: test() missing 1 required positional argument: 'b'

How else do you want unbound functions to behave when you haven't constructed an instance of the type yet? (And FWIW, zls in vscode correctly annotates values as having type `type` for me)

If the type is `type`, and you're missing one argument, and the types of the arguments suggest you're missing the first argument, then that's an opportunity for a much more specific error message.

But before we even get to that stage, I would prefer that "." isn't the syntax for both types of call.

Agreed on both counts. We give C++ a lot of flack for verbose syntax, but separating scope resolution (::) from member access (.) is something that it got right, not a place to cut.

They're semantically similar, but not the same, which is actually exactly the place where you should distinguish syntax. Using parentheses for both expression grouping and function calls doesn't hurt readability much, but using them for both function calls and array access would. This falls more in the latter category.

Yuck. The type itself should be a different type from instances of the type, and therefore that error should be "function not found".

For the first one, constructors should generally do required init, although there are circumstances where that's very hard. Hence the builder pattern.

This is a common pattern in zig and compliments comptime well. It's not supposed to be the constructor for the ArrayList, it's more like a C++ template in that you're constructing a type that then needs to be initialized. There isn't templating syntax in zig though, since you just write compile time code in zig directly (which is really nice).

Also, the type is different and ZLS will insert the hint if enabled.

Yes, the error is much clearer when you realize where the mistake is :)

There's an interesting point here, though: while comptime lets Zig unify function calls and generic type instantiation, this also creates the possibility of confusing the two and getting confusing error messages.

The Unix Programming Environment tutorial for building hoc doesn’t even come close to what Nystrom gets into in Crafting Interpreters. Hoc is a very fun little language, but as Nystrom describes several times in the book…parsing just isn’t the interesting part of the game.

I’ve also ported the lox vm to Zig and had a great time working through it.

Since the project is designed in C, you can mostly write the exact same code in zig, with minimal modifications. If you want to use zig features, they’re easy to integrate, but Nystrom obviously won’t be giving you any hints.

But the language offers a lot of useful features (slices, optionals, error types) and makes some C paradigms syntactic realities (tagged enums, explicit pointer casts). Even more so, the standard library comes with very useful stuff (an ArrayList, a handful of different allocators, heck I replaced the trie of keywords with a StaticStringMap).

it’s a fun project, I would definitely recommend it!

Well, the markdown specification allows inline HTML, so that's to be expected. But it's true if you're taking user input as markdown and display it as rendered HTML, you need to think very carefully about escaping and sanitization.

kens is the author of the write up, not the designer of the chip.