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

Reason: A new interface to OCaml

facebook.github.io

Post reply on HN
Print view View original

211–220 of 294 posts

Re: Reason: A new interface to OCaml

#211

Post by pathsjs »

nv-vn wrote: post #198
robohamburger wrote: post #115

I took ocaml for a spin a couple months ago and compared to more recently created languages it seems a bit crufty. If they can simplify the build system to be on par with something like cargo that would be swell. Also: having rust style traits or haskell classes would be amazing. Also macros that aren't obscure and hard to use compiler plugins please :) Hopefully it ends up being more than just questionable sugar aro…

Try out the OASIS build system. It's very similar to Cargo/Cabal (although it's separate from the package manager) in that you basically declare what you're working with and it does all the building for you. It's super simple to use and is good enough for 95% of use cases. As for traits/type classes, this is in development with the modular-implicits (experimental) fork of the compiler. It's highly likely that some fo…

I tried it. I found no easy way to have dependencies isolated per project. Any suggestions?

Re: Reason: A new interface to OCaml

#212

Post by nikolay »

jordwalke wrote: post #162
nikolay wrote: post #145

Nice, but I always wonder why function is abbreviated as the longer unambigous fun and not just fn?!

Jordan here (I work on Reason): I agree with you but one benefit of `fun` is that it aligns better with multiples of two spaces. It's important when lists end up wrapping: /* Nice multiple of two spaces */ fun myFun xyz abc => { doSomeThings(xyz, abc); }; /* yikes, only one horizontal space between * doSomething and abc on the line above */ fn myFun xyz abc => { doSomeThings(xyz, abc); }; I'm obviously no stranger to…

Not a good enough reason, sorry! With syntax coloring, it's less irrelevant as well.

Re: Reason: A new interface to OCaml

#213

Post by reycharles »

ubertaco wrote: post #172

As excited as I was to see a big new thing in OCaml-land, I have to say my excitement died down as I read on. 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 unam…

> 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?

This is actually an improvement in my opinion. Reusing the syntax for function application in type application makes the language more uniform. It's even necessary with dependent types.

A lot of the better changes reminds me of the revised syntax http://caml.inria.fr/pub/docs/manual-camlp4/manual007.html

(why would you introduce the ternary operator when if-then-else is so much nicer to read?!)

Re: Reason: A new interface to OCaml

#214

Post by mseri »

jordwalke wrote: post #128
mseri wrote: post #68

I love OCaml, but that's a really nice reshape of OCaml syntax! And apparently things will be interoperable. I am really curious to see where it goes. EDIT: and they want to use and maintain compatibility with ppx. Great news

Interop with OCaml is perfect and should remain so. ppx should work (modulo issues that we're not aware of). You can even upgrade your existing OCaml source code to be in the Reason style by using the versatile `refmt` program that is included.

Thanks. I am definitely going to play with it!

Re: Reason: A new interface to OCaml

#215

Post by runT1ME »

SwellJoe wrote: post #200

So, 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.

Re: Reason: A new interface to OCaml

#216

Post by mseri »

incepted wrote: post #54

Interesting but since they are designing a revised syntax, I wish they had got rid of Ocaml's semi colon. These stand out in 2016.

Why? It has more benefits that downsides.

I think the only complains we can do at the moment are the switch from '' to '=>' for functions. But we will see how it will evolve

Re: Reason: A new interface to OCaml

#218

Post by jordwalke »

kbenson wrote: post #197
wtetzner wrote: post #183

Earlier quoted context omitted.

That's a comparison of syntax, which has nothing to do with compiling to Javascript.

Whether they have an intermediate step that is OCaml or not is irrelevant. Most compilers have one of more intermediate representations between source and executable. I think providing a syntax comparison to Javascript right next to a syntax comparison to OCaml is a clear indication that they are marketing to Javascript programmers, and the only reason for that is if they intend thelanguage as a replacement or supple…

In 2016, "marketing to JavaScript programmers" is pretty much the same thing as "marketing to programmers". Providing context that the vast majority of programmers will understand is helpful regardless of the compilation strategy. That being said, of course people want a language that can compile to JavaScript, and it's worth mentioning the expanding set of options for doing so. But the syntax comparison really would be worthwhile even if it weren't the case, if only to provide context to what is likely the largest developer community that exists today.

Re: Reason: A new interface to OCaml

#219

Post by Cyph0n »

jestar_jokin wrote: post #174
Cyph0n wrote: post #48

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…

A similar language might be Haxe, which can target C++, Java, C#, PHP, JavaScript, Python, Lua, and Neko languages, and make use of the tooling/build chain for those languages. 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 wri…

Ah, I forgot about Haxe. Someone correct me if I'm wrong, but isn't Haxe essentially a transpiler with its own stdlib? I think Reason is different is that it explicitly integrates into the OCaml build process.

Re: Reason: A new interface to OCaml

#220

Post by jordwalke »

nikolay wrote: post #212
jordwalke wrote: post #162

Earlier quoted context omitted.

Jordan here (I work on Reason): I agree with you but one benefit of `fun` is that it aligns better with multiples of two spaces. It's important when lists end up wrapping: /* Nice multiple of two spaces */ fun myFun xyz abc => { doSomeThings(xyz, abc); }; /* yikes, only one horizontal space between * doSomething and abc on the line above */ fn myFun xyz abc => { doSomeThings(xyz, abc); }; I'm obviously no stranger to…

Not a good enough reason, sorry! With syntax coloring, it's less irrelevant as well.

When we start talking about syntax coloring, you know we're just one step closer to actually debating the color of a literal bike-shed!

Jokes aside, what would your highlighting do in this case?

Post reply on HN