00:37 <discocaml> <ilo Kali> :ocaml:

03:49 <discocaml> <MasterBuilder> is there any way to express to the compiler that a match arm is unreachable? specifically when a list will never be empty

03:49 <discocaml> <MasterBuilder> so handling `[]` is unnecessary

03:53 <discocaml> <MasterBuilder> can always throw an unthrowable exception I guess which has the benefit that if those invariants are violated after all it will be visible, but it's still a bit of an eyesore, in this case there is absolutely no doubt, what I want is a "list of length >= 1" type but I don't really want to go creating one of those

04:19 <discocaml> <hopefullyhat> What is the reason for the list never being empty?

04:30 <discocaml> <MasterBuilder> the reason is a little complicated, I'm open to the notion of it being poorly designed, anyway I have a list of events that I loop over but before the iteration can start I first need to wait for one event to arrive, which must be handled immediately and then it is saved because the information is still needed even though it won't be handled again, so I wait for one event, then I start the iteration by calling a recursive function with a

04:33 <discocaml> <hopefullyhat> If the list is indeed non-empty, you might want to use a non-empty list type

04:33 <discocaml> <MasterBuilder> and even if I were to set a flag to indicate it's been handled to avoid it being handled again in the recursive call (if no other events are available), it's still dumb because the invariant is quickly established after that, so it's just noise

04:34 <discocaml> <MasterBuilder> is there an easy way to do it and using entirely the same list API?

04:34 <discocaml> <hopefullyhat> Don’t think so 😦

04:34 <discocaml> <MasterBuilder> yeah that does bother me a little

04:34 <discocaml> <hopefullyhat> Unless you want to write your own type or use an existing library, the neatest is just failwith “Impossible” in the branch

04:35 <discocaml> <MasterBuilder> yeah that's what I have now

04:36 <discocaml> <MasterBuilder> I'll think about using a better type, I did find a library that offers such a type but it didn't look very good

04:36 <discocaml> <MasterBuilder> and stackoverflow suggested some complicated GADT that I don't really understand so much

04:37 <discocaml> <MasterBuilder> well, thanks

04:50 <discocaml> <ilo Kali> Maybe a silly idea, but perhaps you could use a text editor to copy the List module's signature and edit all occurrences of `'typevar list` to `('typevar,'phantom) list` (or whatever you want to use to store the relevant type information), then paste it back and restrict the List module (or a copy) to it

05:09 <discocaml> <leviroth> There is core_kernel.nonempty_list, but maybe that’s the library you had already seen. I’ve used it; I find it really convenient sometimes, but other times missing a function or being unable to prove something necessary to the compiler can be annoying.

05:10 <discocaml> <MasterBuilder> Hmm no haven't seen that, I don't think, honestly didn't look very hard, is that part of Base?

05:13 <discocaml> <MasterBuilder> To be honest I don't need the full power of List for this one, kinda depends on a few things that are a bit unclear at the moment, possibly don't need anything at all, so maybe whipping up a custom type wouldn't be terrible, I'm a bit skeptical of pulling in a massive library just for that

05:13 <discocaml> <MasterBuilder> is that the only nonempty list you're aware of?

08:42 <discocaml> <psychokitty> I don't suppose there's a cooperative way to build OCaml objects from C that uses exported information about the decided object layout for types?

08:43 <discocaml> <psychokitty> I know there's specific functions for common things, `caml_alloc_some`, etc. but I see that a lot of bindings basically have to know the object layout of the things they wish to construct, and sort of hardcode the construction themselves (the LLVM bindings, for example; https://github.com/llvm/llvm-project/blob/main/llvm/bindings/ocaml/llvm/llvm_ocaml.c#L1578-L1597).

09:21 <discocaml> <emillon> That's how the majority of bindings are written, yes

09:22 <discocaml> <emillon> You can have a look at the ctypes library which uses a different approach (with no C but a Ocaml api to manipulate C values)

09:34 <Anarchos> how to get the ocaml/ocaml 4.14 branch from github on my own github repo ?

11:01 <Anarchos> why do the compiler recompiles checkstack.c each time a launch make world ?

14:31 <discocaml> <leviroth> @MasterBuilder it's not a part of base, but it depends on base, so if you're trying to keep dependencies really light it might not work for you.

14:31 <discocaml> <leviroth> You could also potentially just copy the type definition from that library; you may or may not need any of the helper functions it contains.

14:33 <discocaml> <leviroth> Actually it depends on core, lol

14:38 <discocaml> <MasterBuilder> yeah that could work

14:41 <discocaml> <MasterBuilder> but if core is only an indirect dependency that's not necessarily so bad, I'm already using stuff from Containers which is why I'm hesitant to directly pull in another library extension, that sounds like a big mess

14:58 <discocaml> <leviroth> You’d take the extra dependency for binary size etc, but you should be able to use it without having to open Core or anything like that.

15:05 <discocaml> <MasterBuilder> you know it was actually much easier to create this type than I thought

15:06 <discocaml> <MasterBuilder> just

15:06 <discocaml> <MasterBuilder>

15:06 <discocaml> <MasterBuilder> ```ocaml

15:06 <discocaml> <MasterBuilder> module NonEmptyList = struct

15:06 <discocaml> <MasterBuilder> type 'a t = ( :: ) of 'a * 'a list

15:06 <discocaml> <MasterBuilder> end

15:06 <discocaml> <MasterBuilder> ```

15:06 <discocaml> <MasterBuilder>

15:06 <discocaml> <MasterBuilder> then I locally open this module and didn't even need to change the code at all, so for pure lists this works great, as long as I don't use any List functions this is adequate

15:06 <discocaml> <MasterBuilder> maybe I'll look into using the `non_empty_list` module if I need more power

15:07 <discocaml> <MasterBuilder> but this is fine for now

15:15 <discocaml> <NULL> You can also replicate all List functions you may want to use in a `List` submodule, so that it still works cleanly

15:16 <discocaml> <MasterBuilder> oh that's a good point

18:23 <discocaml> <froyo> `type 'a nonempty = 'a * 'a list`

18:23 <discocaml> <froyo> `let cons x (y, ys) = x, y :: ys`

18:23 <discocaml> <froyo> `let hd (h, _) = h`

18:23 <discocaml> <froyo> `let tl (_, t) = t`

18:24 <discocaml> <froyo> `let to_list (h, t) = h :: t`

18:26 <discocaml> <froyo> etc etc

18:30 <discocaml> <NULL> `type 'a non_empty_list = (::) of 'a * 'a list` is better because you will be able to write `[0; 1]` and it will be a valid non-empty list

18:32 <discocaml> <NULL> Also, you can have `let to_list : 'a non_empty_list -> 'a list = Obj.magic`

18:41 <discocaml> <octachron> Using `Obj.magic` to avoid a single allocation in `let to_list (x::y) : _ list = x :: y ` is overkill.

18:42 <discocaml> <MasterBuilder> I want to be able to pattern match the head and tail as if it were a normal list, that's the whole point

18:46 <discocaml> <geoff> If the first item is guaranteed and you don't want to have the impossible branch, why not unroll one step and get/process the first element before entering the function that matches on a list

18:47 <discocaml> <NULL> The first part is definitely the most reasonable argument

19:05 <discocaml> <geoff> wait I read the above stuff wrong ignore me 😅

19:08 <discocaml> <geoff> I feel like redesigning to not have to pass in a dummy list with one element that you don't want to actually reprocess is the answer, but I could be reading the description of the problem wrong. I'd say it's unlikely a new type is required though

19:19 <discocaml> <MasterBuilder> I do still need it but just as static info, but you're totally right it was the entirely wrong abstraction, I just made it another parameter instead of having it as the head of the list, actually, it used to be an `option` parameter because the way the code was written necessitated that at the time (wasn't unrolled as you say), but I hated that because that can also never be `None` so it's the wrong type, so I just decided to put it at

21:16 <discocaml> <geoff> Another parameter, or having the list function be local and closing over it is what I had in mind yea. That's what I've done in similar situations

23:57 <discocaml> <MasterBuilder> oh yeah I actually could do that too by shuffling some code around, the function already is local

23:58 <discocaml> <MasterBuilder> Hmm but actually since it's changing it would have to be a reference and that just makes it ugly