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

Post by _hl_ » Tue, Jul 31, 2018, 5:20 PM UTC

barrkel wrote: post #77

repsilat wrote: post #12

Earlier quoted context omitted.

> 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…

It's generally better to highlight the existence of an error condition sooner rather than later. Compile time is better than runtime, evaluation time is better than via explicit value inspection. Non-signalling NaNs provide an easy way of distributing an invalid value widely throughout a program's data structures before it's discovered. The only reason to go the other way, and have silent NaN propagation, is if they'…

Post by rs86 » Tue, Jul 31, 2018, 7:30 PM UTC

colanderman wrote: post #123

masklinn wrote: post #105

Earlier quoted context omitted.

> Erlang for example follows that pattern (and has no concept of "exception"). Erlang absolutely has a concept of exceptions. They're even called exceptions: http://erlang.org/doc/reference_manual/errors.html#exception... .

Wow, I used Erlang extensively a few years ago and don't remember exceptions at all. (Exit reasons and process monitors, yes; but I don't think I ever wrote a "catch" expression, or encountered a library that expected me to do so.)

Post by pmontra » Tue, Jul 31, 2018, 7:40 PM UTC

cmmartin wrote: post #129

pmontra wrote: post #15

Earlier quoted context omitted.

The documentation about types says to look at the Readme of the compiler, which is very short and doesn't tell anything about types. Same thing for many other entries in the side menu. The examples don't have any type declaration. So, type inference and no reuse of the same variable with a different type, even when forcing mutation? Unfortunately the documentation is still too skinny. A note to language designers: I…

Well if you are worried about those 2 characters, you should be stoked about Grain, because it gives you type safety without ever defining types. Think how many characters you will save in an application by never defining a type and at no cost.

Post by Semiapies » Tue, Jul 31, 2018, 10:19 PM UTC

jholman wrote: post #53

anonytrary wrote: post #13

I mean, this looks interesting, but why was this posted prematurely? Now I have to remember to look this up again in two months when they actually have a website that isn't 3% done. Basically all of the docs are in the "todo" stage. I always get a bit annoyed when people post their pages way too early.

What makes you think that the HN poster has any affiliation with the project, or vice versa?

Post by c-smile » Tue, Jul 31, 2018, 11:09 PM UTC

mkl wrote: post #135

c-smile wrote: post #118

IMO modern web language should have some notion of events as in my Sciter ( https://sciter.com/event-handling/ ) for example: event click $(table > thead > tr > th) { // click on table header cell // 'this' is that th element } class Widget : Element { function attached() {...} event click $(span.up) { this.increment(); } event click $(span.down) { this.decrement(); } event mousedown { this.state.focus = true; } ...…

Can you explain how these differ from ordinary callback functions? I haven't done any web development to speak of, but I've done a fair bit of GUI stuff, doing things like this snippet appears to in languages that don't have "events" as a separate category of thing.

    observable.on("click", observerFunc);
    // or observable.addEventListener(...);

    class Widget : Element {

      event click { … observer's code … }
    }

    widget {
      prototype: Widget url(path); //  controller
      display: block;   
      ...  
    }