10:37 <jco> Hello! While writing interfaces to expose functions from a module in a library, i get a warning: unused value

10:38 <jco> but since it's a library it's not a problem to not use values

10:38 <jco> is there something i missed?

10:49 <malc_> jco: if the symbol is not explicitly exported you'll get (well deserved) warnin

10:49 <malc_> g

10:52 <jco> malc_: thanks, how a value gets explicitely exported?

10:53 <malc_> jco: "val name : type"

10:54 <jco> oh yeah, i did it, i did though

10:55 <malc_> eh?

10:56 <jco> yeah this function was exported

10:58 <malc_> jco: then i'm afraid the information you've provided is incomplete for me to be of any help

10:58 <jco> the error is: https://privatebin.net/?09b5956ced35bbf3#8sDfKFTxNLLAE6qEbPpFgh7t8aW8DunMKiZNC8JUv1x2

11:00 <malc_> JavaScript is required for PrivateBin to work. Sorry for the inconvenience.

11:00 <jco> ok, which service do you prefer most?

11:01 <malc_> jco: in my experience tpaste.us is good

11:02 <jco> https://tpaste.us/onRn

11:02 <jco> here it is

11:03 <malc_> thanks, looking

11:03 <jco> yw :)

11:04 <theblatte> jco: do you have a second val update_milestone further down?

11:04 <malc_> i'm really confused

11:04 <malc_> (not a heavy .mli user though)

11:04 <theblatte> this would cause a warning 32 (which is a really poor choice ^^)

11:05 <theblatte> (I mean the error message could say that you have multiple declarations instead of "this one is unused")

11:05 <jco> malc_: right on!

11:05 <jco> that's so bad, one is meant to be exposed while the other is not

11:05 <jco> thanks ^^

11:13 <jco> malc_: may i ask why don't you use javascript? for security reasons?

11:15 <malc_> jco: no, i just got used to not having it available on my ppc mac mini.. and sorta got used to not having it, and being a special a unique snowflake, besides having a machine connected to the power outlet with a wattmetter on the way to the power source taught me that those nifty new things (js and such) are sucking the life out of the mother earth

11:15 <malc_> ie no good reason

11:43 <jco> malc_: i see :)

13:11 <jco> a general question concerning apis: is it okay to have functions with 5 to 7 arguments?

13:11 <jco> or does this mean that the api needs to be restructured?

13:12 <jco> using records to group information

13:30 <octachron> It is probably a good idea to try to see if some of the 7 arguments can be logically grouped together.

13:32 <octachron> But if all the arguments are orthogonal, having 7 arguments is not unheard of.

13:34 <jco> thanks, as a concrete example if we have two hashtables, and a function which operates on these hashtables, would it make sense to group them in a record?

13:35 <jco> it looks a bit strange to me to pass a function which operates on these structures as an argument

13:35 <jco> but i may be overthinking it a bit

13:36 <d_bot> <colin> a tuple is always a sensible choice if your function wouldn't benefit from currying much anyway

13:37 <jco> yeah

13:59 <companion_cube> or named arguments

16:05 <ollehar> companion_cube: about "functional core, imperative shell" architecture

16:05 <ollehar> 23:52 < companion_cube> not caring about what

16:07 <companion_cube> hum

16:08 <companion_cube> what makes you think that?

16:08 <ollehar> companion_cube: google shows nothing.

16:08 <ollehar> thus: booo

16:09 <companion_cube> maybe it's just not something that people write?

20:31 <ollehar> hm

20:32 <ollehar> no side-effect discipline

20:41 <ollehar> maybe i'll post on /r/ocaml and see what people thinkg

20:42 <ollehar> -g