Some things simply cannot be collected when using reference counting, and even though GC is less predictable, that's not really something you worry about in high-level languages such as Mica.

The current test runner relies on a built version of mica to run its tests and on a bash-like shell. This is suboptimal since rust already provides a good framework, which also allows for parallel testing.

To make use of this, I added a custom rust test runner, making use of libtest-mimic to emulate the base behavior of cargo test.

This test runner loads all mica files from the tests folder and then runs them as actual tests with output, etc. It also identifies each test by using it's containing folder.

To enable skipping of long tests (like with stress-1 or 2) it is possible to add a .skip extension to stop them from running by default and only run them when using cargo test -- --ignored.

It is also possible to add basic exception testing. The example is failing.ml, in which we assert a false value and then check that the output contains the text "assertion failed". This is currently still pretty limited, but it would definitively be possible to expand this (i.e. by using .err files or sth. to compare more complex error outputs)

One thing that always annoys me in Lua is that when errors due to type mismatches occur, they usually appear really deep in the call stack unless you prepared yourself with all the appropriate assert(type(x) == "number", "argument x must be a number") which is very verbose and repetitive to write.

As such I think Mica should have an option to add type annotations to function arguments.

Syntax

func name(x: T)

The func syntax is augmented to accept an expression after a colon : for all parameters, specifying the constraint for the parameter. This syntax is optional for each parameter and propagates across parameters. For instance:

func sin(x: Number)
  x.sin
end

The constraint is any value that implements the Constraint trait, defined as:

trait Constraint
  func check(x)
end

The argument check receives is the argument received by the function, and the returned value's truth defines whether the constraint is satisfied or not. The returned value can also be a (false, String) tuple. In this case the returned string is used as the error message, formatted like type mismatch at argument N: <message>. Otherwise, the error message is type mismatch at argument N: expected T, but U does not satisfy the constraint, where N is the argument index (starting at 1), T is the constraint's name (Debug) and U is the name of the received value's type.

All types (but not their values) implement Constraint by default, which simply checks if a value satisfies the given type.

Implementing Constraint on custom types

It should be possible to override Constraint for custom types, to implement range checks and the like. For example, a user-defined Range type could implement Constraint to check for values within a specified range.

struct Range

impl Range
  func new(min, max)
    @min = min
    @max = max
  end

  as Constraint
    func check(x)
      if !(x >= @min and x <= @max) do
        # Assuming the ~ operator is used for concatenation in the future
        (false, "value outside of of range(" ~ @min ~ ", " ~ @max ~ ")"))
      else
        true
      end
    end
  end
end

# A shorthand:
func range(min, max)
  Range.new(min, max)
end

In practice, this would be used like so:

func do_stuff(x: range(1, 10))
  print(x * 1000)
end

do_stuff(1)
do_stuff(11)  # error

This only happens in the REPL, and only sometimes.

> "a"
> "a"
> Gc.collect

Here's some fish code that reproduces the issue reliably:

#!/usr/bin/fish

while true
  printf \"a\"\n\"a\"\nGc.collect\n | ./target/debug/mica
  if test $status -ne 0
    exit 1
  end
end

Currently Mica has no way of storing sequential or associative data. For that, we're going to need List and Dict types.

A List is an ordered sequence of elements (in Rust speak, a Vec.) This name was chosen because it's more beginner-friendly; after all, why "vector"? As far as I can tell it just lists things.

A Dict is basically just a Rust HashMap but with dynamic typing. This name was chosen because what the heck does "hash" mean, and as far as a beginner is concerned a map looks like this: (Image courtesy of Google Maps)

Dict is short for dictionary which has one common meaning.

Constructing lists

Lists are constructed using square brackets [], which become a prefix token. Elements are comma-separated expressions.

my_list = [1, 2, 3]

list_literal := '[' (expression (',' expression)* ','?)? ']'
prefix := list_literal

Constructing dicts

Dicts are also constructed using square brackets, however they use a: b pairs rather than single elements.

my_dict = [
  "pi": Number.pi,
  "e": Number.e,
  "two": 2,
]

dict_pair := expression ':' expression
dict_literal := '[' (dict_pair (',' dict_pair)* ','?)? ']'
prefix := dict_literal

I chose to use [] instead of {} because everything can still be parsed predictively, and curly braces can remain reserved for tuples (#22).

As far as new syntax goes, that's it.

Accessing elements in the new data types

Elements in lists and dicts can be retrieved using the get/1 method. There is no indexing operator, because I want to implement traits first (#38) before adding any new operators into the syntax. Likewise there is no joining operator.

Other methods available on the two types should follow what Rust offers with Vec<T> and HashMap<K, V>.

It would be nice if we had a way of implementing default functions in traits. However, with the current syntax we run into ambiguities:

trait Name
  func my_required_function()  # How do we tell if this is a prototype or a default implementation?

  func my_default_function()
    10
  end
end

To alleviate this, a delimiter needs to be introduced after function declarations. The natural option is requiring a do..end block:

func example(x) do
  print(x + 1)
end

I don't think it looks half bad in item context, but it's a little worse in anonymous functions:

do_stuff(func (x) do x + 1 end)

So an extra version for single expressions should be introduced, making use of = after the argument list.

func add_one(x) = x + 1
do_stuff(func (x) = x + 1)

This version does not require an end. Of course, this leads to two stylistic choices that codebases can adopt:

func add_one(x) do
  x + 1
end
# or
func add_one(x) = do
  x + 1
end

But I think it's better to leave this to individual preference rather than make it a hard error.

Declaring structs ahead of time is a necessity for supporting mutually recursive types, but most types aren't mutually recursive. Therefore it would make sense for struct Name to return the created type in addition to binding it to a variable Name.

Combined with Mica's flexible impl blocks, this would allow for the following idiom:

impl struct Vector
  func new(x, y) construct
    # ...
  end
end

Currently the only string literal available is "abc", which is inconvenient for a few use cases:

• No way to disable escape sequences
• No way of writing ASCII characters, akin to Rust's b'a'
• Hard to store code in literal strings

Therefore I propose the following new literals:

• Double-backslash like Zig:

  code =
  \\Hello, world!
  \\This is a multiline string literal.
  assert(code == "Hello, world!
  This is a multiline string literal.")
  

  • This gives the developer nice control over the indentation level of content inside the literal.
• ~~ASCII character literals: assert(\a'a' == 97)~~ not needed if we have code points ↓
• Unicode code points: assert(\u'ć' == \x107) - also needs a complementary String.nth_code_point method
• Raw string literals: \r"C:\Windows\calc.exe"
  • We use a backslash before the r because I'd rather not have the lexer have to branch on identifiers or do other funny stuff.

After debating the whole idea with myself I have decided that standard library-level traits have too many drawbacks, and we need a proper language-level solution.

Defining a trait

A trait is defined using the trait keyword, followed by the name, followed by a list of function heads, terminated with end. A function head is the function's name, parameters, and calling convention, without the implementation. Only the instance calling convention should be supported for now; static functions can be added in later (probably after the GC and type are implemented). For instance, the standard library will define an Iterator trait for for loops:

trait Iterator
  func has_next()
  func next()
end

trait := 'trait' identifier function_head* 'end'

Implementing a trait

A trait can be implemented by any arbitrary type, by using the as keyword inside of an impl block. For instance, to implement Iterator on a user-defined Repeat struct:

struct Repeat

impl Repeat
  func times(n) constructor
    @n = n
  end

  as Iterator
    func has_next()
      @n >= 0
    end

    func next()
      i = @n
      @n = @n - 1
      i
    end
  end
end

impl := 'impl' expression impl_item* 'end'
impl_item := func_item | as_item
as_item := 'as' expression func_item* 'end'

Calling into trait methods

For calling methods defined on traits, we can reuse the existing method call syntax. Combined with creating a struct full of static shims that call the actual method to represent the trait, we can use the syntax Iterator.has_next(repeat) to call the method has_next on repeat's implementation of Iterator.

I considered a few other options:

• repeat.Iterator.next - can be ambiguous if there are multiple traits with the same name implemented by a type
• repeat.(Iterator).next, repeat.as(Iterator).next, (repeat as Iterator).next - all function the same way; they do a lookup of what next should mangle to given the trait Iterator in order to call the appropriate method on repeat, but that's unnecessary runtime work that can be done during compilation. In order to understand why the extra work is needed, we need to delve deeper into the implementation details…

The implementation

Traits should reuse the existing dtable mechanism, mainly because it's very fast (finding out a method's implementation is just an array lookup). The way this should be implemented is that function signatures get one more bit of mangling information - the ID of the trait a method is attached to (assuming that on creation a trait receives a unique ID).

The reason why the three options I presented will be hard to implement, is that we need to find out the ID of the trait at runtime. But the trait ID is known during compilation, and as such each shim method in the trait knows the ID too, so the method ID can be precomputed at compile time.

Right now it's possible to call Rust functions from Mica, so it should be possible to go the other way round - calling Mica functions from Rust. Right now the only way is to execute a chunk that calls the function with the desired parameters.

Right now assigning always returns a value, regardless of whether the value is actually used. This causes a lot of unneeded value cloning, which can be reduced by introducing separate opcodes for handling "sinking" assignments (those that do not clone the value but rather move, or sink it into the variable). The compiler has all the context it needs to know whether the result of an assignment is discarded or not.

Currently there's no way of telling whether you're creating a variable, or assigning to an existing one just by glancing at the declaration. This leads to more terse code, but it also creates code that is harder to reason about.

While I do quite like the current syntax:

{ some, library, function } = require("test.library")

i = 1
while i < 10 do
    i = i + 1
end

I believe let would make the code much easier to reason about in large scripts:

let { some, library, function } = require("test.library")

let i = 1
while i < 10 do
    i = i + 1
end

On an even more practical note, let also solves a syntax ambiguity that might throw people off with destructuring:

a = 1
do
    (a, _) = (2, nil)  # is `a` assigned to, or is a new `a` created?
end

Since pattern destructuring is going to be exclusive to let (for now), the above will no longer be ambiguous:

let a = 1
do
    let (a, _) = (2, nil)
end

aka. decoupling stuff into smaller parts.

The plan is to split the monolithic Engine into many smaller components:

• There'll be a new Engine that only contains an Environment. It will be used for compiling Scripts.
  • Scripts will no longer hold a mutable reference to the engine, and instead will use a unique ID assigned to the engine at its creation to ensure correctness.
• Engines will also be used for creating Isolates, which will be the actual execution environments.
  • An Isolate is like a reusable replacement for a Fiber, except as the name suggests - it's completely isolated from other isolates. Each isolate has its own GC and global storage.
    • Scripts will no longer be able to write global variables, only read from them. Global variable shadowing will also not be allowed.
      • I'm also considering making global variables be part of the Engine, because hey they're immutable anyways. But we'll see how that goes.
• In addition there will also be a Registry type - a dynamically typed storage container, basically a HashMap<TypeId, RefCell<Box<dyn Any>>>.
  • There will be two registries: the static registry (part of the Engine,) and the isolate registry (one per Isolate). Foreign functions will have a way of accessing these registries and mutating what's inside them.
  • This mechanism will be modeled to fit the requirements for implementing require.

This function would simply return whether a type implements the provided trait.

trait Example end

struct MyType impl
  func new() constructor = nil
  as Example end
end

value = MyType.new
assert(implements(value, Example))

Hi,

I am working on a classical RPG Creator in Rust at https://github.com/markusmoenig/Eldiron. I am currently using Rhai for scripting but it's slow, I cannot use Lua etc. because it does not compile to WASM (I mean you can compile it to WASM but you cannot communicate with it).

I like Mica, do you think it is ready for production ? I am half-way through my project so if I would want to switch it is now :)

Cheers