4 ms·

> I've said this before and I'll say it again, modular implicits would be a game changer for OCaml. That would be the second time we disagree about that on HN

by brmgb 6y ago

> I've said this before and I'll say it again, modular implicits would be a game changer for OCaml. That would be the second time we disagree about that on HN but I still fail to see how modular implicits are supposed to be game changing for OCaml. The situation was different before 2011. Now, first-class modules and local open have made modules really easy to use. Modular implicits would mostly be sugar most of the time.

smabie 6y ago
You're right that both of those things help OCaml out a lot. But just look at all the powerful stuff people do with Scala and implicits. All of that could be done with OCaml: typeclasses, parameterized behavior, configurable functionality, testing. All of that stuff can be done explicitly right now, but I really do think there's something powerful about changing an include/import and having all your code change behavior. For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes. You gotta admit there's something just really awesome about that.
- brmgb 6y ago
  > For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes. But you can already do that with parametrized modules. Just change the module you pass as a parameter and the behaviour cjanges. It is not more cumbersome than changing an include and it is much more clear (dare I say explicit) in its intent.
  - smabie 6y ago
    But what if you're doing a bunch of category theory stuff? Passing in the right monoid or whatever to every function is such a drag. Alternatively using local open is also a drag. Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful. Not sure how it came to be that everyone totally ignores it.
    - brmgb 6y ago
      But why would you be doing a bunch of category theory stuff while writing softwares ? Local open with let+ and let* make writing monadic and applicative code very easy when needed. Anything more abstract than that is over complex abstraction. OCaml is not Haskell. Trying to write Haskell code in OCaml is always going to result in something highly unidiomatic. > Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful. I have written a fair bit of OCaml and never actually encountered these problems. In practice, module prefixing and local open are just fine. You rarely use more than one module per function anyway. I agree that the object system is nice but structural typing is rarely what you want and it leads to convoluted error messages.

by brmgb 6y ago

smabie 6y ago

You're right that both of those things help OCaml out a lot. But just look at all the powerful stuff people do with Scala and implicits. All of that could be done with OCaml: typeclasses, parameterized behavior, configurable functionality, testing. All of that stuff can be done explicitly right now, but I really do think there's something powerful about changing an include/import and having all your code change behavior. For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes. You gotta admit there's something just really awesome about that.

brmgb 6y ago
> For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes. But you can already do that with parametrized modules. Just change the module you pass as a parameter and the behaviour cjanges. It is not more cumbersome than changing an include and it is much more clear (dare I say explicit) in its intent.
- smabie 6y ago
  But what if you're doing a bunch of category theory stuff? Passing in the right monoid or whatever to every function is such a drag. Alternatively using local open is also a drag. Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful. Not sure how it came to be that everyone totally ignores it.
  - brmgb 6y ago
    But why would you be doing a bunch of category theory stuff while writing softwares ? Local open with let+ and let* make writing monadic and applicative code very easy when needed. Anything more abstract than that is over complex abstraction. OCaml is not Haskell. Trying to write Haskell code in OCaml is always going to result in something highly unidiomatic. > Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful. I have written a fair bit of OCaml and never actually encountered these problems. In practice, module prefixing and local open are just fine. You rarely use more than one module per function anyway. I agree that the object system is nice but structural typing is rarely what you want and it leads to convoluted error messages.