I miss dead code elimination the most, especially when building code that uses Core.
Reason: A new interface to OCaml
231–240 of 294 posts
Re: Reason: A new interface to OCaml
#232Nice to see that OCaml is getting so much love at facebook. Unfortunately, adding a new syntax that's almost OCaml, but not quite, doesn't seem like such a great idea. While it might make the language accessible to more people, it runs the risk of fragmenting the community.
I know syntax is subjective, but some of the choices seem a bit odd. For example, declaring variants and using their constructors looks like Haskell, but the semantics is still OCaml. In Haskell, constructors are first order so they can be passed as functions, and partially applied. It makes sense that their declaration and use looks like function declaration and function calls. In OCaml they are not first class, that is, you can't pass the as arguments, or partially apply them. That's why it makes sense for the declaration to look like a tuple, and the use to look like a function applied to a tuple--well, somewhat, you can still argue that it's still confusing because you might expect to be able to apply the constructor to a tuple variable, but well, such is life :). Unless constructors are first class in Reason--it doesn't look like it from a quick scan through the docs--this particular syntactic difference is of dubious value, and, worse, it can be misleading to newcomers.
Also, changing `match` to `switch` seems gratuitous as well, and it also loses some of the meaning of the original. i.e. "I want to match this value against this set of patterns".
Finally, I know that using `begin` and `end` for blocks is verbose and Pascal-ish--which people seem to hate for some reason--but using { } for scopes looks out of place, and leads to awkward cases like this:
try { ... } { | Exn => ... };
Re: Reason: A new interface to OCaml
#233If you'd like to play with Reason you can do it online here:
https://codeboard.io/projects/17520?view=2.1
Of course, you can also create your own Reason projects.
Re: Reason: A new interface to OCaml
#234I miss dead code elimination the most, especially when building code that uses Core.
It's coming with flambda. Am I wrong?
Re: Reason: A new interface to OCaml
#235Nice to see that OCaml is getting so much love at facebook. Unfortunately, adding a new syntax that's almost OCaml, but not quite, doesn't seem like such a great idea. While it might make the language accessible to more people, it runs the risk of fragmenting the community. I know syntax is subjective, but some of the choices seem a bit odd. For example, declaring variants and using their constructors looks like Hask…
> In OCaml they are not first class, that is, you can't pass the as arguments, or partially apply them. That's why it makes sense for the declaration to look like a tuple, and the use to look like a function applied to a tuple--well, somewhat, you can still argue that it's still confusing because you might expect to be able to apply the constructor to a tuple variable, but well, such is life
If I understand what you're saying, you provided a reason why variant arguments should not look like function application (because they have different semantics than function application), and then in the same paragraph suggested that variant arguments should have tuple syntax, while admitting that they don't actually have tuple semantics either.
The truth is that variant arguments in `Reason` actually do not have function application syntax - note the distinguishing, leading capitalized letter on the variant. Sure, they share the fact that arguments are specified via a space separated list, but function application doesn't have a monopoly on the syntactic pattern of things separated by spaces. The argument quickly breaks down.
Re: Reason: A new interface to OCaml
#236Earlier quoted context omitted.
This definitely makes me feel more warmly toward OCaml. Syntax has kept me away in the past. It's silly, but it's really hard to evaluate a language if you can't read the examples.
> It's silly, but it's really hard to evaluate a language if you can't read the examples. No, this is not a silly notion. But I don't think the difference Reason makes is as big as you think. I mean, I don't really believe that you can read this: let foo = if (cond) { x } else { y }; foo + 1 but not this: let foo = if cond then x else y in foo + 1
The 'in' is what makes it difficult to understand for someone not familiar with OCaml syntax and semantics. Reason makes it easier.
Re: Reason: A new interface to OCaml
#237I started off a bit skeptical with the What's OCaml's status with multithreading? Are there any proposals for more flexible operators, so there doesn't need to be different operators for different numerics? (F# solves this by allowing inlined functions.)
If there is one single thing from F# I would like to have in OCaml it is the whitespace syntax. I can write nice OCaml, but I often need to exploit corners in the grammar and cheating around with precedence and @@ to get my code to not be full of clumsy parens, anonymous functions etc.
I loved so much significant whitespaces when I discovered them in Python! Since then, a few years have passed, and I've come to the conclusion that significant whitespaces are a mistake: they make automatic code formatting difficult or impossible (gofmt, refmt, etc.), they make sharing code snippets by chat or email error prone, they make automated code generation error prone too. Please don't add them.
Re: Reason: A new interface to OCaml
#238This looks very interesting. I've always had OCaml in mind but never actually got around to using it in a project. Facebook could have done a better job describing what exactly this is, but they do provide a good overview at the end of the page (strangely!) [1]. In summary, Reason [2] is a new language (correction: interface to OCaml) that shares a part of the OCaml compiler toolchain and runtime. I don't know of any…
I always liked ML family PLs, but my problem with OCaml is lack of good stdlib. This is why I never invested a lot of time in to it sadly. Reasons looks like a more solid out of the box ocaml distribution which I actually like a lot. Will play with it.
Glad to hear it! We've also tossed around the idea of having a precompiled standard lib come with it upon installation. We're certainly not looking to increase the number of standard libraries, when there's already so many to choose from, but including/pre-building/curating is certainly within the scope.
Re: Reason: A new interface to OCaml
#239So, I know OCaml is impressively fast. And, I know OCaml is impressively terse ("concise" may be a more positive term). But, I wonder what would make one choose OCaml (or a variant of it like this) over some of the other new or old languages that exhibit some excellent characteristics for modern systems. In particular, a convincing concurrency story seems mandatory. I don't know enough to know if OCaml (or this varia…
Because ocaml type system is state of the art unlike go or elixir. Also, what's a convincing concurrency story? Does multiprogramming count?
A convincing concurrency story is the one offered by the two languages you mentioned: Go (with memory sharing, which is an advantage or a drawback depending on your goals), and Elixir (no memory sharing between lightweight processes).
A version of OCaml offering a similar "concurrency story" would have a lot of appeal.
Re: Reason: A new interface to OCaml
#240So, I know OCaml is impressively fast. And, I know OCaml is impressively terse ("concise" may be a more positive term). But, I wonder what would make one choose OCaml (or a variant of it like this) over some of the other new or old languages that exhibit some excellent characteristics for modern systems. In particular, a convincing concurrency story seems mandatory. I don't know enough to know if OCaml (or this varia…
OCaml is a much more modern language than Go.
Yes and no, depending on which aspect of the language you consider:
- Type system -> OCaml is more modern (despite being designed before Go)
- Concurrency, parallelism, garbage collector, tooling -> Go is more modern (Reason is improving the tooling with refmt for example; work is ongoing on parallelism)