Context

Sonata does not implement, yet, any modularization system that allows hiding internal state to a module. Right now the compiler will let you use any defined class, and this class will be stored in the top-level scope.

Sonata, however, does implement a way to import files with source code based on a include path.

Motivation

Any modern language should contain a painless module system that allows developers to reuse code enforcing their best practices:

• Importing external modules from the include path safely.
• Importing only chosen classes from a file.

Requirements

Sonata is meant to be a simple language, so the module system should be also as simple as possible and opinionated on best practices. There is a minimum set of requirements:

• The developer is responsible of hiding any declaration that is not useful outside the module.
• Importing/exporting definitions should not pollute the language, if possible.

Approach

A suggested approach would be:

• All files in Sonata pertain to a module, by default it will be related to the directory where they are. This would work similar to a Java package.
• Modules have a hierarchy: Given the module std.lib
  • The module std is parent of std.lib
  • The module std.lob is sibling of std.lib
  • The module std.lib.streams is child of std.lib
• Any declaration in a module, is by default public and visible to all modules.
• Declarations marked as internal can only be seen by the same module, siblings and children.

Examples

; src/my/module/foo.sn :: module: my.module.foo
internal let foo() = 1

; src/my/module/bar.sn :: module: my.module.bar
requires my.module.foo
let bar() = foo() + 1 ; visible because my.module.bar is sibling of my.module.foo

; src/my/module/foo/fooer.sn :: module: my.module.foo.fooer
requires my.module.foo
let fooer() = foo() ; visible because my.module.foo.fooer is child of my.module.foo

; src/main.sn :: module: main
requires my.module.foo

foo() ; does not compile, foo() is internal to module my.module.foo

Affected Modules

• The standard library needs to be changed to use the new module system.
• The compiler should enforce visibility rules.

Now actors are reentrant because we are not ensuring the order of consumption. We need to make sure that actors do process messages one by one, and that actors are reentrant.

Right now, NodeDockerTest do not run in Github Actions and fail with a timeout. Find a way so those tests can be run in CI.

Context

Sonata does not implement, yet, generics.

Motivation

We need to support generics to ensure type safety in the communication between entities.

Requirements

Sonata is meant to be a simple language, so generics should be as easy as possible. We want to make sure the following constraints are considered:

• The generic type system should allow any reasonable need.
• Simplicity is key: if something would be complex, redesign or drop it.
• Should not break entity/value visibility constraints.

Approach

A suggested approach would be:

• Type inference should be smart enough to cover most of the reasonable cases where we use generics.
• Generic rules will be based on:
  • value classes can not be inherited
  • entity classes can not be inherited
  • entity classes can implement contracts

So we have the following cases:

• Generic on anything (like collections)
  • We will need to change the ContinuationProcessor to take into consideration generics that contain entity classes.
• Generics on contracts are covariant.
• Generics on entities and value classes are invariant.

Examples

; let's assume a new Bag class:
entity class Bag<T> {
   let put(a: T) = {}
}

; If we use the Bag to store a contract, it will be covariant:
contract Toy {}
entity class Football implements Toy {}
entity class Basketball implements Toy {}
let toys = Bag<Toy>()
; If we use the Bag to store a football, it should work
toys.put(Football())
; If we have a bag to store footballs, only footballs are allowed
Bag<Football>().put(Basketball()) ; fails

Affected Modules

• The standard library needs to be changed to use generics instead of any.
• The compiler should understand generic types on method signatures.
• The compiler should understand generic types when building continuations.

Right now we are not able to compose a function with a method, or two methods together.

Sample code with the issue:

value class Price(amount: number) {
    let format() = '$' + amount
}

let printPrice: (Price) -> any = ?.format() -> println

Compiler output:

[ERROR] [samples\playground.sn:27:34] near 'a.format() -> println': Only functions can be composed.

Motivation

Enterprise applications require a mature and opinionated observability platform, so they can easily monitor their running applications.

Requirements

Approach

Examples

Affected Modules

There are some situations where stopping actors block the runtime. It may be a race condition where an actor can not be stopped because it still has pending messages. However, we couldn't reliably reproduce the issue.