nickmqb

9 ms·

31.
Using libclang to generate C bindings for Muon(nickmqb.github.io)
2 points by nickmqb 7y ago|0 comments
32.
Using libclang to generate C bindings for Muon(nickmqb.github.io)
2 points by nickmqb 7y ago|0 comments
33.
by nickmqb 7y ago
I agree that Muon's current handling of whitespace is not ideal. I have plans to allow users to customize it. For now, you can use the //tab_size=N directive as documented here: https://github.com/nickmqb&#x2F
34.
by nickmqb 7y ago
One design decision that comes to mind is Muon's significant whitespace. Having that makes it much easier to do parser error recovery, which in turn made it easier to build the language server. Another one is that I initially had the r
35.
by nickmqb 7y ago
My main focus has been on the compiler and language server so far. Next up is a tool for generating foreign function definitions. This tool will make it easier to work with 3rd party libraries. Once ready, I'm planning on writing some
36.
by nickmqb 7y ago
To step back a bit, the way I see it, the main goal as a language designer is to ensure that users can be productive in the language. Many factors play a role here. Language features are an obvious one, but there's also (in no particul
37.
by nickmqb 7y ago
I didn't look for any resources beyond the LSP spec and VS Code documentation, so I can't offer any recommendations here I'm afraid. That said, looking back I'm pretty happy with the choice of using VS Code as the initia
38.
by nickmqb 7y ago
Author here. I wrote both the language server and Muon compiler [1] from scratch. The language server reuses the compiler code, for parsing and type checking. I'm not sure which grammar you're referring to? The VS Code extension [
39.
Building a language server for Muon(nickmqb.github.io)
101 points by nickmqb 7y ago|54 comments
40.
by nickmqb 7y ago
> Since each transform needs to perform vastly different image operations, using an enum in this case would’ve forced us to write one massive switch statement to handle each and every one of those operations — which would most likely bec
41.
Building a language server for the Muon programming language(nickmqb.github.io)
3 points by nickmqb 7y ago|0 comments
42.
by nickmqb 7y ago
Most languages today come with a runtime. That makes it hard to interoperate with other languages/environments. To avoid this, a new programming language should either have no runtime (or a very minimal one), or be very explicit about
43.
by nickmqb 8y ago
Thanks! I don't think we should lose the braces. Braces help avoid mistakes when refactoring/copying/pasting code, and they make the language look more familiar to people coming from C-like languages, which I think are large
44.
by nickmqb 8y ago
Done :) https://github.com/nickmqb/muon/issues/2
45.
by nickmqb 8y ago
1. That's true, I didn't mean to imply that transmute is equivalent, there would definitely be benefits to the feature you're suggesting. But it also brings additional complexity of course. 6. Sorry, I totally missed that par
46.
by nickmqb 8y ago
Short term, I have some tools planned for automatic generation of foreign function definitions based on .h files (currently you have to do this by hand, which is tedious and also somewhat error prone). Long term, I agree that a package&#x2F
47.
by nickmqb 8y ago
Thanks! 1. Right now, you can emulate this with the transmute builtin function. Not yet sure if the additional complexity of this feature would be worth it. 2. Array bounds checks can be avoided by using the unchecked_index builtin. Uniniti
48.
by nickmqb 8y ago
Sibling comment (granzymes) is correct, also see implementation here: https://github.com/nickmqb/muon/blob/d557c18d2dcd3fc15a7a7a6... In Muon, you can always add more functions to an existing namespace, so if
49.
by nickmqb 8y ago
Thanks! See my comment re: whitespace here: https://news.ycombinator.com/item?id=19599908
50.
by nickmqb 8y ago
You're correct that Muon wouldn't catch that bug, but I think one can make a pretty strong case that it's an anti pattern to use unsigned integers for that kind of stuff anyway. It's actually the reason that the Muon sta
51.
by nickmqb 8y ago
That's entirely fair game, good luck to us both! ;)
52.
by nickmqb 8y ago
I'm not yet convinced to make it absolutely required, but some kind of warning/linter message would definitely be useful for this.
53.
by nickmqb 8y ago
Hey Andrew, I really like your work! In addition to the Muon compiler I'm still maintaining a C# interpreter which is used for bootstrapping (just so there's always a safe bootstrapping path), so there's some extra work there
54.
by nickmqb 8y ago
I'm not sure that I follow you, just to clarify: Muon.ssize == Rust.isize == Go.int ('usually', according to https://tour.golang.org/basics/11 ) Muon.usize == Rust.usize == Go.uint Muon.long == Rust.i64 =
55.
by nickmqb 8y ago
I agree that Rust takes the right approach. Muon follows it, the corresponding types are ssize and usize.
56.
by nickmqb 8y ago
I'm not sure if I understood your question correctly, but lowerCamel vs snake_case is not guaranteed to be different right? E.g. if you have an identifier consisting of a single word. I'd recommend using UpperCamel for namespaces&
57.
by nickmqb 8y ago
The main difference is simplicity. D has a lof of features, like classes, inheritance, exceptions, properties, etc. Muon is a much simpler language that specifically avoids all of those things.
58.
by nickmqb 8y ago
With regards to your last point, that would be fine. The compiler doesn't care about spaces vs tabs after the first non-whitespace character of a line, as that's not relevant to how the code is parsed.
59.
by nickmqb 8y ago
Muon always allows you to specify a return type for clarity, though. The key point is that you have the option not to. Not all code is created equal. For library functions that are used by many others it is probably a good idea to add expli
60.
by nickmqb 8y ago
Yup, the type names for integers (byte, short, int, long, etc.) are borrowed from C#. All primitives in Muon have a well-defined, platform/architecture independent size. Two exceptions: ssize and usize (machine word sized integers), wh

More ›