<discocaml>
<.korven.> idk man Cabal has been really picking up the slack lately
waleee has quit [Ping timeout: 264 seconds]
<dh`>
typeclasses can't be used for sealing abstractions
<dh`>
at least, not conveniently
<dh`>
(haskell is not that good at modularity in general)
dh` has quit [Changing host]
dh` has joined #ocaml
mbuf has joined #ocaml
<discocaml>
<tornato> Well
<discocaml>
<tornato> Haskell does have a more powerful type system capable of encoding effects as data
<discocaml>
<tornato> Haskell does have a more powerful type system, and effects are encoded as data
<discocaml>
<tornato> Which is neat
<discocaml>
<tornato> Honestly I like Haskell it's just it's always a pain to get things working
<discocaml>
<tornato> And the libraries get abandoned
<discocaml>
<tornato> Enforcing referential transparency in your language does make a lot of things easier to test/mock/parallelism easier
<discocaml>
<tornato> Enforcing referential transparency in your language does make a lot of things easier to test/mock (effects as data, not ref transparency)/and parallelism is easier
Square2 has quit [Ping timeout: 264 seconds]
<dh`>
far as I know it does not make parallelism easier
<dh`>
in theory you can eval every subexpression in parallel, sure, but that doesn't actually work (you spend more time coordinating than evaluating)
<dh`>
in practice you have threads in the IO monad and they're just as nasty as everyone else's threads
<discocaml>
<tornato> If your program sits in IO and not another Monad, you are doing it wrong
<discocaml>
<tornato> (should use MTL or algebraic effects)
<discocaml>
<tornato> Even still though I fail to see how having parallelism over pure functions whose rt is guaranteed (minus unsafePerformIO or other nasty things) is less safe than ocaml which has no training wheels
<discocaml>
<tornato> That wasn't really relevant, but I fail to see how having parallelism over pure functions whose rt is guaranteed (minus unsafePerformIO or other nasty things) is less safe than ocaml which has no training wheels
<discocaml>
<tornato> That wasn't really relevant, but I fail to see how having parallelism over pure functions whose rt is guaranteed (minus unsafePerformIO or other nasty things), and immutable data structures is less safe than ocaml which has no training wheels
<discocaml>
<tornato> I swear every time I have to log something or do very basic side effects having to create a typeclass or functor in Free and the using that as a constraint on a function is really a pain in the ...
Serpent7776 has joined #ocaml
bartholin has joined #ocaml
torretto has quit [Remote host closed the connection]
torretto has joined #ocaml
nasmevka has joined #ocaml
bartholin has quit [Quit: Leaving]
olle has joined #ocaml
<discocaml>
<timv_12727> Does Windows support installing ocaml and opam?
<Leonidas>
yes, but that support is going to be much better starting with opam 2.2
<discocaml>
<yawaramin> also, the OCaml team seem to be discussing introducing another new syntax for binding, like `let/Option x = get_x ()` etc.
<companion_cube>
I wish we had `;*` and `match*` and `try*` etc.
<companion_cube>
that unsugar to `let* x = x in match x with …`
<olle>
match let* ?
<olle>
wait
<olle>
ignore me
hwj has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lobo has joined #ocaml
hwj has joined #ocaml
<discocaml>
<JM> @yawaramin is that to get around the issue with mixing let* from different modules?
<discocaml>
<JM> I'm not sure I'll learn to like that syntax tho 😔
<discocaml>
<yawaramin> that and they think people won't understand the meaning of `let*`/`let+`/`and+`/etc.
<discocaml>
<deepspacejohn> I've often thought that something like let%map looks more readable than let+
waleee has quit [Ping timeout: 264 seconds]
hwj has quit [Ping timeout: 264 seconds]
jabuxas has quit [Ping timeout: 268 seconds]
a51 has joined #ocaml
cr1901_ is now known as cr1901
mbuf has quit [Quit: Leaving]
Serpent7776 has quit [Ping timeout: 272 seconds]
olle has quit [Ping timeout: 272 seconds]
nasmevka has quit [Quit: Leaving]
omegatron has joined #ocaml
Tuplanolla has joined #ocaml
mima has joined #ocaml
jabuxas has joined #ocaml
waleee has joined #ocaml
Square2 has quit [Ping timeout: 264 seconds]
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
jabuxas has quit [Ping timeout: 264 seconds]
bartholin has joined #ocaml
Serpent7776 has joined #ocaml
mal`` has quit [Quit: Leaving]
mal`` has joined #ocaml
torretto_ has joined #ocaml
torretto has quit [Ping timeout: 260 seconds]
<discocaml>
<barconstruction> I was looking into F# type interfaces and I can't even tell how to define an interface for a stack data type.
<discocaml>
<yawaramin> you'd have to use OOP in F# (an OOP interface)
<discocaml>
<barconstruction> An F# person responded to my stack overflow post almost immediately so I'll read their answer and see if it makes sense. It does look like they recommend using a class.
Anarchos has joined #ocaml
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
boozec has joined #ocaml
boozec has quit [Client Quit]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
dnh has joined #ocaml
Square2 has joined #ocaml
bartholin has quit [Quit: Leaving]
<discocaml>
<akhilindurti> I have a bunch of places in my code where I call `expect_varbind`, `expect_unbound`, `expect_tyrecord`, etc.. which basically assert that some sum type has a variant, and returns the data underneath.
<discocaml>
<akhilindurti> Originally, I just used inexhaustive matching like `fun (VarBind(...) -> )`, but this would produce a warning
<discocaml>
<akhilindurti> If I disable this warning, I don't think I get exhaustivity checks for regular `match` though.
<discocaml>
<akhilindurti> Am I taking the right approach here but creating a bunch of `expect_foo` functions?
<discocaml>
<Kali> you can disable match warnings per expression with a `[@warning "-8"]` prepended to the expression
<discocaml>
<Kali> oops, not prepended
<discocaml>
<Kali> the other way
<discocaml>
<Kali> appended
<discocaml>
<akhilindurti> i see. is that what you would recommend in this case?
<discocaml>
<akhilindurti> is there a way to disable match warnings only for fallible bindings/declarations?
<discocaml>
<akhilindurti> when i use `match`, i like having exhaustiveness checking
<discocaml>
<akhilindurti> but if i'm doing `let (Foo(...)) = ...`, i'm doing that for a reason
<discocaml>
<akhilindurti> but if i'm doing `let Foo(...) = ...`, i'm doing that for a reason
<discocaml>
<Kali> you can disable it per declaration by appending `[@@warning "-8"]`
pi3ce has quit [Ping timeout: 255 seconds]
<discocaml>
<Kali> @ = expression
<discocaml>
<Kali> @@ = declaration
<discocaml>
<Kali> @@@ = the rest of the module
<discocaml>
<limp.biskit> yeah, i often do that in ppxes
<discocaml>
<Kali> i would advise against writing partial code in the first place, but that is how you would do it if you wanted to structure your code that way
<discocaml>
<akhilindurti> it's not so much that it's partial, but that the way to handle any other variant except a specific one is to panic
<discocaml>
<akhilindurti> you can't really correct-by-construction your way out of this without something extremely complicated with gadts/functors/etc...
Serpent7776 has quit [Ping timeout: 255 seconds]
<discocaml>
<Kali> i see
<discocaml>
<Kali> well, sometimes exiting makes the most sense
<discocaml>
<akhilindurti> agreed, which is why my `expect_varbind` function is defined as
<discocaml>
<akhilindurti> ```ocaml
<discocaml>
<akhilindurti> let expect_varbind bind =