Strict doesn't need a lot of keywords, most code is only valid written in one way. Switching arguments or changing code style will make the code usually not longer compile (or at least not behave the same way). Strict keywords are most similar to the go language, Python and C#. For details check the grammar strict.iro file.
You will understand any .strict code you read, writing code is much harder due to all the strict rules ^^
Loops and control flow
Comparsions and Operators
- is (any equal comparsion)
- not (negation)
- as, to (type conversion)
- and, or (english words instead of strange C operators)
- +, -, *, /, %, xor (for math)
- () for lists/arrays, which includes method parameters and method call arguments, there is no empty list (), it is never written and just None. Thus method and method calls must not use empty ().
- let and = to assign initial value
Everything in Strict.Base is always available, everything else you can just import
Strict only allows assignment at creation time, which is when the let keyword is used.
let number = 5 let text = "Hey"
Only mutable types can even change their state, and they are rarely used (linked lists or counts). In this example count, list and index are all mutable, the compiler can still optimize index away, but count and list will prevent this code from running automatically in parallel like all immutable code will do in any loop.
let count = Count(0) let list = List(Number) for index in Range(0, 10) count.Increase(1) list.Add(count)
Any comment is considered bad. Only add comments to methods to explain functionality or link to more information, comments for members, types, inside methods are all not allowed. Like in C, Java or C# comments start with //, no other type of comment is allowed, multiline comments are not needed, if your comment is more than 3 lines, the compiler will refuse it.
Everything is an expression
All statements are expressions in Strict, in fact any expression can be put into a line of code, can be a parameter, part of a if statement or for loop, etc. If an expression stands on its own and returns a value, it must be true, otherwise it will cause a runtime, test and even compiler error immediately.
A Strict package folder looks like this (folder must match project name):
- build.yml (package meta data, autogenerated if missing: author, creation date and special build settings if needed)
- README.md (description, must start with project name header, should contain usage examples of the package and maybe a quick overview of types available, only allowed in main folder)
- .gitignore (is usually empty, but if you really need to exclude files, do it here)
- .editorconfig (defaults to tabs with 2 spaces and the default styling used for Strict, this way all editors will behave the normal way)
- any other file MUST be a .strict file, which defines a type each (class or trait)
- SubFolder can contain more .strict files
Runnable apps must contain a Program.strict file, which defines allows code that is called automatically when the app starts (think main())
has log Log test() log.LastLine() is "Hello World" log.Write("Hello World")
and more at https://github.com/strict-lang