Various questions about the language

[twitchyliquid64]

First of, awesome stuff! I hope to try this out for some embedded shiz sometime in the future.

I have a bunch of questions from the documentation.

Significant Whitespace

Statement blocks are created via indentation, i.e. using significant whitespace (like in Python). In addition to that, redundant { and } are required.

So we need both indentation & curly-boiz? Which one does the parser actually recurse off? Also does the presence of a carriage return (ie: Windows) affect where a line is considered or count towards the indentation?

Choose either tabs or spaces and stick with your choice. If possible, configure your editor to convert spaces/tabs on paste, so you can easily copy paste code fragments.

Does this work for any unicode space code point or only single-byte encodings?

Type / function declarations

Unlike Go/Rust, in Muon it appears you declare a function/structure by starting with the identifier first: Thingy struct {. That seems like that makes the state space massive when parsing a new line, and complicate writing highlighters. Is there a mode where we can put a prefix on these?

ie: type Thingy struct { or fn main() {.

UFCs

The doc's say:

Important note: in such functions it is highly recommended to not let the first parameter escape the function (i.e. store it in a place where it may outlive the function call).

Why thou?

Thanks!

[nickmqb]

Hey, thanks for your interest in Muon!

The parser uses whitespace to determine the program structure. But Unix-style (LF) and Windows-style (CRLF) line endings are supported (they don't affect the indentation).

Only ASCII spaces and tabs are supported for indentation; unicode characters are allowed inside string literals but they cannot be used for indentation.

Omitting prefixes like "fn" and "type" is a deliberate language design choice; while it does make tooling a bit harder to write, I think it's worth it in terms of code readability.

The reason for not letting an implicit parameter escape a function, is that someone could inadvertently pass a short lived pointer (e.g. pointer to a stack variable), and not realize that the function is actually storing this pointer for use later on. If the pointer gets used later on, that's a memory safety error, which could lead to security issues and is a type of error that is generally hard to debug.