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

271–280 of 294 posts

Re: Reason: A new interface to OCaml

#271

Post by MichaelGG »

ngrilly wrote: post #267
MichaelGG wrote: post #262

Earlier quoted context omitted.

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 significan…

Without examples it's hard to say. Python isn't static, and it's type system isn't as capable as MLs.

I'm entirely unconcerned about random formatting systems destroying whitespace. Some eat angle brackets. Maybe I'm not copy+pasting enough. I find "for beginners" to not be useful as a measure of anything - anything can be said to be confusing for beginners. But I can see how people might come to a different opinion.

Re: Reason: A new interface to OCaml

#272

Post by thedufer »

LeonidasXIV wrote: post #228
thedufer wrote: post #193

Earlier quoted context omitted.

As others have noted, the pipeline operator already exists in OCaml. And even if it didn't, you can define it pretty easily: let (|>) x f = f x

Can be shortened to let (|>) x f = "%apply" which utilises some language magic and is probably faster.

At risk of being pedantic, that's actually shorter. It also doesn't work, at least on the version of OCaml I'm familiar with. In order to invoke that particular bit of "language magic", you'd have to declare it external and explicitly give its type:

    external (|>) : 'a -> ('a -> 'b) -> 'b = "%revapply"
Also, `%apply` is usually the `@@` operator. For `|>`, one would expect `%revapply`.

Re: Reason: A new interface to OCaml

#273

Post by davidpelaez »

jordwalke wrote: post #238
Gonzih wrote: post #230

Earlier quoted context omitted.

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.

This would be so interesting! I don't know any other language that has made this before. But if the intention is to increase the reach of OCaml then if sound like a great plan.

Re: Reason: A new interface to OCaml

#274

Post by davidpelaez »

jordwalke wrote: post #151
mhd wrote: post #146

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…

It's great to learn about the process. Sounds amazing. I agree that JS syntax is not a selling point, from what I read the approachability of a wider audience is. However I agree that care should be taken not to fall to easily in stripping away most of the ML interesting things and end up with everything looking the same. Go, Rust, Swift, JS it's all about the same. For different languages their "user interface" is extremely similar. I think that with your proposals you have shown a great suitability to discover the balance between being different and being accesible, I don't think they have to be opposed as many language designers seem to be convinced.

Re: Reason: A new interface to OCaml

#275

Post by rixed »

ngrilly wrote: post #239
rixed wrote: post #202

Earlier quoted context omitted.

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.

Those are just techniques, other techniques achieve the same goal, such as multiprogramming, which I think is better that's why I asked.

But if you want POSIX threads and lightweight threads for the sake of it, then there are several lightweight threads libraries for ocaml (LWT being the most common one). POSIX threads you have to do from C though.

Re: Reason: A new interface to OCaml

#276

Post by jordwalke »

nikolay wrote: post #263
jordwalke wrote: post #220

Earlier quoted context omitted.

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,…

It doesn't have to be three letters, keywords can be odd numbers and achieve a similar effect - also, we likely will use the `mod` keyword instead of `module` fwiw.

Re: Reason: A new interface to OCaml

#277

Post by nikolay »

jordwalke wrote: post #276
nikolay wrote: post #263

Earlier quoted context omitted.

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,…

It doesn't have to be three letters, keywords can be odd numbers and achieve a similar effect - also, we likely will use the `mod` keyword instead of `module` fwiw.

That would be another poor choice as "mod" is used as "modulo" - there's no need to abbreviate "long" words like "module", because they are not used so often and bringing ugliness and confusion just to save a couple of characters per file is not worthy!

In this case, you don't even need the "fun" keyword as syntax-wise, "=>" alone can be used like in other languages as (parameter1, parameter2) => parameter1 + parameter2, for example - it's obvious enough without having to prefix with anything!

Anyway, I see that you want to be "different" in hopes to be "better", but, indeed, you're just "weird", instead.

"+." for float addition, "^" for concatenation, etc.

"(" ":" ")" instead of the shorter and more readable "as" .

For example, why did you choose "mutable" and not "mut"? See, your language is full of inconsistencies, it's not well-thought, it's not intuitive! For example, you chose "rec", which usually means "record" for "recursive"! In your "for"-loop, you have just "to", not "upto", but then "downto"! A good choice borrowed by some old languages would be to use the optional "by" , which defaults to +1, but in a case of a "downto", would be -1, and thus giving you a more powerful loop!

Re: Reason: A new interface to OCaml

#278

Post by jordwalke »

nikolay wrote: post #277
jordwalke wrote: post #276

Earlier quoted context omitted.

It doesn't have to be three letters, keywords can be odd numbers and achieve a similar effect - also, we likely will use the `mod` keyword instead of `module` fwiw.

That would be another poor choice as "mod" is used as "modulo" - there's no need to abbreviate "long" words like "module", because they are not used so often and bringing ugliness and confusion just to save a couple of characters per file is not worthy! In this case, you don't even need the "fun" keyword as syntax-wise, "=>" alone can be used like in other languages as (parameter1, parameter2) => parameter1 + paramet…

You don't know of any other languages that use `mod` to represent "module"? Say, perhaps, the one you just advocated for in another thread?

And there are in fact issues with using x => y syntax for lambdas without a leading fun/fn keyword:

let x = (this, is, a, really, long, thing ) => 10;

- In that example it's not possible to tell if the leading ( is the start of a pattern for the sake of lambda, or a tuple. This happens with ES6 today as well (destructured record argument). It's not just a matter of human readability, it's a matter of building an efficient parser.

- The (x : y) syntax for type annotations is not new or weird to many people. That's the syntax used by ML, OCaml, and JS (Flow).

- We're likely going to swap some operators for string concat, so that it would be the more common ++ operator.

- The rest of the observations are good and we should address them soon.

Re: Reason: A new interface to OCaml

#279

Post by nikolay »

jordwalke wrote: post #278
nikolay wrote: post #277

Earlier quoted context omitted.

That would be another poor choice as "mod" is used as "modulo" - there's no need to abbreviate "long" words like "module", because they are not used so often and bringing ugliness and confusion just to save a couple of characters per file is not worthy! In this case, you don't even need the "fun" keyword as syntax-wise, "=>" alone can be used like in other languages as (parameter1, parameter2) => parameter1 + paramet…

You don't know of any other languages that use `mod` to represent "module"? Say, perhaps, the one you just advocated for in another thread? And there are in fact issues with using x => y syntax for lambdas without a leading fun/fn keyword: let x = (this, is, a, really, long, thing ) => 10; - In that example it's not possible to tell if the leading ( is the start of a pattern for the sake of lambda, or a tuple. This h…

I know Rust uses "mod", but Rust is consistent and predictable - it also uses "mut" unlike in Reason.

Regarding ":" to denote type - I like it and it's widely used across various language, but not enforced with parentheses for typecasting.

Re: Reason: A new interface to OCaml

#280

Post by kirse »

smoothdeveloper wrote: post #269
LeonidasXIV wrote: post #222

Earlier quoted context omitted.

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

Expressions of various kinds - Async, seq, query, etc; record type "constructors"... that's all I can think of off the top of my head.

F# in general is a beautiful language though, I can't say I've ever thought about the "curly bracketisms" personally because I'm too busy being excited about how much fun it is to write over C#.

Post reply on HN