Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new F# compiler feature: graph-based type-checking

devblogs.microsoft.com

Post reply on HN
Print view View original

31–40 of 118 posts

Re: A new F# compiler feature: graph-based type-checking

#31

Post by daxfohl »

phillipcarter wrote: post #15

This is very neat, I love the idea of using the syntax tree to guide what can be parallelized vs. not. As some additional background, there's a very good reason why the F# language typechecks files sequentially. Because F# supports type inference at every scope, a single change in the body of a function can result in cascading type changes across an entire project. This kind of change can not only affect other files,…

It's useful to keep these anyway, as if you make a change that accidentally changes the type of some function, the error message makes it immediately obvious what you did. Otherwise it's hard to tell whether you messed up the function or the caller.

Also having type annotations makes code reviews easier. Basically people's brains can use the same optimization that compilers do.

Re: A new F# compiler feature: graph-based type-checking

#32

Post by eddythompson80 »

owlstuffing wrote: post #9
peheje wrote: post #5

F# is sooo great

Type providers are boss. Why doesn’t every language type system have this feature by now?!

I got downvoted on the typescript subreddit when I mentioned how Type providers work in F# because "nah, it can't be working that way. The compiler can't be making http requests to make up types for an API" smh.

Re: A new F# compiler feature: graph-based type-checking

#33

Post by eddythompson80 »

Akronymus wrote: post #14
owlstuffing wrote: post #9

Earlier quoted context omitted.

Type providers are boss. Why doesn’t every language type system have this feature by now?!

Because they are pretty annoying to implement and most are quite fragile

They are only as fragile as your type source.

Re: A new F# compiler feature: graph-based type-checking

#34

Post by ObscureScience »

carapace wrote: post #30
_svoh wrote: post #29

Earlier quoted context omitted.

Eh, it doesn't seem like character assassination. Dude chose his management style. That makes his project unfit for purpose for certain people. Those people are allowed to make that determination and state as such. I remember when the Elm team first decided to lock down the Elm compiler, so that only the team in charge had special privileged access to modify it. I thought, "wow, this looks like a bunch of people who…

FWIW my comment was along the lines of allergic reaction. I'm not an Elm fanatic, I'm just sick of seeing people snipe on the dude. You're entitled to your opinion, of course, and you articulated it well. But again I see it as another example of someone not liking being told "no", no?

My understanding of this is that he managed to hype the language with certain killer features. A lot of people were enthusiastic and invested alot of time in learning and building in it. Evan than "suddenly" said they wanted to take the language in another direction and dropped some of the core features and pricipals that drew people in. While perhaps a mischaracterization, it comes a cross as a kind of "bait and switch" or at least undependable.

Re: A new F# compiler feature: graph-based type-checking

#35

Post by _svoh »

carapace wrote: post #30
_svoh wrote: post #29

Earlier quoted context omitted.

Eh, it doesn't seem like character assassination. Dude chose his management style. That makes his project unfit for purpose for certain people. Those people are allowed to make that determination and state as such. I remember when the Elm team first decided to lock down the Elm compiler, so that only the team in charge had special privileged access to modify it. I thought, "wow, this looks like a bunch of people who…

FWIW my comment was along the lines of allergic reaction. I'm not an Elm fanatic, I'm just sick of seeing people snipe on the dude. You're entitled to your opinion, of course, and you articulated it well. But again I see it as another example of someone not liking being told "no", no?

That's really reductive and biased against us, the potential user base of Elm that decided not to engage. Why is it that we don't like being told "no," as opposed to the Elm leadership and Elm community not liking being told "this isn't a 100% solution for me so I'd like to modify it"?

Obviously Elm is his passion project, that's fine. But nobody who locks down their compiler on a supposedly "open source" project can actually seriously expect others to engage with that in good faith.

Furthermore, the absolute state of just trying to modify Elm to be more fit for purpose is horrendous. Every time I see a parallel implementation or a fork, the author has to bend over backward with platitudes to placate the Elm masses and ensure them that this project isn't trying to "split the community," which is a nonsense idea to start with imo.

It feels cultish, on top of a project that is actively hostile to people who want to use it any way other than how the BDFL has mandated its usage. If you want to say the problem is with the users, that's fine, but that's exactly the attitude keeping me from ever engaging. I personally think the problem is with the people who want such fine control over their technology and community, as opposed to understanding that they can really only shepherd their implementation. That's about as far as their reach rightfully extends.

EDIT: also, the fact that they aggressively lock down their compiler and have such hostility to anyone working in parallel is imo the definition of "holding it back"

Re: A new F# compiler feature: graph-based type-checking

#36

Post by piaste »

daxfohl wrote: post #31
phillipcarter wrote: post #15

This is very neat, I love the idea of using the syntax tree to guide what can be parallelized vs. not. As some additional background, there's a very good reason why the F# language typechecks files sequentially. Because F# supports type inference at every scope, a single change in the body of a function can result in cascading type changes across an entire project. This kind of change can not only affect other files,…

It's useful to keep these anyway, as if you make a change that accidentally changes the type of some function, the error message makes it immediately obvious what you did. Otherwise it's hard to tell whether you messed up the function or the caller. Also having type annotations makes code reviews easier. Basically people's brains can use the same optimization that compilers do.

There is also a helpful compiler command to generate updated signature files for you. Then you just glance at the git changes and see if you accidentally broke an API or not.

Re: A new F# compiler feature: graph-based type-checking

#37

Post by aeonik »

I have a tangential question that is related to this cool new feature.

Warning: the question I ask comes from a part of my brain that is currently melted due to heavy thinking.

Context: I write a fair amount of Clojure, and in Lisps the code itself is a tree. Just like this F# parallel graph type-checker. In Lisps, one would use Macros to perform compile-time computation to accomplish something like this, I think.

More context: Idris2 allows for first class type-driven development, where the types are passed around and used to formally specify program behavior, even down to the value of a particular definition.

Given that this F# feature enables parallel analysis, wouldn't it make sense to do all of our development in a Lisp-like Trie structure where the types are simply part of the program itself, like in Idris2?

Also related, is this similar to how HVM works with their "Interaction nets"?

https://github.com/HigherOrderCO/HVM

https://www.idris-lang.org/

https://clojure.org/

I'm afraid I don't even understand what the difference between code, data, and types are anymore... it used to make sense, but these new languages have dissolved those boundaries in my mind, and I am not sure how to build it back up again.

Re: A new F# compiler feature: graph-based type-checking

#38

Post by Capricorn2481 »

obeavs wrote: post #16

Great addition to a great language. We've been building a very technical product in F# + Rust for the last three years or so (think R lang + R Studio or Replit but for DSLs we built for finance and contracts). While most folks tend to see F# as a .NET-oriented/back-end kind of language, they'd be missing some incredibly unique web technologies such as the Fable compiler (F# -> JS, Python, Dart, etc) and Elmish (Elm,…

I looked at Fable and the resulting code just looked way more complicated than anything Javascript could write. I'm interested in F# still on the backend, but I don't think people "haven't discovered" Fable, it's just not a great alternative.

Re: A new F# compiler feature: graph-based type-checking

#39

Post by G4BB3R »

_svoh wrote: post #29
carapace wrote: post #25

Earlier quoted context omitted.

Please PLEASE enough with the character assassination of the Elm guy. He wants to run his own project his own way. There's a small but dedicated residue of people who just can't stand being told "no" and go around crapping on the kid whenever they get a chance. I get it. You don't like Evan's project management style. Move on already. - - - - The fact of the matter is that he's a person who took his thesis, made it i…

Eh, it doesn't seem like character assassination. Dude chose his management style. That makes his project unfit for purpose for certain people. Those people are allowed to make that determination and state as such. I remember when the Elm team first decided to lock down the Elm compiler, so that only the team in charge had special privileged access to modify it. I thought, "wow, this looks like a bunch of people who…

Without this management style Elm would be the oppositive of what it is today (simple language, very fast compiler, efficient tree shaking, no runtime exceptions) wanting to add at all costs Haskell features and JS direct sync interop.
Post reply on HN