The primary goal of Myst is and always has been to support users as best as possible. For the most part, this has meant defining an expressive, globally-consistent syntax, and implementing powerful features like pattern matching.
But, if you ask anyone who uses a modern compiled or transpiled language what they think the most helpful feature of the language is, they'll likely tell you about the compiler catching errors before the code runs. Not just things like missing parentheses or mispelled keywords, but things like type checking, reachability, and more.
That kind of support is generally known as Static Analysis, and is something that modern dynamic languages have recently been growing into more and more. Some take the approach of creating a new "superset" language (e.g., TypeScript over JavaScript, Hack over PHP) while others like Python are adding Gradual Typing directly into the original language.
Now, I'd like to bring this into Myst directly. Similar to Python, I think the gradual typing approach is best, and being such a young language there's no concern for legacy compatibility, which makes this the simplest option as well.
That said, there are two changes that need to happen to enable static analysis in Myst:
Disallow dynamic type modification (e.g., opening a type within a method). Types can still be statically re-opened, and defining new "anonymous" types within a method could be allowed, but using defmodule or deftype to re-open an existing type from within a normal method would be explicitly disallowed.
Enforce that all necessary components of a program are loaded with static require expressions. In other words, require would almost always need to be given a string literal instead of a variable. It can still be allowed within methods, as require operates as a copy-paste.
I don't see these as being particularly restrictive. In fact, I would almost argue that these are desirable traits in the language to improve clarity and traceability in larger codebases.
Once those two changes are in place, we can start work on a proper semantic phase (a simple implementation already exists in /src/myst/semantic). I'm imagining a two-phase approach. First, Type Resolution to get the final state of all types defined in the program. Then, some implementation of Hindly-Milner type inference for type checking, along with method checking.
I'm not sure how strict things like type checking should be for Myst. I absolutely want to avoid any chance of the type system getting in the way of the user. Elixir seems like a solid reference point to use for strictness.
The primary goal of Myst is and always has been to support users as best as possible. For the most part, this has meant defining an expressive, globally-consistent syntax, and implementing powerful features like pattern matching.
But, if you ask anyone who uses a modern compiled or transpiled language what they think the most helpful feature of the language is, they'll likely tell you about the compiler catching errors before the code runs. Not just things like missing parentheses or mispelled keywords, but things like type checking, reachability, and more.
That kind of support is generally known as Static Analysis, and is something that modern dynamic languages have recently been growing into more and more. Some take the approach of creating a new "superset" language (e.g., TypeScript over JavaScript, Hack over PHP) while others like Python are adding Gradual Typing directly into the original language.
Now, I'd like to bring this into Myst directly. Similar to Python, I think the gradual typing approach is best, and being such a young language there's no concern for legacy compatibility, which makes this the simplest option as well.
That said, there are two changes that need to happen to enable static analysis in Myst:
Disallow dynamic type modification (e.g., opening a type within a method). Types can still be statically re-opened, and defining new "anonymous" types within a method could be allowed, but using
defmoduleordeftypeto re-open an existing type from within a normal method would be explicitly disallowed.Enforce that all necessary components of a program are loaded with static
requireexpressions. In other words,requirewould almost always need to be given a string literal instead of a variable. It can still be allowed within methods, asrequireoperates as a copy-paste.I don't see these as being particularly restrictive. In fact, I would almost argue that these are desirable traits in the language to improve clarity and traceability in larger codebases.
Once those two changes are in place, we can start work on a proper semantic phase (a simple implementation already exists in /src/myst/semantic). I'm imagining a two-phase approach. First, Type Resolution to get the final state of all types defined in the program. Then, some implementation of Hindly-Milner type inference for type checking, along with method checking.
I'm not sure how strict things like type checking should be for Myst. I absolutely want to avoid any chance of the type system getting in the way of the user. Elixir seems like a solid reference point to use for strictness.