5 ms·

I started off a bit skeptical with the <- renaming to =. Mutability should be rare enough that <- makes things stand out. But apart from that I think I rather l

I started off a bit skeptical with the <- renaming to =. Mutability should be rare enough that <- makes things stand out. But apart from that I think I rather like this syntax, on the whole. Not a fan of semicolons. It also makes me appreciate F#'s #light syntax (now its default). Using whitespace really clarifies stuff, and there's always in and ; for fallback. What's OCaml's status with multithreading? Are there any proposals for more flexible operators, so there doesn't need to be different operators for different numerics? (F# solves this by allowing inlined functions.)

kcsrk 10y ago
Multicore support is progressing nicely. Only earlier today I made a PR for adding nativecode compilation for multicore: https://github.com/ocamllabs/ocaml-multicore/pull/47 https://github.com/ocamllabs/ocaml-multicore/pull/47. A lot more information about the multicore OCaml project can be found here: https://ocaml.io/w/Multicore https://ocaml.io/w/Multicore
jordwalke 10y ago
I suspect the syntax of `<-` (or lack thereof) will be a common topic of discussion. Let's see how various audiences respond to this change and then discuss if we'd like to restore `<-` for mutation. Personally, I don't use a ton of mutations in my code so I have less at stake and if there's anything we can do to appeal to a wider audience, I'm inclined to give it a shot.
- ufo 10y ago
  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 manner though.
  - int_19h 10y ago
    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).
    - latkin 10y ago
      `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.
shados 10y ago
Yeah, I feel the same way about <-, but it's interesting to know that Elm did the same thing, so it isn't a random change.
LeonidasXIV 10y ago
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.
- ngrilly 10y ago
  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.
  - MichaelGG 10y ago
    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.
    - ngrilly 10y ago
      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-whitespace-rule-is-right/#comment-432 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 https://talks.golang.org/2012/splash.article

kcsrk 10y ago

Multicore support is progressing nicely. Only earlier today I made a PR for adding nativecode compilation for multicore: https://github.com/ocamllabs/ocaml-multicore/pull/47 https://github.com/ocamllabs/ocaml-multicore/pull/47. A lot more information about the multicore OCaml project can be found here: https://ocaml.io/w/Multicore https://ocaml.io/w/Multicore

jordwalke 10y ago

I suspect the syntax of `<-` (or lack thereof) will be a common topic of discussion. Let's see how various audiences respond to this change and then discuss if we'd like to restore `<-` for mutation. Personally, I don't use a ton of mutations in my code so I have less at stake and if there's anything we can do to appeal to a wider audience, I'm inclined to give it a shot.

ufo 10y ago
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 manner though.
- int_19h 10y ago
  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).
  - latkin 10y ago
    `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.

shados 10y ago

Yeah, I feel the same way about <-, but it's interesting to know that Elm did the same thing, so it isn't a random change.

LeonidasXIV 10y ago

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.

ngrilly 10y ago
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.
- MichaelGG 10y ago
  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.
  - ngrilly 10y ago
    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-whitespace-rule-is-right/#comment-432 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 https://talks.golang.org/2012/splash.article