hexaredecimal / ml Goto Github PK

Currently the tests are garbage and trash needs to go. I have to write meaningful tests, these ones were written in the early stages and they were used to measure the amount of features we support.

Currently the compiler optimizes the imports by importing definitions only once. If they are defined and used in multiple places, it doesn't cause a problem. The problem rises when we import two files that reference each other, the solution is to cache import paths and don't re import at all when the path is already cached.

I should refactor the compiler and user references as much as I can as opposed to cloning. I clone everything in this compiler and that is just bad design. My code proves the point that I am new to Rust. For now the main task is to refactor the code.

All structs fields are public and currently I only use destructuring a way of getting the value stored in any known field. I'm thinking of simplifying the process a bit, by intoducing pointer access using the ->. Think about it, all objects in java are heap allocated and variables store references (So variables are actually pointers in this case) to those objects, so it makes sense.

struct Foo(baz: Int)

fun main(): Unit => {
  var bar = Foo { baz: 100 }
  println(bar->baz)
}

I am planning on adding a feature which allows the programmer to lift types from java using the type alias mechanism. This is how it should roughly work.

type Window = "JWindow" (* This will allow us to create bindings for external libraries *)

Type aliases will work hand-in-hand with functions that use the java block as a way to case effects to the state of the application

Currently the compiler emits invalid Java code when another if expression is used in the body of the if expression. So the following code passes on the compiler but generates the wrong code.

if true then {
   1
} else (* body of the else *)
   if true then { 2 } else { 3 }

Since the JVM backend is now working about 80% of the time, I am planning to add more backends. I would like to add backends that take advantage of all types in SMLL. Currently there are types which are disabled because they have no implementation in Java and they cannot be represented as Objects. Moving to a native platform will definitely improve performance. Here is the plan for going native.

1. Support many platforms without using llvm, but start here.

• QBE Backend - Default for native
• PIC16 Assembly
• UXN