mlatu-lang / mlatu Goto Github PK

Currently you have to define everything in an implicit global namespace. I'd prefer for every file to be an implicit namespace, and you have to import foundation for example, to import everything from foundation.mlt's namespace into the current file's namespace. That's a bad example, because foundation.mlt is always in the prelude, but the point still comes across I hope.

This is in the works, and may replace the current algebraic effect system.

Instead of the current permission-based IO

define print[T] (T -> +IO) {
  show _::mlatu::print
}

Linear types could be used with a World value like Clean does.

define print[T] (World, T -> World) {
 show
}

IO using World is very verbose in Clean because you need to specify the parameters of every IO-performing function call and order the worlds (world1, world2, world3,...). This is made much easier in Mlatu because of the concatenative aspect: you will rarely have to bind the World value to a local variable, and IO functions look almost identical in their bodies to non-IO functions.

Currently Mlatu is always interpreted which makes it rather slow.
I'd rather compile to one of the following:

• Rust (memory safety, gives access to LLVM and Wasm)
• LLVM (extreme portability, optimizations, JIT or compile-time)
• Wasm (browser compatibility, JIT possibility)
• ASM (speed?)

Others could be considered as well, but I more need to decide on one.

The local copy of the license in the README is 404'd.
https://github.com/mlatu-lang/mlatu/blob/main/LICENSE.md

Switch from function traits to type classes, with the following syntax:

class [T] Eq[T] {
   member = [T]  (T, T -> Bool)
}

instance Eq Int {
   define = (Int, Int -> Bool) {
    ....
  }
}

instead of the current

trait = [T] (T, T -> Bool)

instance = (Int, Int -> Bool) {
 ....
}

This will make it much easier to implement constraints and should fix some of the rust codegen problems

Add ability to create record types with the following syntax

record type Foo:
  field a (A)
  field b (B)
  field c (A, B)

which should automatically generate record access methods with like signaatures like a(Foo -> A)
Should be fairly easy (two new tokens, a slightly altered parse function, and similar desugaring, but with different parameters). Depending on how it works, we may need something similar to algebraic constructors as a representation, but otherwise it should be just frontend details.

Error messages are currently pretty awful.
It will probably take a significant amount of work but errors should be much closer to Rust/Elm "compiler errors for human."
https://elm-lang.org/news/compiler-errors-for-humans

A cool feature that could be part of this is to allow the user an editable version of ~3 lines of context around the offending line during a parse error, so the user can easily fix a simple mistake if it exists and recompile.

Add a basic LSP implementation to use in a VSCode or Atom extension/plugin. The lsp package will be useful to this end, and a new executable can be made within the same repository.

There is currently neither syntactic nor semantic support for constrained parameters.

An example:

define print (for t. -> +io):
  show Mlatu.print

In using print, there is an implicit requirement that t has an instance of show. Currently, it is a runtime error for print to be used on a t that does not have an instance of show.

The proposed syntax is something like the following.

define print (for t. t show => t -> +io:
  show Mlatu.print

Edited for correctness and updating of syntax

We need a formatting option to the CLI which will parse a single file into a Fragment, and then write a formatted version of that Fragment back onto the file.