Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
lpw25
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
45 ms
·
1.
▲
by
lpw25
3y ago
This is part 3 of a series, the previous posts were: 1. Locality: https://blog.janestreet.com/oxidizing-ocaml-locality/ (Discussion: https://news.ycombinator.com/item?id=36094799 ) 2. Rust-style owner
2.
▲
by
lpw25
3y ago
These are the posts the article is referring to: Part 1: https://blog.janestreet.com/oxidizing-ocaml-locality/ Part 2: https://blog.janestreet.com/oxidizing-ocaml-ownership/
3.
▲
by
lpw25
3y ago
Our long term aim is to upstream all of our work from our branch of the OCaml compiler. Of course, that is contingent on the ideas we’re developing there being accepted by the community. There are two main reasons we work on our own branch:
4.
▲
by
lpw25
10y ago
> OCaml (concurrency isn't the best) Pet peeve: OCaml's concurrency is pretty good, it's parallelism that it struggles with.
5.
▲
by
lpw25
10y ago
Modularity
6.
▲
by
lpw25
11y ago
> Is there any place in the official OCaml repository / issue tracking system / wiki etc where one could check the status? You can see some things on: https://github.com/ocamllabs/ocaml-modular-implicits
7.
▲
by
lpw25
11y ago
The size of Core executables is mostly addressed by module aliases. Unfortunately the public release of Core still uses packing instead of module aliases because oasis/ocamlbuild don't easily support them.
8.
▲
by
lpw25
11y ago
It's being very actively worked on. No solid ETA yet but I would expect the coming version or the one after to work out of the box.
9.
▲
by
lpw25
11y ago
> I still serve on program committees and review articles for journals and the like. Judging academia from your experience on program committees is like judging the entertainment industry from watching Britain's Got Talent.
10.
▲
by
lpw25
11y ago
It is, but it is worth noting that when OCaml or Haskell programmers talk about type inference they are usually referring to global type inference which allows an argument's type to be inferred from its uses. For example: let f x
11.
▲
by
lpw25
11y ago
Just a quick note to say that jdh hasn't been an active OCaml user for years. He trolls on behalf of F# these days.
12.
▲
by
lpw25
11y ago
Functors => higher-kinded types
13.
▲
by
lpw25
11y ago
You need at least one module that does something at top-level, otherwise your program won't do anything.
14.
▲
by
lpw25
11y ago
> Mind naming any fundamentally new concepts introduced by Haskell or OCaml? For OCaml: - row polymorphism (in particular polymorphic variants) - higher-order and applicative functors (not the Haskell thing). - first-class modules For bo
15.
▲
by
lpw25
11y ago
OCaml has had type-directed record disambiguation for a few versions now. So you can quite easily reuse field names these days.
16.
▲
by
lpw25
11y ago
> Anecdotally, the runtime also falls down when you need to use large arrays or strings, or do lots of floating-point calculations. Anecdotally from one specific well-known troll. (I'm not saying it is or isn't true, just that
17.
▲
by
lpw25
12y ago
Indeed classes are great for these kinds of encodings. It is one of the use cases for which classes are the nicest approach in OCaml. For example, see this section of Real World OCaml: https://realworldocaml.org/v1/en&#
18.
▲
by
lpw25
12y ago
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
19.
▲
by
lpw25
12y ago
Multicore: https://github.com/stedolan/ocaml Modular implicits: https://github.com/ocamllabs/ocaml-modular-implicits
20.
▲
by
lpw25
12y ago
> the languages that compile to javascript are a poor substitute (bloated code sizes, interop issues, poor runtime performance, etc) js_of_ocaml has good code size and performance in my experience. Interop with js is variable -- some js
21.
▲
by
lpw25
12y ago
> The kind of mistakes that good programmers make are not normally caught in code reviews. That's pretty much the definition of a good programmer; their mistakes are rare and subtle. I think the opposite is true. Good programmers kn
22.
▲
by
lpw25
12y ago
> Also, has anyone ever used gadts to implement type safe syntax trees like that? I believe the main use is for embedded DSLs. I'm afraid I don't have any practical examples on hand to link to.
23.
▲
by
lpw25
12y ago
> I would say F# is an implementation that includes all the good parts of Ocaml the language I like F#, but this just isn't true: - Polymorphic variants - GADTs - Module system The last one, in particular, is one of the best feature
24.
▲
by
lpw25
12y ago
Actually OCaml does support recursive types. Recursion through objects and polymorphic variants is always supported, and full recursive types can be turned on with the `rectypes` command-line option.
25.
▲
by
lpw25
12y ago
OCaml has excellent compile-to-JavaScript support. Facebook use this to compile their Hack type-checker for an in-browser IDE. I imagine they do something similar for Flow.
26.
▲
by
lpw25
12y ago
They both seem to produce a new version about once a year, so there's not much difference there.
27.
▲
by
lpw25
12y ago
> This is why unsafePerformIO is unsafe: it’s completely foreign to the programming model Maybe, although it is also not type safe because Haskell doesn't have a value restriction for polymorphism. (or looked at another way Haskel
28.
▲
Simplifying 0install's solver with OCaml's functors
(roscidus.com)
37 points
by
lpw25
12y ago
|
9 comments
29.
▲
H.261 decoder in OCaml, compiled to JavaScript
(andrewray.github.io)
5 points
by
lpw25
12y ago
|
1 comments
30.
▲
by
lpw25
12y ago
Most of these things seem nice but are actually a bad idea. Many of the rest are already implemented or in the process of being implemented. A couple of them are good ideas which are awkward to implement due to politics (e.g. the licence) o
More ›