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

261–270 of 294 posts

Re: Reason: A new interface to OCaml

#261

Post by tom_mellior »

alex_muscar wrote: post #232

Nice 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 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.

But I guess in Reason they could be first class. All it takes is to interpret an occurrence of an n-ary constructor

  Foo
as

  (fun a1 ... an => Foo a1 ... an)

Re: Reason: A new interface to OCaml

#262

Post by MichaelGG »

ngrilly wrote: post #237
LeonidasXIV wrote: post #223

Earlier quoted context omitted.

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.

This is not correct. You can still auto format just fine. It won't change indentation obviously, since that would change the meaning of the program. What problems do you have in mind?

I'm also very skeptical that they make sharing code difficult. Any indentation issues will be readily apparent in a compiled language.[1] Plus I doubt this is a serious issue in the first place. And certainly it doesn't outweigh the massive gain in the main activity: reading and writing code.

1: Sure there's always a few counter examples. But in general this isn't an issue. Just like inferring function types. It's rare to have a true mistake end up changing things but simultaneously compile fine.

Re: Reason: A new interface to OCaml

#263

Post by nikolay »

jordwalke wrote: post #220
nikolay wrote: post #212

Earlier quoted context omitted.

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?

It would make the function name stand out from the parameters. Again, to pick one unintuitive abbrevation, just because it's a 3-letter one like let, it's just not serious! Make all be 3:

    type -> typ
    switch -> swi
    if -> iff
    else -> els
    in -> inn
    downto -> dow
    module -> mod
Call you language 3-letter reason. You see how it ridiculous it gets? You can't make all keywords be 3-letter and if people care about alignment, they can further align, but most don't care as much as you think!

Re: Reason: A new interface to OCaml

#265

Post by joshmarlow »

Gonzih wrote: post #245
eru wrote: post #244

Earlier quoted context omitted.

Have you ever tried the Jane Street standard libraries?

yeah, but it's not the standard library. this is my problem. what about compatibility with the other tools/libs?

I think for the most part the community is standardizing on using Core as though it was the standard. As an example: Real World OCaml, for instance, assumes Core is installed (note: I believe it is coauthored by one of the Jane Street employees).

Re: Reason: A new interface to OCaml

#266

Post by alex_muscar »

tom_mellior wrote: post #261
alex_muscar wrote: post #232

Nice 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 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. But I guess in Reason they could be first class. All it takes is to interpret an occurrence of an n-ary constructor Fo…

Yes, that is do-able, if they want to make this change.

Re: Reason: A new interface to OCaml

#267

Post by ngrilly »

MichaelGG wrote: post #262
ngrilly wrote: post #237

Earlier quoted context omitted.

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.

This is not correct. You can still auto format just fine. It won't change indentation obviously, since that would change the meaning of the program. What problems do you have in mind? I'm also very skeptical that they make sharing code difficult. Any indentation issues will be readily apparent in a compiled language.[1] Plus I doubt this is a serious issue in the first place. And certainly it doesn't outweigh the mas…

You're right about auto-formatting being possible with significant whitespaces... but:

When you copy-paste a block of code in another block of code, with significant whitespace you have to correctly reindenting everything very carefully, while with explicit blocks you can let an automatic formatter do the work.

When you copy-paste a block of code in chat/email/comment, it is sometimes difficult to preserve significant whitespaces. For example, I've seen a lot of blog comments "eat" the white spaces at the beginning of each line (example: https://unspecified.wordpress.com/2011/10/18/why-pythons-whi...)

It can be difficult to fix code incorrectly mixing spaces and tabs (especially for beginners).

Rob Pike wrote on this topic:

> Some observers objected to Go's C-like block structure with braces, preferring the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause. It is better to forgo convenience for safety and dependability, so Go has brace-bounded blocks.

Source: https://talks.golang.org/2012/splash.article

Re: Reason: A new interface to OCaml

#268

Post by co_dh »

ngrilly wrote: post #237
LeonidasXIV wrote: post #223

Earlier quoted context omitted.

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.

I've been programming in Python for about 10 years and still love it.

Re: Reason: A new interface to OCaml

#269

Post by smoothdeveloper »

LeonidasXIV wrote: post #222
jordwalke wrote: post #151

Earlier quoted context omitted.

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…

I am not a fan of introducing curly brackets in a similar way I am not a fan of curly-bracketisms in F#, it makes for a clumsy noise to a relative distraction-free language like OCaml. It feels like trying to get Algol-family programmers on board, whereas OCaml users have been using ( and ) as well as begin/end since a long time. But an advantage I see with the new comment syntax is that there are is that there is no…

Curious what are the curly-bracketisms in F#?

Re: Reason: A new interface to OCaml

#270

Post by reality_czech »

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…

It's important to use an incompatible dialect of every language and toolchain that your company uses. If you just use the vanilla project, the company might be tempted to adopt outside open source projects rather than reinventing the wheel in-house. This would be a terrible thing because it Wasn't Invented Here (tm). Also, new college graduates might not be appropriately awed by the pile of High Tech Stuff you show them on day 1, if just anyone else could use it outside the company.

For example, when you're using C++, be sure to rewrite the string and stream classes (like Folly does). This will ensure that you can't contribute anything back to the community, and they can't contribute to you. Be sure to use all the funny C++ features that haven't quite been standardized or supported correctly yet.

For OCaml, it's harder, since it doesn't have as many poorly designed and duplicative features. But with enough effort, you too can fix the "problem" of your code being similar to other people's code.

Post reply on HN