5 ms·

Do you plan to support return type inference? Will classes be accessible before they are declared? Why "int" (opposed to supporting the wasm type names)? (I'm

by dukoid 11y ago

Do you plan to support return type inference? Will classes be accessible before they are declared? Why "int" (opposed to supporting the wasm type names)? (I'm interested because I was planning to add a typescript parsing demo for an expression parser (https://github.com/stefanhaustein/expressionparser https://github.com/stefanhaustein/expressionparser), but typescript turned out to be a bit more tricky than anticipated originally)

constexpr 11y ago
I'm not planning on supporting return type inference since I actually don't like that feature of TypeScript, but I could be convinced otherwise. It really harmed API readability for me when I tried to use it. All declarations in ThinScript are order-independent right now so classes are accessible everywhere simultaneously. I'm getting away with that because I'm currently requiring all global initializers to be constant. One idea I had that would allow for non-constant global initializers without really complex static analysis to determine initialization order was to initialize non-constant global variables on first access instead of on startup. I chose "int" because I was aiming for familiarity with existing languages. I'm also planning for WebAssembly to be just one target among many targets so I don't want to align too closely with WebAssembly. Some other targets I'm considering are C, x86, Swift, and C#, for example.
- dukoid 11y ago
  Are parameter types mandatory or do omitted types imply "any"? Do you support "let" (the example uses "var"?)
  - constexpr 11y ago
    There is no "any" type since ThinScript is an ahead-of-time compiled language and emulating dynamic types is a non-goal. Types are required and omitting them is a syntax error. Right now "let" is an alias for "var" and "var" behaves like "let".
    - dukoid 11y ago
      What about implicit conversions to boolean? Is "if (1)" legal? Does "==" require equal types (or compatible types) on both sides?
      - constexpr 11y ago
        Right now the only implicit conversions are null to nullable types and smaller integers to larger ones. There is no "===" right now and "==" requires equal types. I may consider aligning this more with JavaScript in the future. There's a live compiler demo at http://evanw.github.io/thinscript/ http://evanw.github.io/thinscript/ where you can try out all of this yourself :)

by dukoid 11y ago

constexpr 11y ago

I'm not planning on supporting return type inference since I actually don't like that feature of TypeScript, but I could be convinced otherwise. It really harmed API readability for me when I tried to use it. All declarations in ThinScript are order-independent right now so classes are accessible everywhere simultaneously. I'm getting away with that because I'm currently requiring all global initializers to be constant. One idea I had that would allow for non-constant global initializers without really complex static analysis to determine initialization order was to initialize non-constant global variables on first access instead of on startup. I chose "int" because I was aiming for familiarity with existing languages. I'm also planning for WebAssembly to be just one target among many targets so I don't want to align too closely with WebAssembly. Some other targets I'm considering are C, x86, Swift, and C#, for example.

dukoid 11y ago
Are parameter types mandatory or do omitted types imply "any"? Do you support "let" (the example uses "var"?)
- constexpr 11y ago
  There is no "any" type since ThinScript is an ahead-of-time compiled language and emulating dynamic types is a non-goal. Types are required and omitting them is a syntax error. Right now "let" is an alias for "var" and "var" behaves like "let".
  - dukoid 11y ago
    What about implicit conversions to boolean? Is "if (1)" legal? Does "==" require equal types (or compatible types) on both sides?
    - constexpr 11y ago
      Right now the only implicit conversions are null to nullable types and smaller integers to larger ones. There is no "===" right now and "==" requires equal types. I may consider aligning this more with JavaScript in the future. There's a live compiler demo at http://evanw.github.io/thinscript/ http://evanw.github.io/thinscript/ where you can try out all of this yourself :)