Tagged unions look simple and useful, but not very compact. As someone who has dabbled in scripting language interpreters, it be would nice to see built-in support for something like NaN-boxing if you're doing a union between pointer types, smaller integer types, and doubles. But I suppose you could it yourself like in C.
The Hare programming language
221–230 of 323 posts
Re: The Hare programming language
#222Tagged unions look simple and useful, but not very compact. As someone who has dabbled in scripting language interpreters, it be would nice to see built-in support for something like NaN-boxing if you're doing a union between pointer types, smaller integer types, and doubles. But I suppose you could it yourself like in C.
The issue with representing them more compactly is that we'd have to make the rules much more complex and we'd also have to depart from the C abi, so while this is something we might look into in the future it's not very likely to happen.
Re: The Hare programming language
#223Earlier quoted context omitted.
Self-hosting is a very last-millennium form of wankage. Back then, a compiler was a pretty significant program, and compiler construction tools weren't mature. Nowadays, self-hosting your compiler doesn't demonstrate much of anything. It takes a lot more than a compiler to prove anything meaningful about your language. Time spent on self-hosting is mostly just time wasted. It mainly suggests you were not really serio…
You are missing one subtle but important flaw in your dismissal: not self-hosting means that your compiler will only be developed by people willing to write C/C++ code, which has practical implications as well as taking away some of the punch from your effort to improve on the status quo.
Self-hosting will only distract you from any "effort to improve on the status quo". And, do you really want people working on your compiler who can't even cope with C++? (BTW: There is no such language as C/C++. Clang and Gcc are both coded in C++.)
Your new language desperately needs libraries that bring it up to a level of practical usefulness. A compiler front end is about the least-useful code you could write in it. Taking a long detour for that says something, but it is the wrong thing.
Re: The Hare programming language
#224Earlier quoted context omitted.
"Optional" means unused or misused until proved otherwise. No checking and no guarantees can be assumed, and if someone tries to deploy an add-on proof assistant I'd expect managers to see programmers who waste time pursuing some warnings instead of making progress on new features.
This is wholly unimaginative, there is a wide window of usage patterns that are not "unused or misused", for example, on by default but off with a project flag, or off when building a dev release but on when building a prod release, and also don't forget my point that many projects simply don't need the level of memory safety that rust provides. For example if you are single threaded and never free, or if you have an…
Reducing concurrency and/or dynamic memory management makes a program easier to reason about for the compiler (and more likely to be correct in practice), not less in need of correct memory management.
I'm "wholly unimaginative" about what variables can be acceptably corrupted; I can only think of deliberately reading uninitialized memory as a randomness source, a case that is easier to prevent (by clearing allocated memory by default on the OS side) than to enable.
Re: The Hare programming language
#225Happy to see “secretlang” out in the open! I have been following development from afar and really like the idea of a “simple” take on a language, but with a lot of wisdom and affordances added since the state of the world back in 1972. In short, Hare seems to be a language that I really should like and I want to take it for a spin. What I find a bit confusing though is the licensing. I belong to the “BSD school”, but…
The licensing model is essentially designed in deference to users who want to vendor standard library modules in their projects. They can do so, and patch them, but have to publish their patches. Then the compiler is GPL because it does not make sense to vendor it.
Re: The Hare programming language
#226Earlier quoted context omitted.
I don't think many Zig programmers miss C macros. Comptime is extremely powerful.
C macros are powerful enough to create entire functional languages at compile time, which is far beyond any constexpr functions. https://github.com/rofl0r/order-pp
If it's at compilation time, you have the full zig language so you certainly could implement your very own functional programming language https://github.com/igmanthony/zig_comptime_lisp in regular zig rather in an external preprocessor.
Re: The Hare programming language
#227Earlier quoted context omitted.
I filter it a bit differently. There are enough people who will check out new language X; I don't have to. If it has merit, I'll keep hearing about it. Sure, I'll miss out on using X the first year or two out of the gate, but I don't actually need that. Yes, if X is all it's cracked up to be, I could have benefited from using it in that year or two. On the other hand, I didn't waste time learning a bunch of new langu…
That is the "ignore everything new" choice. You are pointing out its lack of downside. On many days I would agree. (But you didn't. You spent enough time on it for this.) If in fact the language would have turned out to be interesting, helping out early might make the difference between its fizzling out or getting traction. And, helping out might be a chance to learn a lot, or to ensure it will scratch your itch. In…
> But you didn't. You spent enough time on it for this.
Fair, to a point. But writing an HN comment is a bit lower investment than learning a new language well enough to evaluate it fairly.
> If in fact the language would have turned out to be interesting, helping out early might make the difference between its fizzling out or getting traction.
You may have that kind of pull; I don't. Nobody is going to care whether I like a language or not.
> And, helping out might be a chance to learn a lot, or to ensure it will scratch your itch.
That's somewhat more likely than me helping it gain traction. And, in fact, the earlier the input, the more influence it has at bending the language in the direction you want, because there's fewer voices at that stage. But there are too many potential languages for me to do that with very many of them, so we're back at the problem of choosing which ones to invest in...
(I once did take your approach, with the C++ STL, when was first announced on the newsgroups. It wasn't part of the compiler yet - it was a separate download. I found a bug in the initialization of the random number generator used to random-shuffle vectors. I, some random nobody on the net, emailed Stepanov and Lee, and got three fixes in the next two hours. I was amazed at the response. And the fix made it usable for what I was trying to do with it.
I think that's the only time I've invested in something brand new, though...)
Re: The Hare programming language
#228Earlier quoted context omitted.
To distinguish between an instance and a namespace? The same can be said for why do we need to put parenthesis after functions that take no parameters? So people still know it's a function.
But why not use a single character? With the double colon, something like foo::bar(xyz) looks like bar is “closer” to xyz, when in fact it's closer to foo.
A single ':' is used for other things, like casting types.
let x: int = 0;
Re: The Hare programming language
#229Will wlroots move to hare? Or will bindings be written and maintained?
I have no plans to do either. I can't see wlroots being rewritten, but I could see someone writing bindings for it. Hare does not make C obsolete, there's no reason to rewrite old code imo.
Re: The Hare programming language
#230Earlier quoted context omitted.
> To distinguish between an instance and a namespace? I’m with OP here. C# proves that . reduces the noise substantially.
Only somewhat related, but when reading docs/comments that mention some method `class.method`, it's annoying when that's ambiguous and could mean either a static method or an instance method. In the Ruby world, I think they have the convention of writing `class#method` in docs/comments when mentioning an instance method, and `class.method` when mentioning a static method.
Fun trivia fact: I tried to bring that convention over to Rust, but enough people didn't like it than in the end, we don't do that.