03:33 <companion_cube> I wish we could have some sort of unitialized arrays…

03:33 <companion_cube> once more

03:56 <greenbagels> companion_cube: for speed or?

03:57 <greenbagels> also, https://ocaml.org/docs/metaprogramming and https://github.com/ocaml-ppx/ppx_deriving mention how to combine derivers

03:57 <greenbagels> like [@@deriving show,eq]

03:58 <greenbagels> but with say ppx_deriving_yojson, how would i combine something like @default and @key?

04:02 <greenbagels> oh i guess [@default X] [@key Y]

05:33 <greenbagels> if you have a data type that could have a "null" value but also just be plain ol' optional (i.e. not labeled "Required" in a JSON Schema), what would be the more common solution? To make a trinary variant type (like Missing, Null, or Some 'a) or to compose the `option` type with a variant type? (like Missing, or `a option)

05:35 <greenbagels> honestly json is such a pain...

05:36 <discocaml> <geoff> `option option`?

05:36 <greenbagels> i dont know why i thought that wouldn't work...

05:37 <greenbagels> now im imagining some cursed ocaml codebase out there that has Some Some Some Some Some None...

12:03 <discocaml> <smondet> (Coq extracted to OCaml without optimizations looks like that actually': `(S (S (S (S Z)))` 🙂 )

13:45 <discocaml> <deepspacejohn> I guess it also depends on if Null or Missing have a different meaning. If they don't, then I'd just keep it simply by always including the fields and setting them to `null`. If you're decoding JSON to OCaml, then you can just decode both missing or null fields as `None`.

13:48 <discocaml> <deepspacejohn> if you do need to preserve the distinction between null and missing, then I'd do a trinary type or a type like `type 'a optional = Missing | Set of 'a` because seeing `Some None` makes me unhappy.

15:59 <dh`> there's nothing wrong with Some None if it's clear what it's supposed to mean

16:00 <dh`> e.g. lookup in a foo option Map.t

16:25 <discocaml> <xavierm02_> Is there some way of having `dune test` check that something does not typecheck (or more precisely that `let f (x : t1) : t2 = x` does not typecheck, i.e. that two types `t1` and `t2` are not convertible)?

16:26 <discocaml> <xavierm02_> some *simple* way

16:36 <discocaml> <deepspacejohn> So you want a test that tries to compile that code, and the test passes if the compiler finds a type error? (I'm not sure how you'd do that, but I'm just making sure I'm understanding the problem.)

16:38 <discocaml> <xavierm02_> @deepspacejohn Yes. I want to have an explicit check that a type is abstract-enough

16:41 <discocaml> <xavierm02_> And I can't just try getting a weird error with `Obj.magic` and catching it because the two types will be equal, but that equality should be hidden

16:45 <discocaml> <deepspacejohn> Types are usually either just abstract or they aren't, so that seems like an odd thing to test. But if you're using `Obj.magic`, then you're breaking the type system anyway. Either way, I don't have a good solution. Hopefully someone else can help.

16:46 <dh`> a test framework that has no way to express tests that are expected to fail seems fundamentally flawed to me

16:48 <discocaml> <deepspacejohn> Dune runs tests after compiling the code. So if your code doesn’t compile, then it can’t run the tests. Maybe you could call the compiler from a cram test, or something like that though.

16:50 <discocaml> <xavierm02_> I'm not using `Obj.magic`. I was just saying that "have different representations" might be expressible using `Obj`, but that even if it were, this would not be relevant to my use case

17:05 <discocaml> <functionalprogramming> why would you need to explicitly write a test for this

17:05 <discocaml> <xavierm02_> Hm. I can see this working with cram tests, e.g. writing the tests in comments and uncommenting them in seperate files, but that's too much work for the little gain for now ^.^

17:07 <discocaml> <octachron> You could check the output of a REPL session.

17:08 <discocaml> <xavierm02_> @micah : For the same reason as other trivial tests : if the invariant I have in mind when writing the code is eventually broken, I want the compiler to warn whoever broke it that I did not expect this

17:08 <discocaml> <octachron> (both the compiler and the reference manual use more specialized tools but you would need to vendor them)

17:09 <discocaml> <xavierm02_> @micah : For the same reason as other trivial tests : if the invariant I have in mind when writing the code is eventually broken, I want the build system to warn whoever broke it that I did not expect this

17:11 <discocaml> <xavierm02_> @octachron What would be the advantage of using a REPL instead of trying to compile the file?

17:38 <discocaml> <octachron> You can have more than one error in the test by using `ocaml <test.ml`

17:39 <discocaml> <octachron> (and mix the test with non-typechecking tests)

17:42 <discocaml> <xavierm02_> Ah right