5 ms·

Oh wow I did not expect this to be up here this soon. Warning: two-week-old project. I've got a lot of plans for this but it'll take at least a few months for t

Oh wow I did not expect this to be up here this soon. Warning: two-week-old project. I've got a lot of plans for this but it'll take at least a few months for this to be anywhere near useful. Right now it's just an experiment!

dfield 11y ago
^ constexpr is the author
pookeh 11y ago
Please don't add type inference. Coming from Scala it seems such a beautiful concept and a productivity booster when you are writing code but then you come back a few months later / see someone else's code and quickly figure out what a time waste and a productivity drain it really is.
- Drup 11y ago
  If I may, that just means that either 1) your tooling is bad 2) Scala's type system is too complex. I don't know scala much, but it's not a problem in other languages with full inference (particularly OCaml, but it's not a huge problem in Haskell either).
- davnn 11y ago
  Just because type inference exists doesn't mean that you have to use in every case. Better to establish best practices when to use type annotations.
PeCaN 11y ago
I'm glad it did though—this is awesome! Good luck with it, and perhaps I'll contribute something (do you plan for it to be garbage collected?).
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 :)

dfield 11y ago

^ constexpr is the author

pookeh 11y ago

Please don't add type inference. Coming from Scala it seems such a beautiful concept and a productivity booster when you are writing code but then you come back a few months later / see someone else's code and quickly figure out what a time waste and a productivity drain it really is.

Drup 11y ago
If I may, that just means that either 1) your tooling is bad 2) Scala's type system is too complex. I don't know scala much, but it's not a problem in other languages with full inference (particularly OCaml, but it's not a huge problem in Haskell either).
davnn 11y ago
Just because type inference exists doesn't mean that you have to use in every case. Better to establish best practices when to use type annotations.

PeCaN 11y ago

I'm glad it did though—this is awesome! Good luck with it, and perhaps I'll contribute something (do you plan for it to be garbage collected?).

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 :)