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

Why OCaml, why now? (2014)

spyder.wordpress.com

Post reply on HN
Print view View original

71–80 of 132 posts

Re: Why OCaml, why now? (2014)

#71

Post by purescript »

jordwalke wrote: post #59
purescript wrote: post #31

Earlier quoted context omitted.

I can't really comment on source maps in Elm, but the approach in PureScript has been to generate clean, readable JS which is debuggable directly. Source maps are on the roadmap, but not really a priority right now. I haven't heard any complaints about the ability to debug compiled PureScript yet.

That's a nice approach for debugging! If the mapping is close enough, I don't mind reading the JS output. I'm curious about the general approach to compilation, though. It seems like a statically typed language could take advantage of the knowledge of types to generate an even more efficient version of the program that uses typed arrays and views (though, yes, it would require implementing a garbage collector unless…

Right now, the translation is very direct. My basic rule of thumb is - only perform those optimizations which the user opts into. Some things are standard though, like a few inlining rules and tail call elimination, but the plan is to provide a rewrite rules engine so that the developer can be as fine-grained as they like when it comes to optimizations.

Re: Why OCaml, why now? (2014)

#72

Post by spyder81 »

lmm wrote: post #15

If it's about what's well-supported for compiling to Javascript, does scala.js becoming non-experimental change the landscape?

I knew about scala.js when writing the post (although it was still experimental at the time) but I didn't mention it because I don't like Scala. It looked promising when I first saw it, but then I had to write some production code in it.

My opinion now is that if you're forced to use the JVM then Scala is one of the best options. But that's a low bar, given the choice I would pick something else.

Re: Why OCaml, why now? (2014)

#73

Post by lmm »

tejinderss wrote: post #2

Now that .net is going cross platform, I see a great future of f# (another variant of ML family). Its got multi processors support too.

I think most people who wanted a cross-platform, VM-based, corporate-ecosystem-integrated ML derivative with good concurrency support have already found Scala :P.

Re: Why OCaml, why now? (2014)

#74

Post by lpw25 »

jonsterling wrote: post #63
jordwalke wrote: post #55

Earlier quoted context omitted.

I generally prefer programming with immutability, but I certainly appreciate the ability to use "benign effects" in my programs. Besides the case for performance, I have applied a strange combination of benign effects, GADTs, and functors to generate a sort of "proof of type equality" between two values passed into a framework, each of which are not known to the framework because they're passed into the framework by…

After numerous discussions with Bob Harper (and reading Derek Dreyer's work, who has been the biggest proponent for applicative functors), I have come to understand that there are only two compelling use-cases for applicative functors: 1. higher order functors. 2. modular type classes Higher order functors are kind of cool, but IMO Standard ML does not seem to be suffering too much from the lack of them. I'm not too…

I think I disagree with this. Your functors should generally be pure, and for pure functors applicative is a nicer semantics.

Consider the case of a set implemented as a binary tree. The type of such a set should be parametrised by the type of the elements and the ordering used. With applicative functors this is the case as your set type will be `Set(O).t` where `O` is a structure containing the type and the ordering. With generative functors each individual set type is abstract -- so the type itself is not parameterised by the ordering.

You could consider this to be just an example of what you are calling "Modular Type Classes", but there doesn't need to be a system of implicit module parameters for it to be useful.

Re: Why OCaml, why now? (2014)

#75

Post by tpetricek »

jordwalke wrote: post #50
tpetricek wrote: post #47

Earlier quoted context omitted.

Can I please quote your debating which particular brand of natural spring water should be given to millions of people who are thirsty in the desert when I get a chance :-)? It is a great summary of the problem with functional programming. As a person with academic background interested in real-world FP (using F# in my case), this is exactly why I'm not very enthusiastic about most functional programming papers that a…

No need to ask permission to quote me, but thanks for asking anyways. I definitely agree that shifting focus towards industrial use cases is what we need.

I guess it's more difficult than shifting the focus towards industrial use cases. Industrial use cases are a great thing, but it is something that the industry has to provide :-) (we tried to do something like that for F# here: http://manning.com/petricek2 (sorry for a shameless plug!)).

But many people contributing to functional programming (in one way or another) are in academia. They are not the best people to contribute industrial case studies - but I think there is still a lot to be done there too! The nice thing about the FRP paper is that it is really just a fun (and very simple and somewhat impractical) example, but it is nice inspiration showing (what was back then) a novel use of functional programming. Some of the more recent academic work around FP lacks this kind of creativity...

Re: Why OCaml, why now? (2014)

#76

Post by spyder81 »

didyoucheckthe wrote: post #4

> The first question I usually get ... is “Why not Haskell?”. > The answer is JavaScript. My current favorite language for this is Elm[1]. It compiles to JS, is based on Haskell, and has a few simple differences between either[2]. Elm doesn't let you use the tons of available Haskell libraries, and makes it slightly painful to integrate with JS. But it's the coolest thing for the web so far. And here's why: It uses a…

As far as I can tell Elm is more of a GUI focused language, when I was evaluating AltJS languages I was looking for something a bit more low level. The JS and DOM bindings of js_of_ocaml were what really sold me although I didn't mention this in the post.

Re: Why OCaml, why now? (2014)

#77

Post by codygman »

jonsterling wrote: post #52

Nice post! There are a lot of good reasons to use OCaml over Haskell which are more compelling than “JavaScript”, though. A few of them are: 1. modularity (and now that they have added generative functors à la SML, you can have true abstraction) 2. benign effects: in Haskell "proper", you do not have effects; rather you have "codes" for effects, which get interpreted into effects by the RTS; this rules out the possib…

Awesome response, but....

> (In case the Pedagogical Brethren wish to come and "correct" me.)

Seems very unnecessary and is a big departure from the Haskell community I'm personally used to. On top of that, it's not the tone I'm used to on HN for the most part either.

Apologies for going off topic, just felt obliged to chime in.

Re: Why OCaml, why now? (2014)

#78

Post by manu3000 »

jordwalke wrote: post #55
jonsterling wrote: post #52

Nice post! There are a lot of good reasons to use OCaml over Haskell which are more compelling than “JavaScript”, though. A few of them are: 1. modularity (and now that they have added generative functors à la SML, you can have true abstraction) 2. benign effects: in Haskell "proper", you do not have effects; rather you have "codes" for effects, which get interpreted into effects by the RTS; this rules out the possib…

I generally prefer programming with immutability, but I certainly appreciate the ability to use "benign effects" in my programs. Besides the case for performance, I have applied a strange combination of benign effects, GADTs, and functors to generate a sort of "proof of type equality" between two values passed into a framework, each of which are not known to the framework because they're passed into the framework by…

The first chapter of Dreyer's thesis "Understanding and Evolving the ML Module System" (http://www.mpi-sws.org/~dreyer/thesis/main.pdf) talks about generativity

Re: Why OCaml, why now? (2014)

#79

Post by jonsterling »

codygman wrote: post #77
jonsterling wrote: post #52

Nice post! There are a lot of good reasons to use OCaml over Haskell which are more compelling than “JavaScript”, though. A few of them are: 1. modularity (and now that they have added generative functors à la SML, you can have true abstraction) 2. benign effects: in Haskell "proper", you do not have effects; rather you have "codes" for effects, which get interpreted into effects by the RTS; this rules out the possib…

Awesome response, but.... > (In case the Pedagogical Brethren wish to come and "correct" me.) Seems very unnecessary and is a big departure from the Haskell community I'm personally used to. On top of that, it's not the tone I'm used to on HN for the most part either. Apologies for going off topic, just felt obliged to chime in.

Hey, sorry... You're right, I shouldn't have said this. Over the past few days, certain parts of the Haskell community have been particularly vicious (toward me and others), and I have been feeling a bit beleaguered. I shouldn't have brought it here though. Cheers.

Re: Why OCaml, why now? (2014)

#80

Post by jonsterling »

jonsterling wrote: post #63
jordwalke wrote: post #55

Earlier quoted context omitted.

I generally prefer programming with immutability, but I certainly appreciate the ability to use "benign effects" in my programs. Besides the case for performance, I have applied a strange combination of benign effects, GADTs, and functors to generate a sort of "proof of type equality" between two values passed into a framework, each of which are not known to the framework because they're passed into the framework by…

After numerous discussions with Bob Harper (and reading Derek Dreyer's work, who has been the biggest proponent for applicative functors), I have come to understand that there are only two compelling use-cases for applicative functors: 1. higher order functors. 2. modular type classes Higher order functors are kind of cool, but IMO Standard ML does not seem to be suffering too much from the lack of them. I'm not too…

lps25:

> Consider the case of a set implemented as a binary tree. The type of such a set should be parametrised by the type of the elements and the ordering used. With applicative functors this is the case as your set type will be `Set(O).t` where `O` is a structure containing the type and the ordering. With generative functors each individual set type is abstract -- so the type itself is not parameterised by the ordering.

You make a good point about this not being strictly about type classes. But I'd say that the issue is only a problem in the presence of implicit resolution, since otherwise, you can just bind the result of the functor to a structure once and be done with it. It becomes an issue with type classes, because you don't have the choice to share a single structure during elaboration.

IMO, the generative version is still better for most use-cases (pure or not), but it's nice that you can have both in OCaml.

Post reply on HN