companion_cube changed the topic of #ocaml to: Discussions about the OCaml programming language | http://www.ocaml.org | OCaml 4.11 release notes: https://caml.inria.fr/pub/distrib/ocaml-4.11/notes/Changes | Try OCaml in your browser: http://try.ocamlpro.com | Public channel logs at http://irclog.whitequark.org/ocaml
ollehar has quit [Ping timeout: 260 seconds]
ollehar has joined #ocaml
<inkbottle> let foo : int -> char = undef
<inkbottle> I want a function with a specific signature, but without implementation
<inkbottle> I could also make use of `type 'a seq = undef`; that would be nice too
<inkbottle> A module, with a signature, but no implementation
spew has quit [Quit: Connection closed for inactivity]
<inkbottle> Functors could be an answer to that, maybe; looking into it
Tuplanolla has quit [Ping timeout: 272 seconds]
<companion_cube> ollehar: just have a debug and a display methods
nicoo has quit [Ping timeout: 240 seconds]
kleisli_ has quit [Ping timeout: 265 seconds]
nicoo has joined #ocaml
jbrown has quit [Ping timeout: 272 seconds]
jbrown has joined #ocaml
ransom has joined #ocaml
kleisli_ has joined #ocaml
mfp has quit [Ping timeout: 258 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
<inkbottle> [ocaml-lsp-server / emacs] `module A = struct let a = 3 (* hello *) end`. ocaml-server shows the type of `a` when on `a`, but it also shows the signature of the full module when on `let`, or anywhere in the comment. The version I use is a few days old.
<d_bot> <hcarty> For functions, you can replace undef with an assert or raise
<d_bot> <hcarty> For a placeholder type you can leave it abstract
<d_bot> <hcarty> A module with a signature but no implementation could possibly be done with the right arrangement of a first class module and raise
<inkbottle> I'm now doing: `module type Undefined = sig ... end` and `module type Defined = functor (Undefined : Undefined) -> sig include Undefined ... end`
<inkbottle> So I can put functions and types that I don't want to implement in `Undefined`, and then they are available in `Defined`
<inkbottle> I keep in mind what you said about leaving the type abstract
<inkbottle> and assert and raise
sagax has quit [Ping timeout: 260 seconds]
worc3131 has quit [Ping timeout: 272 seconds]
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ransom has joined #ocaml
andreas303 has quit [Remote host closed the connection]
andreas303 has joined #ocaml
quizzop[m] has joined #ocaml
kleisli_ has quit [Ping timeout: 244 seconds]
<inkbottle> applicative functors: ocaml is using a notation and operators (map and product) different from the established practice of "pure" and "apply"
<d_bot> <Lupus> is it possible to pattern match (and distinguish) two polyvariant constructors with same name, but with different argument type?
<companion_cube> not in the same type, no
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot> <Lupus> even if the type is computed ad-hoc (as it usually happens with polyvariants)?
talyian[m] has joined #ocaml
<companion_cube> yes, because then you cannot know the type of the argument just from the tag
<companion_cube> `match x with Foo y -> … `
<companion_cube> what is the type of `y` if `x : [> `Foo of int | `Foo of string]`?
<d_bot> <Lupus> makes sense, thanks!
<inkbottle> (btw, I'm already getting the hang of ocaml applicative notation)
ransom has joined #ocaml
kleisli_ has joined #ocaml
narimiran has joined #ocaml
nullcone has joined #ocaml
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ransom has joined #ocaml
ransom has quit [Client Quit]
ggole has joined #ocaml
osa1 has joined #ocaml
mbuf has joined #ocaml
Serpent7776 has joined #ocaml
osa1 has quit [Quit: osa1]
reynir has quit [Ping timeout: 272 seconds]
reynir has joined #ocaml
osa1 has joined #ocaml
borne has joined #ocaml
reynir1 has joined #ocaml
Haudegen has joined #ocaml
reynir has quit [Disconnected by services]
reynir1 is now known as reynir
osa1_ has joined #ocaml
osa1 has quit [Ping timeout: 260 seconds]
ngws has joined #ocaml
<ngws> Hi, does someone know if you can create a (rule ...) in Dune with multiple targets, but where the specified action is run *per target* instead of once for all targets? A bit like % in makefiles.
<ngws> If this is a limitation of Dune, I can certainly work around it in different ways, but I'm curious if there is a "right" Dune way.
<rgrinberg> There's no way. The only workaround is to generate the rules with a dune file written in OCaml syntax.
<ngws> Alright, thanks.
dckc has quit [Ping timeout: 244 seconds]
dckc has joined #ocaml
osa1 has joined #ocaml
osa1_ has quit [Ping timeout: 272 seconds]
Tuplanolla has joined #ocaml
sarna has joined #ocaml
cantstanya has quit [Ping timeout: 240 seconds]
cantstanya has joined #ocaml
olle has joined #ocaml
vicfred_ has joined #ocaml
vicfred has quit [Ping timeout: 272 seconds]
mbuf has quit [Quit: Leaving]
osa1_ has joined #ocaml
osa1 has quit [Ping timeout: 256 seconds]
vicfred_ has quit [Quit: Leaving]
mfp has joined #ocaml
nullcone has quit [Quit: Connection closed for inactivity]
jbrown has quit [Ping timeout: 246 seconds]
jbrown has joined #ocaml
ewanas has joined #ocaml
ewanas has joined #ocaml
ewanas has quit [Changing host]
sagax has joined #ocaml
ewanas has quit [Client Quit]
osa1 has joined #ocaml
osa1_ has quit [Ping timeout: 265 seconds]
Haudegen has quit [Quit: Bin weg.]
mbuf has joined #ocaml
<SoF> what is d_bot bridging to?
<d_bot> <psafont> to the OCaml "server" from Discord
<SoF> not what I expected from an 'old' language like OCaml haha
<d_bot> <Mando> is Ocaml old?
<d_bot> <Mando> I thought it was relatively mediocre in the realm of languages
<Drup> mediore :D
<SoF> maybe not old but academical
<d_bot> <Mando> damn this bot knows some stuff
<d_bot> <Mando> how old is ocaml sof?
<d_bot> <Mando> Nice!
<d_bot> <Mando> Sof do you like to eat mcdonald's? If you do, please don't kill me.
<d_bot> <Mando> 🙂
<olle> How YOUNG is OCaml :)
<d_bot> <Mando> You guys are chatting through discord bots!?
<SoF> what is that supposed to mean, Mando?
waleee-cl has joined #ocaml
<d_bot> <Mando> hello SoF
<SoF> Hi
<d_bot> <psafont> they are all using an IRC channel, that's why they look like cats from this side
<olle> lol
osa1 has quit [Ping timeout: 260 seconds]
<d_bot> <Mando> ohhhhh
<d_bot> <Mando> thanks
osa1 has joined #ocaml
<d_bot> <Mando> sneaky people
<olle> ssssneaky thiefs
<olle> it's oursss, it is, and we wants it
Haudegen has joined #ocaml
inkbottle has quit [Quit: Konversation terminated!]
inkbottle has joined #ocaml
ransom has joined #ocaml
webshinra has quit [Remote host closed the connection]
<d_bot> <ostera> indirectly, that's probably an apt answer to your question too @Mando
<d_bot> <ostera> hey @Drup I think I could use some assistance -- I've got two options in my head for working through something.
<d_bot> <ostera>
<d_bot> <ostera> There's a process A, with type `int Process.t` . `int` here indicates the kind of messages that this process can be sent with a `send` function. Very primitive, but it does the trick so far.
<d_bot> <ostera>
<d_bot> <ostera> ```ocaml
<d_bot> <ostera> let a = Process.spawn ... in
<d_bot> <ostera> send a 1; (* this works fine *)
<d_bot> <ostera> send a false; (* this doesn't type check, bool isn't int, etc *)
<d_bot> <ostera> ```
<d_bot> <ostera>
<d_bot> <ostera> So far so good, now I'd like this process to be able to reply back to me. So I must send it a message that includes _a pointer back to me_. Not a memory pointer, but my Process Identifier (or pid).
<d_bot> <ostera> To get my pid, I concocted an FFI that will do the trick:
<d_bot> <ostera>
<d_bot> <ostera> ```ocaml
<d_bot> <ostera> external self : unit -> 'message Process.t = ""
<d_bot> <ostera> ```
<d_bot> <ostera>
<d_bot> <ostera> Great. Now I can change the type of the process to also include a Pid so that it can send a message back to me.
<d_bot> <ostera> But without fixing the type of message that this process can reply to, I find myself stuck between universal quantification and GADTs to encode the Process.t nicely 😦
<d_bot> <ostera> Eg, extend its type from `int Process.t` to `message Process.t`, where:
<d_bot> <ostera>
<d_bot> <ostera> ```ocaml
<d_bot> <ostera> type message = { pid: 'a. 'a Process.message; int: int }
<d_bot> <ostera> ```
<d_bot> <ostera> Or:
<d_bot> <ostera>
<d_bot> <ostera> ```ocaml
<d_bot> <ostera> type message =
<d_bot> <ostera> | Call: 'a Process.message * int -> message
<d_bot> <ostera> ```
<d_bot> <ostera> Unfortunately the first approach would typecheck for any `pid` value, even if it doesn't support the messages that re being sent to it, _because_ the FFI returns a `'message Process.t` that hasn't been unified until you call it.
<d_bot> <ostera> That sucked. I got something compiling, then it crashed at runtime. Nope.
<d_bot> <ostera> One other approach that I've managed to get working over lunch is to make sure a process function is spawned _with a properly typed self value_, this forces you to reconcile the differences in typed messages.
<d_bot> <ostera> So I came up with a contramap between two processes, that can be used to map from the type being sent to you, to the type you can process.
* d_bot <Drup> makes the very wide and predatory smile of the researcher who is about to drop an entire research field on someone's innocent question
<d_bot> <Drup> So, you want session types with first class processes
borne has quit [Ping timeout: 272 seconds]
<d_bot> <ostera> Do I really need to extend the type system 😦
<d_bot> <Drup> no, not really
<d_bot> <Drup> you can encode
<d_bot> <Drup> but first of ... are you sure you don't want to have typed *channels* to someone, with both messages and answer types ?
<d_bot> <Drup> instead of a given process accepting only one thing
<d_bot> <ostera> that could work too -- at the end of the day I'd have some process type that either encodes the valid message type, or that I can use to get myself a typed channel to communicate with it
<d_bot> <Drup> you should look at session types, see if you like that
<d_bot> <ostera> since I'm compiling to Erlang, i'm looking at the naivest thing first: what if `send` is an immediate channel: you open it, you drop your message, it closes.
<d_bot> <Drup> @dinosaure you have a demo of session types somewhere ?
<d_bot> <dinosaure> so, from what I tested, the best is to use `linocaml` : https://cryptoast.fr/societe-generale-choisit-tezos-experimenter-euro-numerique/
<d_bot> <dinosaure> sorry wrong link ...
<d_bot> <dinosaure> https://github.com/keigoi/linocaml this is the project
<d_bot> <Drup> an interest link nevertheless 😄
<d_bot> <dinosaure> but from what I did, just a mix between a monad and GADT is enough
<d_bot> <ostera> @dinosaure thanks for the link! so far I managed to get something working with just a contravariant functor -- but well, gotta read more about session types to see what I'm missing!
<d_bot> <dinosaure> I mean, `linocaml` is too verbose to describe something such as the SMTP protocol and, with a talk with Keigoi, it seems that even we can implement `choose` (and have an alteration during the process), it's not possible to do the `join`
<d_bot> <dinosaure> so you can describe something which is just ... linear ...
<d_bot> <Drup> hum, I would suggest not trying to do the linear part statically in ocaml
<d_bot> <ostera> well, yes, so far my use case has been "process A wants to send bools to you, but you can only receive ints" -- contramap those messages
olle has left #ocaml [#ocaml]
<d_bot> <Drup> @ostera In any case, instead of a contramap, just use channels with both end typed, that should already be simpler
<d_bot> <ostera> is this the canonical bibliography? 🤔 http://groups.inf.ed.ac.uk/abcd/
mbuf has quit [Quit: Leaving]
<d_bot> <ostera> hmm. i'm not sure I understand what do you mean by "use channels" here. Is it a type artifact to constraint calls to the actual underlying "send" ffi 🤔
<d_bot> <ostera> because i think I currently have "a channel"
raver has quit [Remote host closed the connection]
<d_bot> <Drup> @dinosaure you tried http://www.ct.info.gifu-u.ac.jp/~keigoi/session-ocaml/ ? that seems more interesting
<d_bot> <Drup> @ostera well, a typed channel :3
<d_bot> <dinosaure> it uses `Obj.magic` if I remember and I was mostly aware to implement something which can use in production :/
<d_bot> <Drup> In any case, there is a link to FuSe at the end, which is a good introduction for OCaml people
sarna has quit [Quit: Connection closed]
kleisli_ has quit [Ping timeout: 244 seconds]
cantstanya has quit [Ping timeout: 240 seconds]
<d_bot> <EduardoRFS> why one does work and the other doesn't? As far I know from HM both should fail right?
<d_bot> <EduardoRFS>
<d_bot> <EduardoRFS> ```ocaml
<d_bot> <EduardoRFS> let sum a b = a + (Int.of_float b)
<d_bot> <EduardoRFS>
<d_bot> <EduardoRFS> let works () =
<d_bot> <EduardoRFS> let x = Obj.magic() in
<d_bot> <EduardoRFS> sum x x
<d_bot> <EduardoRFS> let fail a =
<d_bot> <EduardoRFS> let x = a in
<d_bot> <EduardoRFS> sum x x
<d_bot> <EduardoRFS> ```
<companion_cube> it doesn't work because you use Obj.magic
<companion_cube> forget about it and your life will be simpler
<d_bot> <EduardoRFS> i'm developing a type system, Obj.magic is a valid case of that
<d_bot> <EduardoRFS> my point is that one type checks and the other doesn't
cantstanya has joined #ocaml
<companion_cube> you mean a type system that emits OCaml? :/
<d_bot> <EduardoRFS> no a type system in OCaml
<theblatte> x has an unsound type, a typechecker can decide to stop typechecking after that
<companion_cube> embedded in OCaml?
<d_bot> <EduardoRFS> no, another language
<companion_cube> I'm having trouble understanding why you need Obj.magic then; it's really only for low level runtime hacks and if you agree that your code can break at any point
<d_bot> <octachron> `x` has a polymorphic (and unsound type) , `a . 'a`, whereas `a` is monomorphic inside the function body.
<d_bot> <EduardoRFS> I don't need to, I need to know how is OCaml capable of accepting one but not the other
<d_bot> <EduardoRFS> OH get it
<companion_cube> oh ok
<companion_cube> (yuck++)
<d_bot> <EduardoRFS> @octachron do you know if that is supported by the traditional HM implementation?
<d_bot> <ggole> Generalisation only acts on type variables that are introduced within a `let`; the type of `Obj.magic ()` is fresh in the `let` and the type of `a` is not
<d_bot> <EduardoRFS> mostly using Algorithm J tho
<companion_cube> let polymorphism was a mistaaake :D
<d_bot> <EduardoRFS> polymorphic lambda calculus is undecidable, there is no way around it
<Drup> companion_cube: huh, wtf, it really wasn't
<Drup> what the hell are you even talking about :O
<companion_cube> Drup: isn't it that `let x = Obj.magic () in …` generalizes the 'a into `type a. a`?
<d_bot> <ggole> There's a nice efficient approach in terms of levels: http://okmij.org/ftp/ML/generalization.html
<companion_cube> otherwise I don't see why it can check `sum x x`
<Drup> companion_cube: yes, sure, and your conclusion is that the `let` is the issue here ?
<companion_cube> :p
<companion_cube> nah, not really
<d_bot> <EduardoRFS> in this case it would be able to type check, the problem is being consistent, I don't remember now why the polymorphic lambda calculus is undecidable, but it is
<companion_cube> inference is undecidable, not checking, iirc?
<Drup> in system F, both checking and inference are undecidable
<companion_cube> 😱
<companion_cube> wow, ok. I didn't know system F was that powerful.
<d_bot> <EduardoRFS> I'm trying to type check the OCaml bytecode btw
<Drup> I'm not quite sure what that means here
<d_bot> <EduardoRFS> which is essentially a representation of the OCaml bytecode, by having whole program inference there is a couple of cool things possible
<def> checking is decidable no ?!
<d_bot> <EduardoRFS> no
<companion_cube> that's really insane!
<Drup> def: depends on much annotation you admit
<Drup> if you annotate big lambdas and every binders, yes, if you just do term : type, without intermediary annotations, no
<Drup> (iirc)
<companion_cube> wait
<def> ah yes, of course.
<companion_cube> checking is when everything is annotated, isn't it?!
<zozozo> seems reasonable
<def> (that's equivalent to inference :P)
<companion_cube> otherwise there is no difference between inference and checking
<zozozo> companion_cube: well you ahve thez type in one case
<d_bot> <EduardoRFS> on HM there isn't
<companion_cube> zozozo: err that's why it's called checking
<companion_cube> :D
<companion_cube> you *check* the types are correct
<Drup> def: well, no, you can also annotate only (small) lambdas, this is the case of reasonable dependent languages
<companion_cube> sure
<companion_cube> typechecking is never the problem
<companion_cube> or, it should never be the problem
<def> it is the difference between curry and church style presentation.
<def> inference is undecidable, but for a church system f calculs checking is decidable (and easy)
<def> (though for system f-sub, even church checking can be undecidable :()
<companion_cube> CiC is also decidable if you check, but undecidable if you infer, right?
<def> :thumb-up"
<Drup> def: Fsub's a mess :3)
<companion_cube> otherwise there would be not point in writing kernel of trust checkers for Coq, lean, dedukti, etc.
<Drup> the question in general for system F is different
<Drup> it's whether you have or not the big lambdas
<Drup> in ML, you don't have them in the terms, you infer their position
<Drup> in CiC, you always have them in the terms
<companion_cube> checking is still decidable if all binders are annotated
<companion_cube> afaik
<Drup> in system F, guessing where they should be is what is undecidable, even if you have theh type.
<zozozo> well, *if* your system has cut-erasure (I think that's what it's called), you *usually* have type systems whose rules are type-directed, and thus everything is peachy, but if you system is not type-directed (as in, multiple rules can produce a conclusion whose type has the same head constructor), thing become strange
<companion_cube> yeah but who would use such systems? :D
<zozozo> hence the need for annotation in these cases iirc
<Drup> in any case, systemF seems a tad overkill for the bytecode.
osa1_ has joined #ocaml
osa1 has quit [Ping timeout: 265 seconds]
<d_bot> <EduardoRFS> there is any approach where inference is undecidable but it forces you to type the needed cases and this cases are rare?
<zozozo> companion_cube: there are some crazy logic system around, I'm sure, ^^
<d_bot> <EduardoRFS> yeah HM seems to fit well for the model on JSOO
<companion_cube> zozozo: sure, and I'd rather not use them :D
<companion_cube> I mean, I imagine that even cubical TT has decidable *checking*
<zozozo> it's a bit like when in maths you study vector spaces, and you enquire about systems with an infinite (let say countable) number of dimensions and you wonder if anyone would ever use that, until you talk with people who study physics, XD
<d_bot> <Drup> @EduardoRFS plenty. That's what we do in OCaml.
<d_bot> <EduardoRFS> oh good point of OCaml having that
<d_bot> <Drup> (it's a bit harder to design a system that is good at telling you where to annotate ...)
<d_bot> <EduardoRFS> if it get stuck on a loop after x seconds you kill the process and throw a error message
<d_bot> <EduardoRFS> halting problem solved
osa1_ has quit [Ping timeout: 240 seconds]
osa1 has joined #ocaml
<Drup> usually, you do something less stupid than that: in the absence of annotation, you just return something simple, but not as polymorphic as it could be
<Drup> (or you recognize you'll never succed, and fail)
<d_bot> <EduardoRFS> usually, I fear the system actually doing that
<Drup> speaking of which! octachron, maybe we should try to add an hint in case of non-annotated pattern match on a GADT.
dckc has quit [Ping timeout: 240 seconds]
<octachron> zozozo, no need to start interrogating physicists about their path integrals, functional analysis is enough to break a lot of finite dimension vector space intuitions (for instance with respect to dual space)
dckc has joined #ocaml
<zozozo> ^^
<octachron> Drup, keeping track of active annotations seems potentially involved? Or do you mean the result annotation (match ... -> x : a)?
<Drup> well, we do know if we have rigid types in the context.
<d_bot> <ostera> dammit @Drup i'm gonna have to learn PI calculus now
<d_bot> <Drup> you really don't x)
<d_bot> <Drup> I mean, it is fun
<d_bot> <Drup> I'm not sure it's veru useful
<d_bot> <ostera> yeah mostly because of that
<d_bot> <ostera> anyway, I managed to get something that _looks type safe_
<d_bot> <ostera> and the compiled erlang code runs as expected 👌
dckc has quit [Ping timeout: 260 seconds]
<d_bot> <EduardoRFS> OH so that's what you're doing
<d_bot> <EduardoRFS> I saw your tweets
<d_bot> <EduardoRFS> not sure who did it, but amazing work at integrating IRC and Discord
<d_bot> <ostera> (* contramap this process to map ints to booleans *)
<d_bot> <ostera> @Drup we'll see how this plays out in larger process chains tho, and with supervision trees D:
<companion_cube> I mean, typechecking even individual actors would be fun already
dckc has joined #ocaml
<d_bot> <rgrinberg> @ostera how do you compile refs/mutability to erlang?
<d_bot> <ostera> i intend not to support them, and trim down ocaml a bunch
<d_bot> <rgrinberg> Hmm, but that will make it impossible to port existing code.
<d_bot> <ostera> maybe not a bunch, but at least where it doesn't map nicely
<d_bot> <ostera> yeah, that's not the idea
<d_bot> <ostera> i could support them with a global ets table tho
<d_bot> <rgrinberg> I think that's a lot better. It would suck not being able to use things like menhir
<d_bot> <ostera> that's true
<d_bot> <ostera> i'll keep it in mind 🙂 but it does have some drawbacks
<d_bot> <rgrinberg> You could also consider porting things that require mutability to nifs perhaps? So you would still run them with the OCaml runtime, but have seamless interop with the rest
<d_bot> <rgrinberg> (if that's possible)
<d_bot> <ostera> e.g, if someone gets their hands on the ets table, they could drop it
spew has joined #ocaml
<d_bot> <ostera> hadn't thought of that, sounds useful -- what did cross my mind was to be able to reuse the native backend to write nifs
<d_bot> <ostera> then you could write beam code and nifs in the ~same language
<d_bot> <ostera> share types and whatnot
<d_bot> <ostera> @rgrinberg good points tho, will keep them in mind going forward 🙌
<d_bot> <ostera> now trying to type gen_servers 😛
<d_bot> <rgrinberg> You got an interesting project going, would be happy to try it out. I'm a user that is always trying to bring his OCaml toolkit to whatever new platform, so being able to reuse existing code is quite important.
<d_bot> <ostera> thanks, I'll let you know when its somewhat usable 🙂
zebrag has joined #ocaml
inkbottle has quit [Ping timeout: 260 seconds]
osa1 has quit [Quit: osa1]
osa1 has joined #ocaml
borne has joined #ocaml
waleee-cl has quit [Quit: Connection closed for inactivity]
osa1 has quit [Client Quit]
raver has joined #ocaml
_ks has quit [Remote host closed the connection]
_ks has joined #ocaml
osa1 has joined #ocaml
osa1 has quit [Quit: osa1]
osa1 has joined #ocaml
<SoF> is anyone here using windows and maybe knows how to set up VS Code Remote to use WSL OCaml things?
<SoF> or has a better suggestion on how to program on windows? (no emacs/vim pls)
<d_bot> <arctumn> > is anyone here using windows and maybe knows how to set up VS Code Remote to use WSL OCaml things?
<d_bot> <arctumn> @SoF#0000 yes i do i can help you i use a vscode with wsl and ocaml setup
<d_bot> <arctumn> sof
ollehar has quit [Remote host closed the connection]
ransom has quit [Quit: Textual IRC Client: www.textualapp.com]
<SoF> arctumn that looks great! how?
<d_bot> <arctumn> do you have ocaml already in wsl?
<d_bot> <Skilly> hi, that's me
<d_bot> <Skilly> I do yes
<d_bot> <Skilly> > do you have ocaml already in wsl?
<d_bot> <Skilly> @arctumn
nullcone has joined #ocaml
bartholin has quit [Quit: Leaving]
reynir has quit [Ping timeout: 272 seconds]
reynir has joined #ocaml
Yagotzirck has joined #ocaml
Yagotzirck has quit [Client Quit]
waleee-cl has joined #ocaml
<d_bot> <Lupus> is it possible to unpack such module later? ```ocaml
<d_bot> <Lupus> type handlers('a) = (module Handlers with type service = 'a)
<d_bot> <Lupus> ```
<d_bot> <Lupus> I get the following error when trying to do it:
<d_bot> <Lupus> ```
<d_bot> <Lupus> Error: The type of this packed module contains variables:
<d_bot> <Lupus> (module Handlers with type service = 'a)
<d_bot> <Lupus> ```
<d_bot> <octachron> You need a locally abstract type : `let f (type a) (x: handlers(a)) = ... `
<d_bot> <Lupus> oh, lemme try that!
<d_bot> <Lupus> looks like it did the trick, thanks @octachron !
<d_bot> <Lupus> last time I gralced through the documentation on that, I didn't spot `It is also extremely useful for first-class modules` 😄
TC01_ has quit [Ping timeout: 260 seconds]
TC01 has joined #ocaml
<d_bot> <hcarty> @Skilly I haven't used Windows + VS Code + WSL but I have used Windows + fdopen's opam fork + VS Code to work on native Windows builds. It has worked well for me
<SoF> hcarty: I wasn't able to set up the cygwin stuff (some old install still lying around messing things up), but with arctumn's help I got it working well on WSL :)
<d_bot> <hcarty> Wonderful! Happy to hear it
Jesin has quit [Quit: Leaving]
ggole has quit [Quit: Leaving]
narimiran has quit [Ping timeout: 260 seconds]
osa1 has quit [Ping timeout: 272 seconds]
<d_bot> <Et7f3> @Bluddy now in server setting we have a tab called community only admin can hit.
<d_bot> <Et7f3> I think it is required to make #announcements real annoucement where we can subscribe
Jesin has joined #ocaml
Serpent7776 has quit [Quit: leaving]
borne has quit [Ping timeout: 240 seconds]
borne has joined #ocaml
Tuplanolla has quit [Quit: Leaving.]
borne has quit [Ping timeout: 244 seconds]
nullcone has quit [Quit: Connection closed for inactivity]
borne has joined #ocaml
ransom has joined #ocaml