3 ms·

While this is an interesting effort, I can't help but be squeamish about the sheer volume of JS that gets emitted (due to type checking) for what seem like smal

While this is an interesting effort, I can't help but be squeamish about the sheer volume of JS that gets emitted (due to type checking) for what seem like small amounts of input.

cameronkknight 13y ago
type-checking and such features can be easily disabled by sticking const DISABLE_TYPE_CHECKING = true at the top of your file. It's handy to have in development vs. production.
tel 13y ago
Wait, the type checking isn't static?
- cameronkknight 13y ago
  Currently, no. I do plan on adding warnings (not errors) on a statically-calculated type issue. One thing is that I don't plan on it erroring if you call a function with a value whose type might be an "any" type or a "union" where it expects a specific type. If there's some overlap, it would allow, to make things easier and give the programmer the benefit of the doubt. Thus, the following would compile without warning: let double(x as Number) x * 2 let repeat(x as String) x & x let fun(x as Number|String) if is-number! x double x else repeat x let fail(x as Boolean) // this should fail at compile-time double x I could write the compiler to be a lot smarter and have it track types through conditional branches (which would be very hard, but possible), or allow it in those cases where it is possible that the types overlap. I also might add a "cast", i.e. a runtime type check. I'm not sure what the best syntax for it would be, but it would act like the following: CAST(x, Number) // validate that x is a Number or throw a TypeError CAST(x, Number|String) // validate that x is either a number or a string, otherwise throw TypeError CAST(x, Number, 0) // validate that x is a Number, otherwise evaluate to 0. Of course, in the cases where `x` could not fit the type requested, then that could error at compile-time. I would love some feedback on this, especially from the perspective of "what would I use to help me develop", not "I need my program to be 100% statically type-safe without having to do any testing".
  - tel 13y ago
    The feeling of it reminds me a bit of Erlang's success typing, but I don't know enough to say much more.

While this is an interesting effort, I can't help but be squeamish about the sheer volume of JS that gets emitted (due to type checking) for what seem like small amounts of input.

cameronkknight 13y ago

type-checking and such features can be easily disabled by sticking const DISABLE_TYPE_CHECKING = true at the top of your file. It's handy to have in development vs. production.

tel 13y ago

Wait, the type checking isn't static?

cameronkknight 13y ago
Currently, no. I do plan on adding warnings (not errors) on a statically-calculated type issue. One thing is that I don't plan on it erroring if you call a function with a value whose type might be an "any" type or a "union" where it expects a specific type. If there's some overlap, it would allow, to make things easier and give the programmer the benefit of the doubt. Thus, the following would compile without warning: let double(x as Number) x * 2 let repeat(x as String) x & x let fun(x as Number|String) if is-number! x double x else repeat x let fail(x as Boolean) // this should fail at compile-time double x I could write the compiler to be a lot smarter and have it track types through conditional branches (which would be very hard, but possible), or allow it in those cases where it is possible that the types overlap. I also might add a "cast", i.e. a runtime type check. I'm not sure what the best syntax for it would be, but it would act like the following: CAST(x, Number) // validate that x is a Number or throw a TypeError CAST(x, Number|String) // validate that x is either a number or a string, otherwise throw TypeError CAST(x, Number, 0) // validate that x is a Number, otherwise evaluate to 0. Of course, in the cases where `x` could not fit the type requested, then that could error at compile-time. I would love some feedback on this, especially from the perspective of "what would I use to help me develop", not "I need my program to be 100% statically type-safe without having to do any testing".
- tel 13y ago
  The feeling of it reminds me a bit of Erlang's success typing, but I don't know enough to say much more.