Porffor: A from-scratch experimental ahead-of-time JS engine

Post by wk_end » Tue, Jul 30, 2024, 9:23 PM UTC

obviouslynotme wrote: post #19

wk_end wrote: post #14

Earlier quoted context omitted.

At least without additional extensions, TypeScript would help less than you think. It just wasn’t designed for the job. As a simple example - TypeScript doesn’t distinguish between integers and floats; they’re all just numbers. So all array accesses need casting. A TypeScript designed to aid static compilation likely would have that distinction. But the big elephant in the room is TypeScript’s structural subtyping. T…

Outside of really funky code, especially code originally written in TS, you can assume the interface is the actual underlying object. You could easily flag non-recognized-member accesses to interfaces and then degrade them back to object accesses.

Post by neongreen » Tue, Jul 30, 2024, 9:38 PM UTC

wk_end wrote: post #32

munificent wrote: post #26

Earlier quoted context omitted.

I think the even bigger elephant in the room is that TypeScript's type system is unsound. You can have a function whose parameter type is annotated to be String and there's absolutely no guarantee that every call to that function will pass it a string. This isn't because of `any` either. The type system itself deliberately has holes in it. So any language that uses TypeScript type annotations to generate faster/small…

So - I know this in theory, but avoided mentioning it because I couldn’t immediately think of any persuasive examples (whereas subtype polymorphism is a core, widely used, wholly unrestricted property of the language) that didn’t involve casts or any/unknown or other things that people might make excuses for. Do you have any examples off the top of your head?

Post by obviouslynotme » Tue, Jul 30, 2024, 9:56 PM UTC

wk_end wrote: post #31

obviouslynotme wrote: post #19

Earlier quoted context omitted.

Outside of really funky code, especially code originally written in TS, you can assume the interface is the actual underlying object. You could easily flag non-recognized-member accesses to interfaces and then degrade them back to object accesses.

You’re misunderstanding me, I think. Suppose you have some interface with fields a and c. If your function takes in an object with that interface and operates on the c field, what you want is to be able to do is compile that function to access c at “the address pointed to by the pointer to the object, plus 8” (assuming 64-bit fields). Your CPU supports such addressing directly. Because of structural subtyping, you ca…

Post by the_imp » Tue, Jul 30, 2024, 10:14 PM UTC

com2kid wrote: post #10

obviouslynotme wrote: post #6

I have thought about doing this and I just can't get around the fact that you can't get much better performance in JS. The best you could probably do is transpile the JS into V8 C++ calls. The really cool optimizations come from compiling TypeScript, or something close to it. You could use types to get enormous gains. Anything without typing gets the default slow JS calls. Interfaces can get reduced to vtables or may…

Ecmascript 4 was an attempt to add better types to the language, which sadly failed a long time ago. It'd be nice of TS at least allowed for specifying types like integer, allowing some of the newer TS aware runtimes could take advantage of the additional info, even if the main TS->JS compilation just treated `const val: int` the same as `const val: number`. I wonder if a syntax like const counter: Number would be ac…

    const Integer = {
      [Symbol.customMatcher]: (value) => [Number.parseInt(value)]
    }

    const Integer(counter) = 42.56;
    // counter === 42

Post by com2kid » Tue, Jul 30, 2024, 10:21 PM UTC

obviouslynotme wrote: post #16

com2kid wrote: post #10

Earlier quoted context omitted.

Ecmascript 4 was an attempt to add better types to the language, which sadly failed a long time ago. It'd be nice of TS at least allowed for specifying types like integer, allowing some of the newer TS aware runtimes could take advantage of the additional info, even if the main TS->JS compilation just treated `const val: int` the same as `const val: number`. I wonder if a syntax like const counter: Number would be ac…

Yeah, that is why I said TS (or something similar). TS made some decisions that make sense at the time, but do not help compilation. The complexity of its typing system is another problem. I'm pretty sure that it is Turing-complete. That doesn't remove feasibility, but it increases the complexity of compiling it by a whole lot. When you add onto this the fact that "the compiler is the spec," you really get bogged dow…