• [x] Always allow assignment to tagged:"any" but don't overwrite the type
• [x] allow call-expression arguments if the corresponding parameter type is any
• [x] if a function signature's return is set to any, return statements need to allow any return values
• [x] apply isAssignemntAllowedin other relevant places: https://github.com/getify/Typl/pull/28#pullrequestreview-207108731

Hi @getify I'm working on eslint plugin for your nice type checker 🌟 .

I'm confused how can I push the errors into the eslint API 😕.

I think that doing it as so in ESLint will give the Developer good experience to integrate with Editors and CI tasks. So I went with 0 rules and I'm trying to use a processor to type check the files and I get interesting data from you checker!

I hope you can guide me a little bit on how I can continue with this approach. Thanks in advance.

Enforce bool type check on if, test condition of for, while, and do..while loops (like in ternary ? : operator).

var i = 3; if(i){ // should report an error }

I made the tests for Array stuff. You will see there are errors happening from tuple onwards.

Basically in a case like this, it finds errors in both assignments, instead of just the bottom one.

var x = array`(int | string)[]`;
x = [ 1, 2, "hello", 4 ];		// OK!
x = [ 1, 2, true, 4 ];			// error

This is because it recognizes the array as type any instead of type of ints and/or strings.

I saw you request code on Twitter for something called "TypL" so, I googled. Interesting use of tagging! I like the idea of this library a lot. But I wouldn't be me if I didn't get curious. 😄

Taking a quick look at TypL makes me wonder if performance won't be an issue. Since it's active at runtime as well, doesn't it call a function for every type (because that's what tags are)? If you have a lot of inline typing (loops with large datasets and such) I can imagine this adding some overhead, especially if you're already working with other libraries that have type validation (like MST).

In the same breathe I'd like to mention file size. Can't that be a bit much, too?

Both of these are of course minor concerns, but I couldn't find much about them yet so I figured... Might as well ask.

Need to support this syntax for annotating an array of values of a certain type:

var x = array`int[]`;
var y = array`int[]``[1,2,3]`;
var z = array`int[]``${y}`;

x = [1,2,3];   // OK!
y = [4,5,6];   // OK!
z = x;   // OK!

Non-empty arrays (by default they're allowed to be empty):

var x = array`int[]``${ [] }`;  // OK, allowed to be empty
var y = array`int[+]``${ [] }`;   // error, not allowed to be empty

Array of various types (union types):

var x = array`(int | string)[]`;

x = [ 1, 2, "hello", 4 ];   // OK!

Multidimensional arrays:

var x = array`int[][]`;
var y = array`int[][][]`;
var z = array`(int | string)[][]`;

x = [
  [1,2,3],
  [4],
  [5,6],
  [7,8,9,10]
];   // OK!

y = [
  [
    [1,2,3],
    [4,5,6],
    [7,8,9]
  ],
  [
    [1,0,0],
    [0,1,0],
    [0,0,1]
  ]
];   // OK!

z = [
  [1,"hello"],
  [2,3,"world"],
  ["ok"],
  [42]
];   // OK!

Tuple, Nested Tuple:

var x = array`<int,string>`;
var y = array`<<int,string>,bool>`;

x = [ 42, "hello world" ];   // OK!
y = [ x, true ];   // OK!

Array of tuples:

var x = array`<int,string>[]`;

x = [
  [42,"hello"],
  [10,"world"]
];   // OK!

Tuple of arrays:

var x = array`<int[],string[]>`;

x = [
  [1,2,3,4],
  ["hello","world"]
];   // OK!

Array of tuples of arrays:

var x = array`<int[],string[]>[]`;

x = [
  [
    [1,2,3,4],
    ["hello","world"]
  ],
  [
    [5,6],
    []
  ],
  [
    [7],
    ["very","cool","stuff"]
  ]
];   // OK!

Very interesting approach! I am wondering wether it is worth adding to the output JS all those extra functions necessary to validate on runtime? What's the mindset on that?

var y = (function foo(x = number){
   return String(x);
})(true);

Here, error should be reported about true not matching x = number, and also y should be implied as string type.

This example currently shows errors for both the argument type mismatch and the return type mismatch. Should use the same check/rules (number subtypes, etc) as normal assignment, and show no errors.

function foo(x = number) {
	if (x > 4) {
		return x;
	}
	return int`0`;
}

var y = foo(int`3`);

Infer narrowest possible numeric types from number literals:

var x = 3;   // infer 'int'
var y = 3.14;   // infer 'finite'
var z = NaN;  // infer 'number'

This will be particularly effective once #6 is done.

In this snippet, during the first pass, x is a 'string', but during the second pass, it should be re-typed as an 'int' (via the foo(2) call and its return value), and thus the x = "hello" assignment should report an error. However, x is still assumed a 'string' on the second pass, and thus the x = foo(2) is the statement that reports the error.

function foo(v) {
    return v;
}
var x = foo(2);
x = "hello";

In this snippet, during the first pass, the foo(..) function assumes a return type of 'int', then on the second pass (because of "hello" being assigned to v parameter), the return type should be changed to 'string', and then return 42 should report an error. However, the function return type is still assumed as 'int', and thus return v reports the error.

function foo(v) {
    if (true) {
        return v;
    }
    return 42;
}
var x = foo("hello");

I believe TypL could benefit from implementing documentation functionality.

Types are useful for documentation but they're only a partial strategy. If a developer were to use TypL for a project and also wanted documentation they'd likely reach for JSDoc and omit type information. JSDoc is widespread but it's an old, inactive project with clunky, generally disliked syntax (I only have anecdotal evidence for this claim).

I propose TypL could enter this field to 1) give developers a modern documentation system and 2) enhance TypL itself with more detailed runtime error descriptions. This would both bring more attention to TypL itself and increase the value of and use cases for TypL.

Nice IDE integration for JSDoc-like tooltips would be a big bonus too.

Usage example with rough API:

function getCommaSeparatedNumberStringPair (aBool = bool, aNumber = number, aString = string) {
  return aBool ? string`${aNumber}, ${aString}` : string`No bueno.` 
}
documentation (getCommaSeparatedNumberStringPair, {
  description: 'This function joins a number and string together to create a new string.',
  parameters: {
    aBool: 'some description of aBool',
    aNumber: 'some description of aNumber',
    aString: 'some description of aString',
  },
  returns: 'aNumber comma separated from aString if aBool is true, otherwise a default message.',
})

getCommaSeparatedNumberStringPair(anArbitraryBool, anArbitraryString)

Resulting runtime error:

TypL Error: 
  Invalid types for getCommaSeparatedNumberStringPair.
  Received Arguments:
     1. VALID: a boolean value
     4. INVALID: a string value
     5. INVALID: no value given
  Function Parameters:
     1. aBool: boolean - some description of aBool
     2. aNumber: number - some description of aNumber
     3. aString: string - some description of aString
  Suggestion:
    Fix Received Argument types for #2 and #3 to match Function Parameters.

"Function Parameters" above is where we see the mixture of TypL's type information and the user-generated documentation. I'm sure we could come up with other benefits of mixing type information and documentation as well.

documentation could be configurable to spit out more or less information. For example: a developer could configure the output to include description and returns, unlike what you see above.

Benefits of a function-based API (as opposed to JSDoc style comments):

1. Modularity
2. Composability
3. Flexibility
4. Ergonomic
5. Smaller learning curve, no special syntax
6. Automatic IDE support for syntax

Basically, it's JS, do what you want to.

Simple example showing how an application could have a common dictionary of terms to be used around the codebase

// commonDictionary.docs.js
export const organizationId = string`the id for an organization`
export const organizations = string`a list of organizations`


// myModule.js
import { organizationId, organizations } from './commonDictionary.docs.js'

const deleteOrganization = (organizationId = string, organizations = array) => {
  return organizations.filter (organization => organization.id !== organizationId)
}
documentation (deleteOrganization, {
  description: 'This function removes an organization',
  parameters: {
    organizationId,
    organizations,
  },
  returns: 'the updated organizations',
})

const updateOrganization = (organizationId = string, organizations = array, updateProperties = object) => {
  return organizations.map (organization => {
    return organization.id === organizationId
      ? { organization, ...updateProperties }
      : organization
  })
}
documentation (updateOrganization, {
  description: 'This function updates an organization',
  parameters: {
    organizationId,
    organizations,
    updateProperties: 'the properties to update an organization with',
  },
  returns: 'the updated organizations',
})

Other projects like TypeScript struggle with providing ergonomic ways of typing code written in a functional style. And at least at some point, TypeScript wasn't expressive enough to type certain functional programming techniques at all. I'm not sure if this is still true but I suspect it is. TypL works a bit different though because it works on value-types instead of variables so I imagine it's more flexible.

1. Are there things in JS that you can do but are not possible for TypL to type?
2. How does TypL fair with regards to typing functional programming techniques?
3. Does TypL make tradeoffs that favor a particular style of coding?

I know TypL isn't done yet so I'm fine with the answers to refer to assumptions and goals for TypL.

Thanks!

TypL looks extremely interesting! Thank you for putting so much work into it already!

I have kind of a surface level question: why were tag functions chosen for the API? I'm sure there are good reasons but from the outside-in perspective, it seems that normal function calls would be a little more ergonomic since there's a good bit less syntax:

Using tag functions:

function isEven(v = number) {
   return bool`${ v % 2 == 0 }`;
}

var x = number`42`;
var kind = bool`${ isEven(x) }`;

vs

Using "regular" functions:

function isEven(v = number) {
   return bool( v % 2 == 0);
}

var x = number(42);
var kind = bool( isEven(x) );

Thanks!

Bug report

Checker tests keep failing on my end:

> [email protected] test /home/mohamededrah/Projects/Oss/TypL
> node scripts/node-tests.js


**********************************
********** TESTING SRC ***********
**********************************

TypL Test Suite (36)

Passed: 'Runtime: API' (14/14)
Passed: 'Runtime: any(..)' (4/4)
Passed: 'Runtime: undef(..)' (10/10)
Passed: 'Runtime: nul(..)' (11/11)
Passed: 'Runtime: string(..)' (8/8)
Passed: 'Runtime: bool(..)' (10/10)
Passed: 'Runtime: number(..)' (10/10)
Passed: 'Runtime: finite(..)' (11/11)
Passed: 'Runtime: int(..)' (13/13)
Passed: 'Runtime: bint(..)' (13/13)
Passed: 'Runtime: symb(..)' (10/10)
Passed: 'Runtime: array(..)' (11/11)
Passed: 'Runtime: array(..), parse shapes only' (8/8)
Passed: 'Runtime: array(..), shape parse failure' (10/10)
Passed: 'Runtime: array(..), shape: int[]' (8/8)
Passed: 'Runtime: array(..), shape: <int[][],string>[]' (10/10)
Passed: 'Runtime: object(..)' (10/10)
Passed: 'Runtime: func(..)' (10/10)
Passed: 'Runtime: regex(..)' (9/9)
Passed: 'Checker: API' (1/1)
Passed: 'Checker: #6 number sub-types' (2/2)
Passed: 'Checker: #7 enforce bool type check in conditionals' (2/2)
Passed: 'Checker: #8 any' (2/2)
Passed: 'Checker: #9 undef' (2/2)
Passed: 'Checker: #17 Narrower number type inference' (2/2)
Passed: 'Checker: #33 Treat IIFE as a validated call-expression' (2/2)
Passed: 'Checker: #34 check tagged-type simple literals' (2/2)
Passed: 'Checker: #39 array-of-type annotation' (1/1)
Passed: 'Checker: #39 Non-empty arrays ' (1/1)
Passed: 'Checker: #39 Non-empty arrays' (1/1)
Failed: 'Checker: #39 Array of various types (union types)' (1/1)
  num errors
    expected: 1
    actual: 2
Failed: 'Checker: #39 multidimensional arrays' (1/1)
  num errors
    expected: 0
    actual: 1
Failed: 'Checker: #39 Tuple, Nested Tuple' (1/1)
  num errors
    expected: 1
    actual: 2
Failed: 'Checker: #39 Array of tuples' (1/1)
  num errors
    expected: 0
    actual: 1
Failed: 'Checker: #39 Tuple of arrays' (1/1)
  num errors
    expected: 0
    actual: 1
Failed: 'Checker: #39 Array of tuples of arrays' (1/1)
  num errors
    expected: 0
    actual: 1

Failed (6/214)

**********************************
********** TESTING SRC ***********
**********************************

npm ERR! Test failed.  See above for more details.

this happens after i run npm install

I did some exploring it seems that the tests (at least for me) start failing at commit 8286faf664bafa36c16d17964142e4fee61fd581
is this a problem on my end or are the test broken ?, i really like this project and would like to contribute if possible, thanks.

How to reproduce

Clone this repo: https://github.com/MSE99/TypL and run npm install

Additional information

os: Pop!_OS 20.04 (An ubuntu based linux distro) node version: 14.16.1 npm version: 6.14.1 typL version: I'm running the tests on the master branch on the latest commit.

const add = x => y => x + y;

const a = add(1)(2);
const b = add('a')('b');
const c = add(1)('b');

a - 1;

Expected results:

1. Trigger an error on the add('a') call since that string value doesn't match the number type that was implied by the previous add(1) call. Ditto for the ('b') call. These errors could be configured off if you didn't want them.
2. Expand the implied type for the x function parameter to be a union type (number | string), as well as y, so future calls can send either type for either parameter.
3. Trigger an error on the + operation when the 1 and 'b' are added. Again, this error could be configured off.
4. a - 1 would definitely be allowed, since a was implied as a number.

Other results:

• Hegel
• Flow
• TS

This is an interesting idea that fits well with TypL's vision, should explore having it incorporated.

https://twitter.com/mpjme/status/1127113416307630080