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

251–260 of 294 posts

Re: Reason: A new interface to OCaml

#251

Post by ubertaco »

tom_mellior wrote: post #247
ngrilly wrote: post #236

Earlier quoted context omitted.

The 'in' is what makes it difficult to understand for someone not familiar with OCaml syntax and semantics. Reason makes it easier.

I've heard that said, but I don't see how it's a big deal. OK, the very first example introducing let bindings would have to come with a sentence like "the 'in' part of 'let ... in' means 'in' just like in English: 'let' the binding be valid 'in' what follows". You don't have to define a whole new syntax where a single sentence in a language tutorial might be enough. But I admit that I probably can't fully appreciate…

Yeah, I don't know what doesn't read easily about "let x = 3 in x - 1" -- it is straightforward: x is equal to 3 in the expression "x - 1".

Re: Reason: A new interface to OCaml

#252

Post by chrismorgan »

wtetzner wrote: post #186
andrewchambers wrote: post #175

Earlier quoted context omitted.

Both garbage collected languages and rust offer memory safety, rust just trades better performance for a more complicated borrow system. Use rust when you need the performance. Use a GC'd language like reason when you want less things to reason about.

> rust just trades better performance for a more complicated borrow system. I would say Rust trades more predictable performance for a more complicated borrow system.

Rust’s borrow system is actually not the key part; if it were just that, then yes, it would be purely a complication performance would be the only important part about it when comparing it with garbage collection. No: the key part is the ownership model, that an object is owned in precisely one location. Borrowing sits on top of and fits into that, not the other way round.

The ownership model is the part that I don't myself yearning for in other languages I work in such as Python and JavaScript.

Re: Reason: A new interface to OCaml

#253

Post by mseri »

cm3 wrote: post #243
mseri wrote: post #234

Earlier quoted context omitted.

It's coming with flambda. Am I wrong?

Not that I'm aware of. Edit: flambda has been released in 4.03 and I'm using it but utop is 17MB, so I doubt proper dead code elimination is part of flambda.

Sorry, what I meant is that I remember having read somewhere that dead code elimination, or some sort of, will be one of the optimization coming in the future due to the introduction of flambda. When I go back home I will try to find a reference, I might recall wrongly

Re: Reason: A new interface to OCaml

#254

Post by mark_l_watson »

Reason looks interesting. I have had a 5 year run of alternating between really liking Haskell, and sometime thinking that my own development process was too slow using Haskell. I am putting Reason on my try-it list.

Documentation suggestion: add examples for string manipulation.

Re: Reason: A new interface to OCaml

#256

Post by xvilka »

xvilka wrote: post #255

It would be nice if they'll make it work on Windows platforms. There is already an issue for that[1]. It also depends from the Windows support in OCaml itself and opam[2]. [1] https://github.com/facebook/reason/issues/470 [2] https://github.com/ocaml/opam/issues/2191

There is some work is done for opam https://github.com/dra27/opam/commits/windows

Re: Reason: A new interface to OCaml

#257

Post by cm3 »

mseri wrote: post #253
cm3 wrote: post #243

Earlier quoted context omitted.

Not that I'm aware of. Edit: flambda has been released in 4.03 and I'm using it but utop is 17MB, so I doubt proper dead code elimination is part of flambda.

Sorry, what I meant is that I remember having read somewhere that dead code elimination, or some sort of, will be one of the optimization coming in the future due to the introduction of flambda. When I go back home I will try to find a reference, I might recall wrongly

You're probably right that it was mentioned on Jane Street's blog that flambda will enable such optimizations. I recall one of the ocamlc devs saying that real dead code elimination is planned but not available yet.

Re: Reason: A new interface to OCaml

#258

Post by alex_muscar »

jordwalke wrote: post #235
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 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'…

I didn't say constructor arguments don't have tuple semantics :). In OCaml tuples are a "unit", i.e. you can't use (,) as an operator. In that sense they match with the constructor semantics: it needs all its arguments at once. It's the constructors not being functions that I was complaining about. Also, I'd say that capitalisation alone is not enough to compensate for constructors looking like they're curried functions. But that's just a matter of taste.

Re: Reason: A new interface to OCaml

#259

Post by latkin »

int_19h wrote: post #221
ufo wrote: post #168

Earlier quoted context omitted.

Maybe I'm too used to Ocaml to comment but I think using `=` for mutation is a bit misleading because it might make it appear that `x.mutablefield = bla` and `let x = bla` are the same thing, which is the case for typical imperative languages (but definitely not for Ocaml). BTW, one thing that I do find awkward about Ocaml's syntax is the difference between := and <-. Dunno if its possible to unify them in a sane man…

F# doesn't unify them, but it makes := largely redundant by letting you do "let mutable ...", and then assign to it with "<-" - so you simply don't need to use refs if you just need some mutable data (you still need them if you want to have a closure mutate something it closed over).

`ref` and `mutable` were unified in F# 4.0. You no longer need to use a `ref` when closing over a mutable value, you can use `let mutable` in all cases and the compiler will figure it out for you. The generated code is the same as before, it's just that there's a unified syntax now.

There is an optional warning one can enable which emits when a `let mutable` is converted to a `ref` behind the scenes - for those who want to by hyper-aware of hidden allocations.

Re: Reason: A new interface to OCaml

#260

Post by tom_mellior »

jordwalke wrote: post #250
tom_mellior wrote: post #247

Earlier quoted context omitted.

I've heard that said, but I don't see how it's a big deal. OK, the very first example introducing let bindings would have to come with a sentence like "the 'in' part of 'let ... in' means 'in' just like in English: 'let' the binding be valid 'in' what follows". You don't have to define a whole new syntax where a single sentence in a language tutorial might be enough. But I admit that I probably can't fully appreciate…

Except when you're in the top level - in which case you don't use `in`. Oh, and don't forget all the nuance of interleaving imperative commands. I'm an experienced OCaml dev and this trips me up (the "ml compared" section of the docs lists some common pitfalls that Reason resolves).

Ah, but here you seem to be talking about when to write 'in'. Reading it is much simpler: Just ignore that it's there, and voilà, you're set.

(I'm an experienced OCaml dev and := versus <- trips me up from time to time when choosing which one to write, but not when reading code.)

Post reply on HN