xd1le has quit [Remote host closed the connection]
xd1le has joined #ocaml
jabuxas has joined #ocaml
jabuxas has quit [Ping timeout: 256 seconds]
xd1le has quit [Quit: xd1le]
waleee has quit [Ping timeout: 255 seconds]
motherfsck has quit [Ping timeout: 255 seconds]
motherfsck has joined #ocaml
Square2 has joined #ocaml
Serpent7776 has joined #ocaml
bartholin has joined #ocaml
bibi_ has quit [Quit: Konversation terminated!]
torretto has quit [Ping timeout: 260 seconds]
torretto has joined #ocaml
olle has joined #ocaml
bartholin has quit [Quit: Leaving]
steenuil has quit [Remote host closed the connection]
steenuil has joined #ocaml
dnh has joined #ocaml
dnh has quit [Ping timeout: 255 seconds]
infinity0 has joined #ocaml
dnh has joined #ocaml
jabuxas has joined #ocaml
a51 has joined #ocaml
<reynir>
There is no way to say "this module has this signature except member foo is actually called bar", right?
<reynir>
For example, given a functor `module F(T : sig val foo : unit -> int end) = struct let foooo () = T.foo () + T.foo () end` and a module `module M = struct bar () = 42 end` you can't write `module M' = F(M with val foo = bar)` or so?
<discocaml>
<dinosaure> you can do `F(struct include M let foo = bar end)`
<discocaml>
<dinosaure> so it's not an exclusion but you add what is required for `F`
<discocaml>
<_ggole> Yeah, some variant of `include` trick seems necessary
omegatron has joined #ocaml
<reynir>
yes so basically you have to define a new module
a51 has quit [Quit: WeeChat 4.2.1]
a51 has joined #ocaml
justache is now known as fotastache
jabuxas has quit [Ping timeout: 272 seconds]
Square2 has quit [Ping timeout: 255 seconds]
olle has quit [Ping timeout: 255 seconds]
Serpent7776 has quit [Ping timeout: 255 seconds]
<discocaml>
<cavemon.dev> what does `!` mean in `type !'a t`?
<discocaml>
<smondet> It's an injectivity annotation
<discocaml>
<Kali> `typevar.` indicates an explicit universal quantification on that type variable
<discocaml>
<Kali> (or type variables, you can have multiple: `'a 'b.`)
<discocaml>
<Kali> this is usually hidden in type signatures since it's just implied, but sometimes you need to explicitly write it to make sure you get the right type, like when putting a polymorphic function in a record
<discocaml>
<Kali> ```ocaml
<discocaml>
<Kali> type example = {
<discocaml>
<Kali> f : 'a -> 'a (* wrong: 'a is unqualified *)
<discocaml>
<cavemon.dev> does qualified here mean something like "the return type here is the same as arg type"?
<discocaml>
<Kali> unqualified is sort of like, this type variable is unbound, it just appeared out of nowhere
<discocaml>
<Kali> you can't introduce a type variable without it first being bound
<discocaml>
<Kali> like in 'a option, it's bound here:
<discocaml>
<Kali> ```ocaml
<discocaml>
<Kali> (* bound here *)
<discocaml>
<Kali> type 'a option =
<discocaml>
<Kali> | Some of 'a
<discocaml>
<Kali> | None
<discocaml>
<Kali> ```
<discocaml>
<Kali> you can't do ```ocaml
<discocaml>
<Kali> type option =
<discocaml>
<Kali> | Some of 'a
<discocaml>
<Kali> | None
<discocaml>
<Kali> ```
<discocaml>
<Kali> because 'a must be introduced before it is used
<discocaml>
<Kali> in a normal type signature, these bindings are hidden to reduce noise
<discocaml>
<Kali> for example `(fun x->x) : 'a -> 'a` is really `... : 'a. 'a -> 'a`
<discocaml>
<cavemon.dev> are these two equivalent?
<discocaml>
<cavemon.dev>
<discocaml>
<cavemon.dev> ```ocaml
<discocaml>
<cavemon.dev> type example = { f: 'a. 'a -> 'a }
<discocaml>
<cavemon.dev>
<discocaml>
<cavemon.dev> type 'a example = { f: 'a -> 'a }
<discocaml>
<cavemon.dev> ```
<discocaml>
<Kali> no
<dh`>
no
<dh`>
the first gives you a type "example" with a field f that is a function that takes any type and returns the same type
<discocaml>
<._null._> Beware of large-ish code blocks, mind the bridge with IRC
<discocaml>
<Kali> the first example is a record containing a function from any type to any type
<dh`>
the second gives you a type "'t example" with a field f that takes a 't and returns a 't
<dh`>
that is, the first takes any type (but that isn't very useful) and the second makes the type into a parameter of the example type
<discocaml>
<Kali> the second example is a type parameterized by a type, that produces a record type containing a function from that type to that type
<discocaml>
<Kali> for example `int example` is the type `{ f : int -> int }`
<discocaml>
<cavemon.dev> i see what you mean
<discocaml>
<Kali> but the first `example` function has to be applicable to all types
<discocaml>
<Kali> `{ f = fun x -> x }` is ok, but `{ f = fun x -> x + 1 }` is not
<discocaml>
<cavemon.dev> because + is int
<discocaml>
<Kali> because it has type `int -> int`, which is less general than `'a -> 'a`
<discocaml>
<cavemon.dev> makes sense
<discocaml>
<cavemon.dev> finally what is `type a` in `fun ...`
<discocaml>
<cavemon.dev> `fun (type a) (ty : a t) : a option t ->`
<discocaml>
<._null._> A locally abstract type, so one which doesn't get unified with any other (except when GADTs are involved)
<discocaml>
<leviroth> I disagree. For example the compiler is perfectly happy to let you write `((fun x -> x + 1) : 'a -> 'a)` even though it will not let you add a universal quantifier to the type.
<discocaml>
<cavemon.dev> locally abstract meaning opaque? or can be any type like int
<discocaml>
<._null._> It's locally abstract, just like regular arguments are locally abstract: you don't know what they are inside the value, you have to deal with all possibilities
<discocaml>
<._null._> It's locally abstract, just like regular arguments are locally abstract: you don't know what they are inside the function, you have to deal with all possibilities
<discocaml>
<cavemon.dev> so these are not the same correct?
<discocaml>
<cavemon.dev> ```ocaml
<discocaml>
<cavemon.dev> let filter = fun (type a) (data: a list) -> data
<discocaml>
<cavemon.dev> let filter: 'a. 'a -> 'a = fun data -> data
<discocaml>
<cavemon.dev> ```
<discocaml>
<._null._> No, the first one is `let filter : 'a. 'a list -> 'a list = fun data -> data`
<discocaml>
<cavemon.dev> so these are not the same correct?
<discocaml>
<cavemon.dev> ```ocaml
<discocaml>
<cavemon.dev> let filter = fun (type a) (data: a list) -> data
<discocaml>
<cavemon.dev> let filter: 'a. 'a list -> 'a list = fun data -> data
<discocaml>
<cavemon.dev> ```
<discocaml>
<cavemon.dev> sorry i forgot to put `list` on second example
<discocaml>
<._null._> Then yes, they will be the same
<discocaml>
<cavemon.dev> are they only same because its an identity function?
<discocaml>
<._null._> Locally abstract types are useful because they won't try to unify with any other type, and they're sometimes required (GADTs, FCMs) but apart from that they don't extend expressivity
<discocaml>
<._null._> "they won't try" : when you have type errors they will be more readable
jabuxas has joined #ocaml
gentauro has quit [Read error: Connection reset by peer]
gentauro has joined #ocaml
<discocaml>
<rongcuid> I'm trying to compile a fairly dated project (`cil-template`) which uses cmake, and I am getting errors about `UsdOCaml.cmake` cannot find a source file, likely because it's not searching for the ocaml file extension. Does anyone have an idea about how to deal with this?
<dh`>
burn down the cmake
<dh`>
(if you are building this because you're taking it up, burn down the cmake right away, you'll thank yourself later. if you're just trying to compile it, that's a harder question)
<discocaml>
<rongcuid> Well, it's a tutorial repository...
jabuxas has quit [Read error: Connection reset by peer]
<discocaml>
<rongcuid> Last time I touched ocaml dune wasn't a thing yet. I'm not sure how hard it will be to convert
jabuxas has joined #ocaml
<discocaml>
<cavemon.dev> is there a contrived example to illustrate locally abstract vs. polymorphic? trying to wrap my head around it
<dh`>
doesn't have to be dune, virtually anything is preferable to cmake, especially for ocaml where there's no standard support for it
<discocaml>
<rongcuid> I need to understand how the project compiles first
<dh`>
anyway if you can't burn it out next best guess is to search for a newer version of the ocaml-in-cmake infrastructure they're using
<dh`>
since cmake is a fairly moving target
<discocaml>
<rongcuid> It has this 1260 line cmake module
<dh`>
I recommend against trying to understand cmake unless you have a lot of sanity points to spare
<dh`>
especially that kind of cmake
<discocaml>
<rongcuid> I'm trying to understand what this does `OCAMLOPTS -pp "camlp4o pa_macro.cmo ${PPARGS}"`
<dh`>
it runs the camlp4 preprocessor (which is old and dead)
<dh`>
or arranges to run it or something, depending on exactly what it is and what's around it
<discocaml>
<rongcuid> This is basically the thing: