3 ms·

It's important to stress that JS is really just the target language "instead of ASM" for Haskell-to-JS compilers, not just a convenient preprocessor. Developmen

by quchen 13y ago

It's important to stress that JS is really just the target language "instead of ASM" for Haskell-to-JS compilers, not just a convenient preprocessor. Development happens in Haskell (or Core, an intermediate representation, "the final human-readable step before compilation") land, and very rarely in the JS (or ASM).

Groxx 13y ago
But bugs happen everywhere, and I don't expect Haste to abstract and fix all possible browser bugs. When <experimental feature X> changes subtly and you get an exception, how do you track it down? How about when the browser just freaks out and inserts a NaN in a place type safety says it can't?
- quchen 13y ago
  Whatever the cause - code, compiler, browser - what you have is a NaN in the wrong place, so the usual techniques apply: Test your code (which usually consists of fairly small functions) using Haskell's excellent testsuites, figure out error location with Debug.Trace, etc. In the end, this is like asking what happens when the assembler "freaks out" (inserts 0 at a random location), or your architecture is wrong (Pentium FDIV bug): things may become difficult. (There is no type safety to help you on the JS level, much like there is no type safety in machine code. When you insert a wrong value, your code will misbehave in an unpredictable way.)
  - Groxx 13y ago
    Except that such things happen a lot more often on browsers. And "softer" errors, like experimental features being subtly different because user X toggled checkbox Y (which you don't know about and cannot reproduce) are not going to be caught by test suites. They can be caught by client-side crash logging / reporting. But if they're useless, you just lost the ability to fix bugs you don't see yourself in your nice up-to-date dev environment. These bugs happen with surprising frequency in any reasonably-used site.
    - deleted 13y ago
      [deleted]

by quchen 13y ago

Groxx 13y ago

But bugs happen everywhere, and I don't expect Haste to abstract and fix all possible browser bugs. When <experimental feature X> changes subtly and you get an exception, how do you track it down? How about when the browser just freaks out and inserts a NaN in a place type safety says it can't?

quchen 13y ago
Whatever the cause - code, compiler, browser - what you have is a NaN in the wrong place, so the usual techniques apply: Test your code (which usually consists of fairly small functions) using Haskell's excellent testsuites, figure out error location with Debug.Trace, etc. In the end, this is like asking what happens when the assembler "freaks out" (inserts 0 at a random location), or your architecture is wrong (Pentium FDIV bug): things may become difficult. (There is no type safety to help you on the JS level, much like there is no type safety in machine code. When you insert a wrong value, your code will misbehave in an unpredictable way.)
- Groxx 13y ago
  Except that such things happen a lot more often on browsers. And "softer" errors, like experimental features being subtly different because user X toggled checkbox Y (which you don't know about and cannot reproduce) are not going to be caught by test suites. They can be caught by client-side crash logging / reporting. But if they're useless, you just lost the ability to fix bugs you don't see yourself in your nice up-to-date dev environment. These bugs happen with surprising frequency in any reasonably-used site.
  - deleted 13y ago
    [deleted]