Java-esque inheritance - single inheritance with method overriding.

This should have a corresponding .mli file and contain Ocaml types for the expression and class / trait definitions.

(To be used for the subsequent type-checking and interpreter stages).

Use a capture checker of sorts - the idea being that new Foo() is an un-captured object, but let x = (new Foo()) is captured (owned by x).

So check let exprs -> let x = e in ___ is only allowed if either e is not a linear object, or if e is an uncaptured linear object.

Given the path to a file as a command-line argument, read in the text from the file as a string.

while (cond) { }

For now, methods will be associated with classes rather than traits (since diverging from the type system Kappa to use regions)

Blog posts: https://blog.janestreet.com/ironing-out-your-development-style/ https://blog.janestreet.com/testing-with-expectations/

Repo: https://github.com/janestreet/ppx_expect

This drives the computation until the first thread has finished executing - reduced to a value.

This should print the computation state -> expression and bindings in stacks and heaps

Rewrite dune files so one library for each folder, rather than the verbose "one library per module" approach used (not the right approach).

i.e. for ints

+ - * / % < <= > >= (where / is integer division e.g 7/2 = 3)

and for bools

&& ||

and for both
!= ==

Abstract Address type as well as ability to allocate object on the heap (generate new address type)

These will be used for E2E testing (as well as any unit/integration tests involving the lexer).

This gives the option of running programs with data-races in them in the interpreter.

-allow-data-races 

Replace Base.Format with fmt.Fmt

This skews the test coverage massively - so only 60ish% overall rather than 95-100% test coverage.

Fix: exclude parser.ml

Rather than managing thread pool and scheduler manually.

Might not be necessary if only small programs.

Currently Circle CI is not deploying documentation to https://bolt.mukulrathi.com

Odoc only builds docs for the public libraries - so it isn't generating documentation files for each of the .mli files (worth switching to ocamldoc?).

This could be used to demonstrate the expressivity of the data-race type-checker.

Rather than operating on the typed AST output, translate the expressions into instructions for interpreter.

Env maps vars -> values
Should also have helper functions to get/set/update environment.

This will be useful when debugging

Chooses which thread to run the next step of computation on

Currently running the entire suite of programs for each of the stages - parsing, type-checking, checking data-races, interpreter. This is very slow.

Improvements

• If a program fails the preceding stage (e.g. parse error etc.) then don't run it for this stage
• look at flakiness of data-racey programs with the interpreter e2e test
• rely more on unit tests than integration tests and reduce the overall program suite to more interesting examples. (Potentially longer more complex programs)

E.g. src/parsing/ast_types.ml is shown in coveralls as src/ast_types.ml - this means you cannot click on file and see the per-line coverage.

This is likely due to the (copy files) stanza used in the dune build file - which during the build puts all files in the same src/ folder for easy referencing of modules.

if () { ... } else { ... }

Currently using v1.1 of dune - worth switching to v2.0 since that's what the most up-to-date documentation refers to.

A simple way of ensuring this would be to filter out var bindings to "thread" objects in the env of e2 in finish{ async{e1} async{e2} };e and then infer the type of the e2 to see if still type-checks.

Could also check that free-vars of e2 don't contain thread vars.

Matter of style:

This is more in line with Java - closures aren't really used in OOP and it's much cleaner to define all the functions beforehand as

function int f (int x) { 
        x
}

rather than

 let f = fun x:int -> x end in   
        ....
end

This consists of a set of utility functions that allow look-up of types in the environment
E.g. Var -> Type mapping, Class_name -> Class defn mapping etc.

Tokenise syntax - for a given Bolt program file, read it in and output a stream of tokens.

e.g. when applying an int as a function (shouldn't be allowed)

Matter of style - simillar to ES2015 JS:

{
let x = 5;
let y = 6;
....
}
(* x and y not accessible in this scope *)

is cleaner than

let x = 5 in 
  let y = 6 in
      ....
  end
end

These will be used by ocamlllex when parsing program.

This could be enforced by removing free variables in the first expression from the environment of the second and then running type-checking on second expression using the reduced environment.

classes can override the capability modes.

So can override AbstractCounter with LockedCounter and LinearCounter etc.

Core type-checker should return the updated env after having inferred the type of an expression, since the env may change (e.g. x now is a dangling pointer after consume x).

Currently these are not being caught by the type-checker - resulting in a run-time error.

Performs one step of computation

Again, similar to parsed_ast.ml - just adding type information to structure.

Use trait definitions to check well-formedness of class definitions - i.e. if all required fields match up, no duplication of fields etc.

Likewise, check that traits with capability read have only const fields.

Similar to PPrint_past.ml, only it would print the AST after type-checking.

Pass -verbose as command line option to main program

Create lexer using Ocamllex