basic typechecking

[bakkot]

Catches errors like tc39/proposal-joint-iteration#11 (comment) via a very basic type system.

The checks only apply to call arguments, and specifically only to arguments which are either literals or themselves calls (including ! Foo()-style unwrapped calls). There's no tracking of variables or anything yet.

Also, we can't generally infer types precisely. For example, imagine Identity(x) which returns its input and accepts any value: TakesInteger(Identity(42)) would be a reasonable thing to write, but the type system here is much to weak to know that. So we check only that the intersection (that is, the meet) of the argument type and parameter type is nonempty.

The first commit is just moving code around. I recommend reviewing commits individually.

[michaelficarra]

1.23456789e+23 is integral and a canonical ToString.

Suggested change

	return !b.value.includes('.');
	let n = parseFloat(b.value);
	return n === Math.round(n);

Alternatively, you could just keep a number instead of a string.

[bakkot]

Do we actually want to allow people to write numbers like *1.23456789e+23*<sub>𝔽</sub>?

[michaelficarra]

Does IEEE-754 prescribe a way to refer to float values in documentation and such?

[bakkot]

Not that I can find on skimming, and it's too long for me to easily feed into an LLM to ask one to read it more thoroughly without chunking it up, which I'm too lazy to do.

[michaelficarra]

I guess I would slightly lean toward only permitting DecimalDigits and DecimalDigits . DecimalDigits and requiring that they be an exactly-representable float value. This is an editorial question we should confirm at an editor call.

Regardless though, I would still change the representation to number and move the complexity of what's permitted upstream.

[bakkot]

Pretend I said 0.1 like I obviously meant.

[michaelficarra]

That could be fine if we add some explanation in the Notational Conventions section saying that we mean the nearest-representable float. This is a topic for editor call.

[bakkot]

Also, changing this to be a number doesn't work for reals, which can in principle be values which are not representable as doubles. So I would still need to keep the string-handling logic for the real case. Given that, I don't want to introduce a different path just four doubles. That's a lot of extra complexity for no benefit.

[michaelficarra]

You already have different paths for reals and doubles.

[bakkot]

In some places, but not in this case.

[michaelficarra]

You should add support for undefined/booleans.

[bakkot]

You should add support for undefined/booleans.

Done.

[michaelficarra]

It looks like you're missing some coverage in the tests. For example, I don't see anything for EcmaScript language values. I would expect the whole dominator lattice to be tested.