-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design Meeting Notes, 8/25/2021 #45577
Labels
Design Notes
Notes from our design meetings
Comments
@DanielRosenwasser have you tried to solve the stack overflow problem using trampoline technique? const trampoline = f => (...args) => {
let result = f
do { result = result(...args) }
while (typeof result === 'function')
return result
}
const factorial = n => factorialAcc(1n, n)
const factorialAcc = (acc, n) => {
if (n <= 1) { return acc }
return () => factorialAcc(acc * BigInt(n), n - 1)
}
const factorialT = trampoline(factorial)
console.log(factorialT(300)) Performance tests for the large call stack case: No trampoline test for factorial(2500): 8.612300038337708 ms
No trampoline test for factorial(2500): 8.430999994277954 ms
No trampoline test for factorial(2500): 8.416900038719177 ms
No trampoline test for factorial(2500): 8.343400001525879 ms
No trampoline test for factorial(2500): 8.81769996881485 ms
Trampoline test for factorial(2500): 6.159500002861023 ms
Trampoline test for factorial(2500): 6.034699976444244 ms
Trampoline test for factorial(2500): 6.161700010299683 ms
Trampoline test for factorial(2500): 5.963100016117096 ms
Trampoline test for factorial(2500): 5.686100006103516 ms Performance tests for the small call stack case: No trampoline test for factorial(100): 0.05640000104904175 ms
No trampoline test for factorial(100): 0.0591999888420105 ms
No trampoline test for factorial(100): 0.07770001888275146 ms
No trampoline test for factorial(100): 0.06279999017715454 ms
No trampoline test for factorial(100): 0.05779999494552612 ms
Trampoline test for factorial(100): 0.08009999990463257 ms
Trampoline test for factorial(100): 0.08600002527236938 ms
Trampoline test for factorial(100): 0.0835999846458435 ms
Trampoline test for factorial(100): 0.0821000337600708 ms
Trampoline test for factorial(100): 0.08160001039505005 ms |
I didn't capture it in the notes but
Wesley can correct me if I got any of the details wrong. |
I mean, our existing trampolines function as state machines rather than recreating closures all the time, but yes. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
Awaited
Type inlib.d.ts
#45350
When we introduced
await
into TypeScript, we added some logic to recursively unwrap a type.At the time, we had no recursion mechanism within the type system.
First we started out with an
awaited
type operator.Problem: if you have generics, you end up with higher-order type operators.
awaited T
is not necessarily assignable toT
(nor vice versa).Had ideas for a top-level type alias...
And that's what we do here, but right now are only introducing the alias to be used in
lib.d.ts
.await
operator does.Preserves the incorrect behavior to avoid errors on
awaited T -> T
in async functions, but better-modelslib.d.ts
.Ideally, other overloads take care of the breaks.
Does this break existing code?
Having
Awaited
makes sense in general.Worth thinking about whether users will be able to understand how to use this.
Should we get rid of the other overloads?
Conclusions
await
?--noErasingImportedNames
#44619
isolatedModules
, it will warn you that some compiler won't know how to drop types.Svelte.
Layout
.Vue
<script setup>
.noErasingImportedNames
hard to parse.preserveValueImports
"importsNotUsedAsValues": "preserve"
😢Stack Overflow on Type Instantiation
#45576
try
/catch
.try
/catch
at the top ofinstantiateType
?The text was updated successfully, but these errors were encountered: