171–180 of 294 posts
Can we please keep using parens for function invocation? Leaving them out hurts readability.
When so much of your code is function calls, all those commas and parenthesis start cluttering things.
I don't really see most of the changes as improvements.
Having a different, explicitly-noticeable syntax for mutable updates is nice, because it calls out mutability (which should be used sparingly).
I don't see extra braces as necessarily an improvement, given that OCaml's local scopes are already quite unambiguous thanks to "let ... in". On that note, Removing "in" and just going with semicolons removes another "smelly-code-callout" by making it less obvious what's imperative and what's functional.
I actually don't like ambiguity between type annotation and value assignment in my records. It's clear in current OCaml that {a: int} is a type declaration and {a = 1} is a value declaration/assignment. Moving to colons-for-record-values is at best a bikesheddy, backwards-incompatible change for change's sake, and at worst a breaking-change way of code less clear.
Speaking of making code less clear, how is "int list list" not clear? It's an int-list list. As in, a list of int-lists. So of course it should parse as "(int list) list". Why change to backwards annotations? Just to prevent existing code from working as-is, and making people used to reading ML spend extra brain cycles on remembering that your types read the opposite way?
And they make a huge deal out of their type for tuples being "(a, b)" instead of "(a * b)". Yeah, okay, I get it. It's not that big a deal, since people are used to reading product types as, well, products.
The other thing that seems weird to me is the need to change to a "fat arrow" instead of a "skinny arrow", again for no real reason. In fact, it just makes it more likely that you'll confuse it with a comparison operator. Nobody tries to type ">-", but people try to type ">=" all the time. You're just switching for the sake of switching, and it's not an improvement.
Their example code of their replacement for match...with is especially egregious. If you showed me the OCaml snippet and the Reason snippet unlabelled, I would think that the OCaml snippet is the new-and-improved version, since it's much more compact, much less noisy, and reads more like what it's trying to do ("match my_variable with either SomeValue x or SomeOtherValue y").
Another thing they make a lot of noise about is requiring fewer parens in some places. But then, they also require more parens in other places. So...okay? I guess? Not really a win.
And why rename equality operators? Are you really going to tell me that people prefer that their languages have "==="?
i noticed this in the examples: | List p (List p2 (List p3 rest)) => false /* 3+ */ has the regular list destructuring in pattern match syntax been removed? that's pretty sad, if so - lists are the default data structure in ocaml, and it's worth retaining some special syntax for cons especially in pattern matches.
This 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…
So you can abstract the syntax from the runtime, but the semantics are often different per target - e.g. accessing the filesystem in Node.js will be different to C++, due to the non-blocking I/O mechanism.
As an aside, the Haxe compiler is written in OCaml. I think there'd be a delicious juxtaposition if it was re-written in Reason. Writing Reason to generate OCaml to create Haxe to generate Java to generate bytecode...
It seems to me that Rust would be pretty much strictly better than this. In particular Rust has similar syntax, seems to have all Reason's features plus the linear types and regions/borrowing that allow memory and concurrency safety while still being able to mutate memory and not being forced to use GC. They are aware of Rust since they cite it in their page, so I wonder why they decided to create this instead of usi…
Use rust when you need the performance. Use a GC'd language like reason when you want less things to reason about.
Earlier quoted context omitted.
For now: - Teaching new programmers how to use ML, and OCaml in particular. - Keeping consistent formatting rules among a large team or project and automating that within your editor. - Benefiting from the comprehensive pattern matching checks provided by the OCaml compiler. - Benefiting from faster compile times of `ocamlc`, or faster native execution time of `ocamlopt`. - Benefiting from Merlin, and the new version…
Interesting project. Ever since being exposed to a bit of Standard ML (which never had much of a "real-world" standard library, as far as I could figure out), I always wanted to like OCaml, but couldn't quite get over the odd syntax. It's been a while, but taking a look at this comparison of SML and OCaml again: http://www.mpi-sws.org/~rossberg/sml-vs-ocaml.html It feels a bit like you've landed in some strange neith…
Which with OCaml, is not an issue thanks to the decent type system!
I agree with you - there is something to be said for just not going against the grain where you can tolerate it. I ask myself, "Are semicolons really the hill I want to die on?".
i noticed this in the examples: | List p (List p2 (List p3 rest)) => false /* 3+ */ has the regular list destructuring in pattern match syntax been removed? that's pretty sad, if so - lists are the default data structure in ocaml, and it's worth retaining some special syntax for cons especially in pattern matches.
For me the odd bit is that they called the constructor List instead of Cons.
I hope this doesn't sound like trolling, but JavaScript's syntax is now a selling point? I kinda-sorta get the reason why people want an actual JavaScript stack on the backend, but I never heard that syntax/semantics brought people from e.g. Rails to Node. Sure, OCaml isn't even the nicest syntax in the ML family, but I'm not sure whether that's worth it, especially considering that almost any "X-like" language often…
Jordan here (I work on Reason) I've mentioned elsewhere that the primary goal for now was to get the tooling automated as much as possible, so that when we receive common feedback, we can adapt to that feedback and trivially migrate people's code forward. I don't think JavaScript's syntax is a selling point and I am someone with a lot of JavaScript experience. I also don't think that OCaml's syntax today is a selling…
Under "Why OCaml?" on the Reason page, it states, "OCaml has a very mature (and still growing) ecosystem for targeting browser and JavaScript environments with a focus on language interoperability and integration with existing JavaScript code," and "Reason‘s non-invasive approach to the OCaml compiler allows Reason code to take advantage of all of the existing OCaml compiler optimizations/backends such as ... and even JavaScript compilation."
It seems like what's being said is that one of the main goals for Reason is to integrate with JavaScript, and it would seem to make sense instead of changing between language syntaxes, you'd want more in common between them, so it makes sense why they are similar. I'm confused as to why you seem to be trying to distance Reason and OCaml from JavaScript, when it definitely seems like the similarity with and integration with JavaScript would be a driving factor in Reason's development now, even if maybe it wasn't in the beginning.
Reason seems really cool, btw.
Earlier quoted context omitted.
The pipe operator's still there.
I've never written OCaml, just SML and F#, but I thought that OCaml didn't have the |> operator.