31–40 of 65 posts
We need HKT. F#. Cmon... I love F# but seriosly...
Not only we do not need HKT, we also do not need Profunctor Optics.
They're really good at saying "No" to things that offer at best incremental improvements at the cost of significant complexity.
"Profunctor Optics" is a great example. Cool paper, but no thanks.
Earlier quoted context omitted.
Is published? I have tried to use FParsec before for the same kind of language and failed.
Its currently in a private bitbucket repo. I can give you the parser though, MIT licensed. ParserUtils is where maybeIndented and indented are. They make indentation just work. There currently overzealous with backtracking though, makes errors kinda shit. Working on that at somepoint. https://gist.github.com/xavierzwirtz/99479a11f1eefd3215467f7...
But this not look more easy than just do it as TopDown Parser. But I don't know your language so it maybe have provided you with some benefits more than just lines of code?
Earlier quoted context omitted.
Its currently in a private bitbucket repo. I can give you the parser though, MIT licensed. ParserUtils is where maybeIndented and indented are. They make indentation just work. There currently overzealous with backtracking though, makes errors kinda shit. Working on that at somepoint. https://gist.github.com/xavierzwirtz/99479a11f1eefd3215467f7...
Ok, thanks. But this not look more easy than just do it as TopDown Parser. But I don't know your language so it maybe have provided you with some benefits more than just lines of code?
We need HKT. F#. Cmon... I love F# but seriosly...
We're working on Type Classes. It seems like HKTs (or anything like them) are going to be hard without diverging in a huge way from the rest of the .NET ecosystem.
Losing HKT would be a shame, but that's a trade-off I would be willing to make.
Earlier quoted context omitted.
If you wanted to create a version of F# that only allows pure functions, your best option is probably to modify the F# compiler (which is open source). However, that sounds like something that might not be all that useful. A more useful thing could potentially be to use the "F# Compiler Service" (which is the compiler API, exposed via a nice F# library) and create some tool that checks purity. I think many people mig…
My purpose would be to create a multiplayer game programming platform. Basically, it would come with a game loop already running, with communications already working. Then you could modify the game by changing functions that transform game tick N to game tick N+1.
Earlier quoted context omitted.
That isn't actually an alias. That is constructing a single-case discriminated union. DUs are compiled into classes and have a few things automatic equality. Generally speaking, it's better to use Units of Measure[0] when you want some compile-time semantics around numeric literals, as these don't incur the performance penalty of creating a class. [0]: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/lang...
Yeah I realize there are more efficient aliases, but even so - just defaulting immutable data structures with only primitive types in them to cretae reference types feels like a massive foot gun performance wise. I couldn't imagine doing C# without value types, so for F# where things are usually more immutable, it has to be painful if e.g. a normal point(x,y) record is a class...
Earlier quoted context omitted.
Not only we do not need HKT, we also do not need Profunctor Optics.
F# and its spirit animal OCaml are really great precisely because of this attitude. They're really good at saying "No" to things that offer at best incremental improvements at the cost of significant complexity. "Profunctor Optics" is a great example. Cool paper, but no thanks.
Do you have examples of why it would add significant complexity? I use them constantly and it really simplifies my code a lot!
Also, I don't believe 'profunctor optics' is a paper, I think it's just one (interesting) implementation of optics, which are useful in any language that encourages immutability.
Earlier quoted context omitted.
Yeah I realize there are more efficient aliases, but even so - just defaulting immutable data structures with only primitive types in them to cretae reference types feels like a massive foot gun performance wise. I couldn't imagine doing C# without value types, so for F# where things are usually more immutable, it has to be painful if e.g. a normal point(x,y) record is a class...
You could use a struct, record, or tuple for a point. I've done all of these before.
I suppose it just shows that those of us that are using .NET to do "C++ work" (always CPU and GC bound, almost never IO bound) are pretty few...
We need HKT. F#. Cmon... I love F# but seriosly...
The issue you're looking for (since an ask for HKTs typically means that Typeclasses are the ideal feature) is here: https://github.com/fsharp/fslang-suggestions/issues/243
Please leave opinions, commentary, and vote if this is something you want! F# language design is done completely in the open, including motivation for features. Thanks!