kevinbarabash / compiler Goto Github PK

2.0 3.0 0.0 770 KB

JavaScript 0.07% TypeScript 98.11% Nearley 1.83%

compiler's Introduction

compiler

The goal of the this project is to implement a language with similar syntax to JavaScript and Hindley-Milner style type inference.

References

compiler's People

Contributors

Stargazers

Watchers

compiler's Issues

template string support

String with regular template strings with interpolations. We can constrain the interpolations to only accept strings to start with and can figure out what to do about string coercion, .toString(), and Showables later.

Do something better than setting `.src` on TFun's to "Lam", "App", or "Fix"

There are a couple of issues with the current implementation:

we aren't setting .src consistently
it's awkward to motivate the use "App" for callback TFun's (maybe tagging its .use as "Callback" would be better)

Type classes

spread args support

There are two sub-cases of this:

spreading a tuple (should work with variadic and non-variadic functions)
spreading an array (should only work with variadic functions)

Intersection types

This is mainly to support:

defining common properties across a discriminated union
function overloading

Pattern matching

Type refinements

Using if statements to change the type of a variable within the then block, e.g.

x: number | undefined
let y = if (x != undefined) {
   x + 5;
} else {
   0;
}

We can shadow x within the then block by setting its type to number in the ctx.env for that block.

This should also work on deep refinements, e.g. if (x.y.z != undefined).

Conditional types

Generate bindings from .d.ts files

We want to be able to generate bindings from existing sources so that we don't have to write them by hand.

Infer TData and TVariables from `gql` tagged template literal

Given a GraphQL schema and a query/mutation defined using gql we should be able to infer the type of the response and variables (if any are required). Eventually, this could evolve in a plugin architecture for the type system. The key aspect is that the plugin is provide an inferred type based on a string. A more complicated plugin architecture would provide a way for it to also generate a set of constraints for any interpolated values. It could return these constraints in the form of a custom TFun for each call since the number of params would have to match the number of interpolated values.

Generate TypeScript types from compiler code

tagged template support

For this the interpolations can have types that differ from string.

Optional params

Optional params should be modelled as T | undefined. Need to update unifyFuncs() to look for optional params when deciding whether it's partial application or not.

Update partial application to support application of params at any position

Given foo(a, b, c) it should be possible to do things like foo(5, _, 10) and have it return a function accepting a single param of type typeof b.

Nested member access

It should be able to handle things like:

a.b.c
x[1][2][3]
a[0].b[1]

Optional chaining

a?.b?.c should have the type typeof c | undefined if either a or b can be undefined.

varargs support

Only the last param can be varargs. Any args that are passed this way will be passed to the function as an array. inferFuncs will need to be updated to handle this. We also need a way to mark a param on TFun as variadic. We could introduce an ERest node for this (and then reuse it for object/array/tuple rest).