Grain: A strongly-typed functional programming language for the modern web

Post by tylerhou » Tue, Jul 31, 2018, 2:33 PM UTC

atombender wrote: post #99

rzwitserloot wrote: post #89

Pretty much the first sentence on the page: > No runtime exceptions, ever. Every bit of Grain you write is thoroughly sifted for type errors, with no need for any type annotations. That's... weird to me. That seems to posit that ALL runtime exceptions are necessarily type errors. Huh? What about full disk, DB errors, data verification error, parsing errors, network errors, and tons of other errors that don't appear t…

Errors could presumably be provided as return values (similar to Rust's Option or Haskell's Either), though we know from languages like Go that propagating these manually is a chore and an eyesore. A harder problem is errors that cannot be handled by a simpler type system. For example, consider Haskell's head function, which is defined like this: head :: [a] -> a In other words, it takes a list, and returns the first…

Post by yosefzeev » Tue, Jul 31, 2018, 2:39 PM UTC

Post by masklinn » Tue, Jul 31, 2018, 2:55 PM UTC

colanderman wrote: post #91

rzwitserloot wrote: post #89

Pretty much the first sentence on the page: > No runtime exceptions, ever. Every bit of Grain you write is thoroughly sifted for type errors, with no need for any type annotations. That's... weird to me. That seems to posit that ALL runtime exceptions are necessarily type errors. Huh? What about full disk, DB errors, data verification error, parsing errors, network errors, and tons of other errors that don't appear t…

I would assume case B, which isn't really that unique. Erlang for example follows that pattern (and has no concept of "exception"). After all, I/O errors, parsing errors, etc., aren't exceptional; they very much should be expected. Forcing them to be handled in the normal code path helps create robust systems. (There are of course also true runtime errors -- e.g. out-of-memory -- and precondition errors -- i.e., codi…

Post by galaxyLogic » Tue, Jul 31, 2018, 3:07 PM UTC

masklinn wrote: post #104

atombender wrote: post #99

Earlier quoted context omitted.

Errors could presumably be provided as return values (similar to Rust's Option or Haskell's Either), though we know from languages like Go that propagating these manually is a chore and an eyesore. A harder problem is errors that cannot be handled by a simpler type system. For example, consider Haskell's head function, which is defined like this: head :: [a] -> a In other words, it takes a list, and returns the first…

> Errors could presumably be provided as return values (similar to Rust's Option or Haskell's Either), though we know from languages like Go that propagating these manually is a chore and an eyesore. Mostly because Go is terrible. > Haskell's type system is extremely powerful, but it cannot catch this at compile time. The problem is not the type system, it's that Haskell's error handling is inconsistent. Elm, despite…

Post by galaxyLogic » Tue, Jul 31, 2018, 3:16 PM UTC

repsilat wrote: post #12

tlrobinson wrote: post #5

The main page doesn't do a great job of showing what's interesting about Grain vs. JavaScript. The only hint is this: "No runtime exceptions, ever. Every bit of Grain you write is thoroughly sifted for type errors, with no need for any type annotations." Maybe show some examples of errors Grain would catch that JavaScript wouldn't, like Elm does: http://elm-lang.org/

> No runtime exceptions, ever. This is something I wonder about JS: there are a lot of places that exceptions happen in (say) Python that just return `NaN` or `undefined` in javascript. Is it intentional? Is it a good idea? Examples: the multiplication operator essentially never throws. Out-of-bounds (or "not found") lookups don't throw. I suspect the logic is "only throw if you have the wrong type for that operation…