alantech / alan Goto Github PK

• random number generator for hashing
• implement Map on top of user defined types and arrays
• Hashable Interface

Eliminate array access and divide by zero exceptions.
OOM would still be possible.

• @std/http
• @std/cmd

Replace union types bdd test

*Result pending potentially a better name

This blocks #11. It is a continuation of https://github.com/alantech/compiler/issues/12. While the pattern described in that issue should work, the implementation path to do so was not, and it currently cannot be done the way "regular" conditional transforms work, because it needs access to the remaining statements in the function and the structure of Microstatements.js does not give it that access.

Write up an RFC for match syntax that is close to the one in StandardML/Ruby/etc but also not unfamiliar to Rust/C#/etc. Ideally one where you can also do Haskell-style "function is match statement on the outside"

We decided to just go the monorepo rout

Needed for http.port

Building on the interface change in #13 there could be a class syntactic sugar:

export class Foo {
  fieldA: string
  fieldB: int64

  fn doStuff(): string {
    return this.fieldA * this.fieldB
  }
  fn merge(other: Foo): Foo {
    return new Foo {
      fieldA: this.fieldA + other.fieldA
      fieldB: this.fieldB * other.fieldB
    }
  }
  infix associative 2 & merge
}

This could be syntactic sugar for:

export type foo {
  fieldA: string
  fieldB: int64
}

export fn doStuff(this: Foo): string {
  return this.fieldA * this.fieldB
}

export fn merge(this: Foo, other: Foo): Foo {
  return new Foo {
    fieldA: this.fieldA + other.fieldA
    fieldB: this.fieldB * other.fieldB
  }
}
export infix associative 2 & merge

export interface Foo {
  fieldA: string
  fieldB: int64
  fn doStuff(Foo): string
  fn merge(Foo, Foo): Foo
  Foo & Foo
}

For this to work, there would be one more change needed. If trying to call new <interface> it should succeed if and only if the interface matches a single type.

Private fields and functions could be simulated by a second type that is not exported and functions not included in the interface nor exported:

export class Bar {
  foo: Foo
  private blah: int64

  fn getBlah(): int64 {
    return this.blah
  }
  fn somethingElse(): bool {
    return this.foo.fieldB > 5 && this.privateCall()
  }
  private fn privateCall(): bool {
    return this.blah * 2 < 10
  }
}

could become something like

export type bar {
  foo: Foo
  privateFields: privateBar
}
type privateBar {
  blah: int64
}
export fn getBlah(this: Bar): int64 {
  return this.privateFields.blah
}
export fn somethingElse(this: Bar): bool {
  return this.foo.fieldB > 5 && this.privateCall()
}
fn privateCall(this: Bar): bool {
  return this.privateFields.blah * 2 < 10
}
export interface Bar {
  foo: Foo
  fn getBlah(Bar): int64
  fn somethingElse(Bar): bool
}

const someArray = new Array<int64> [ 1, 2, 5 ]

becomes

const a = 1
const b = 2
const c = 5
const someArray = newarr(3)
someArray.push(a)
someArray.push(b)
someArray.push(c)

This would let us do things like someObject.innerArray[1].finalValue

Instead of memory for a handler being a pair of data structures, an array of memory for fixed-sized primitives and a hashmap of arrays for strings and simple arrays, it should be a struct housing an array of memory and a hashmap of that same struct, recursively defined.

This might require implementing the Copy trait for this data structure in Rust when an array is provided as the payload to a handler. It would manually grab the hashmap entities and have it recursively repopulate it.

Adapted from discord chat:

In the memory structure right now each memory address is 64-bits wide and all base types except strings fit in it. Strings are put into a Hashmap of a variable length array of data, themselves. This would also work for arrays of ints and the like:

But not for an Array of strings or an Array of Arrays. For that we would need something like this:

An array of strings would have a second dimension it expands into. For an array of array of ints:

Memory is currently a pair of structures: A linear, expandable memory for addressing fixed memory blobs, and a hashmap of addresses to a linear, expandable memory for addressing non-fixed memory blobs

Solution: To implement arrays their Memory is a fractal in the Alan runtime. A struct of linear memory with a hashmap of addresses to new instances of that same struct
then an array of strings, for instance, would first use an array request on a given address, which the opcode would "know" since it's an array opcode should go to the hashmap. Then the request to read a string at a certain offset would similarly "know" to go to that inner hashmap because it is a string opcode and that's where strings reside
but an array of array of ints would do array opcode so request hashmap, then another array opcode, request inner hashmap, then int opcode read from linear memory