111–120 of 125 posts
Earlier quoted context omitted.
Hmm, really? I just read a couple of papers linked from his website, but I'm still not feeling enlightened.
I may write a blog post. Hm.
Earlier quoted context omitted.
Rare language has both .Net and JVM support, probably only Clojure now. On the upside you can build iOS and Android apps using F# plus many other gaming platforms.
Clojure is far from the only language that supports both the JVM and CLR. I had a long reply ready, but I lost it. Off the top of my head the languages that have support on both (aside from Clojure) are; Python, Ruby, JavaScript, Java (though J# is being depreciated), Scheme, Common Lisp, PHP, Perl 6, Prolog, Pascal, Ada. I might be missing some.
Earlier quoted context omitted.
I think a big part of the issue is that - because of the way Haskell's cross-module inlining works - you need to generate different artifacts not just for each version you use but for each set of dependencies chosen for each set of flags set for version you use. I think this strips away much of the benefit of the second approach.
This sounds like something Backpack might be able to help with! (I don't actually know. I'm speculating. And hoping ...)
Earlier quoted context omitted.
This sounds like something Backpack might be able to help with! (I don't actually know. I'm speculating. And hoping ...)
Interesting. I hope you're right. I've been waiting for the finished version to pay Backpack much attention, so I also don't know whether you are.
Earlier quoted context omitted.
Yes, that's close! I also think that we'll need a better treatment of effects than either ML or Haskell can give us, but I hope to have something that has been carefully thought about, rather than bolted on like Haskell's effects. It sounds like call-by-push-value gives a nice unifying approach to CBN/CBV and also effects. I am hoping that something interesting will come out of that work.
It's been about 15 years since CBPV was proposed. Has there been any work on actually making a practical language along those lines?
Frank's basically based on an extension of the CBPV calculus. As far as I know, Conor's also working on extending the core Frank calculus to the dependently-typed case, though this might take a bit.
Earlier quoted context omitted.
Interesting. I hope you're right. I've been waiting for the finished version to pay Backpack much attention, so I also don't know whether you are.
Part of the benefit of backpack seems to be that you can compile modules separately from their dependencies and if this is correct it should go some way to addressing the issue you raise.
Earlier quoted context omitted.
I may write a blog post. Hm.
That would be great! I'm currently reading "Bridging the gulf: a common intermediate language for ML and Haskell" (Peyton Jones, Shields, Launchbury, Tolmach) which was one of Paul Levy's references for CBPV and it seems likely it was a main inspiration.
Earlier quoted context omitted.
That there is no game-plan for doing anything any better than Coq presently does is why I'm a bit skeptical. The trimmings are nicer - nothing else as of yet.
The elephant in the room in these discussions is that the cost of bringing a function compiler to fruition is so high that too much of the discussion gets muddled in the semantics of these hypothetical Haskell-successor languages while no one is actually working on said language. Academia simply isn't set up to incentivize large engineering projects, and industry would never invest in building such a thing either sin…
It's ready now and I'd like to begin work with Haskell in the hopes that industry wakes up to the utility of future successors to Haskell by seeing Haskell itself in action.
Earlier quoted context omitted.
1. Call-by-value gives us both the ability reason by induction. It also typically results in the presence of non-pointed types, whereas Haskell only has pointed types. 2. Call-by-value gives us the ability to safely interleave effects. Now, I know you all think we should not be doing that at all, but I would say that this is only true in some cases. The point of reifying an effect in a monad is not because "effects a…
The best argument for John's thesis is the proliferation of ML derivatives in industry: Swift, Rust and Facebook's Hack. I'm really looking to Facebook's Flow which adds an ML style type system to Javascript.
Syntactically it's a bit different, but from a modularity POV it is much closer to ML than Swift, Rust or Hack.
Earlier quoted context omitted.
Could you expand on why you think the next "great thing" will be more like ML than like Haskell?
1. Call-by-value gives us both the ability reason by induction. It also typically results in the presence of non-pointed types, whereas Haskell only has pointed types. 2. Call-by-value gives us the ability to safely interleave effects. Now, I know you all think we should not be doing that at all, but I would say that this is only true in some cases. The point of reifying an effect in a monad is not because "effects a…
Plus, the build/module/packaging/dependency resolution story, even when doing all the recommended best practices involving sandboxing Cabal and leveraging Nix are just plain embarrassing.
There are so many smart Haskell people. I don't understand how any of them could consider this clusterf*ck to be remotely acceptable.