<discocaml_>
<polybeanalt> Hey yall, so im fairly new to ocaml, but I would like to build something with it. I guess I was wondering at what point I should stop reading a book about the language and dive into building something?
<discocaml_>
<polybeanalt> Fairly open ended, ik
<discocaml_>
<polybeanalt> but Id be grateful for any advice
waleee has quit [Ping timeout: 252 seconds]
<czy>
why not right now
<czy>
ml is very expressive, usually you can just build what you have in your mind
Haudegen has joined #ocaml
bgs has joined #ocaml
mbuf has quit [Quit: Leaving]
trev_ has joined #ocaml
jlrnick has joined #ocaml
Serpent7776 has joined #ocaml
mro has joined #ocaml
<discocaml_>
<emillon> You can try to build clones of Unix tools like ls. There's a ton to learn doing that.
<octachron>
More generally, every time you have invariants that you can expose to the users of a module but either cannot or don't want to "prove" in OCaml itself.
<neiluj>
oh nice!
<neiluj>
thanks, very interesting
neiluj has quit [Ping timeout: 246 seconds]
neiluj has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
mro has quit [Read error: Connection reset by peer]
mro has joined #ocaml
azimut has quit [Remote host closed the connection]
azimut has joined #ocaml
Anarchos has quit [Quit: Vision[]: i've been blurred!]
Anarchos has joined #ocaml
mro has quit [Remote host closed the connection]
mbuf has joined #ocaml
John_Ivan has joined #ocaml
mbuf has quit [Quit: Leaving]
mro has joined #ocaml
Haudegen has joined #ocaml
mro has quit [Ping timeout: 255 seconds]
Serpent7776 has quit [Ping timeout: 255 seconds]
azimut_ has joined #ocaml
mbuf has joined #ocaml
azimut has quit [Ping timeout: 255 seconds]
mro has joined #ocaml
mro has quit [Client Quit]
azimut_ has quit [Ping timeout: 255 seconds]
azimut has joined #ocaml
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<discocaml_>
<idnes> pipe based vs not pipe based?
czy has quit [Ping timeout: 252 seconds]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
Anarchos has joined #ocaml
<discocaml_>
<froyo> as in the pipe syscall?
<discocaml_>
<froyo> or the pipe operator?
bartholin has joined #ocaml
<discocaml_>
<froyo> > To close the connection and free associated memory, call Connection.close. This will close all the involved pipes.
<discocaml_>
<froyo> looks like the former
Haudegen has joined #ocaml
neiluj has quit [Ping timeout: 248 seconds]
neiluj has joined #ocaml
<discocaml_>
<leviroth> `Pipe` is the name of a module in Async
<discocaml_>
<froyo> ah, lame
Anarchos1 has joined #ocaml
Anarchos has quit [Ping timeout: 255 seconds]
czy has joined #ocaml
waleee has joined #ocaml
Anarchos1 has quit [Quit: Vision[]: i've been blurred!]
czy has quit [Remote host closed the connection]
<discocaml_>
<polybeanalt> any chance I could look through your github to see what they look like?
<discocaml_>
<polybeanalt> that sounds cool, but admittedly Ive never programmed anything big like that before
<discocaml_>
<polybeanalt> the scale of at all makes it hard for me to figure out where to even start
<discocaml_>
<polybeanalt> the scale of it all makes it hard for me to figure out where to even start
<discocaml_>
<polybeanalt> small coding challenges like AOC are pretty approachable big large undertakings still arent
<discocaml_>
<polybeanalt> small coding challenges like AOC are pretty approachable butlarge undertakings still arent
<discocaml_>
<polybeanalt> small coding challenges like AOC are pretty approachable but large undertakings still arent
trillion_exabyte has quit [Read error: Connection reset by peer]
motherfsck has quit [Ping timeout: 252 seconds]
trillion_exabyte has joined #ocaml
trev_ has quit [Remote host closed the connection]
<neiluj>
hey! say you've got a function (combinator) which takes as input the number of arguments of the second argument which is a function. Concretely: f: n_args:int -> ('a list -> unit). Here the number of args is represented with a list
<neiluj>
is it possible to enforce that the length of the input list is n_args?
<neiluj>
without dependent types?
<neiluj>
or maybe by using a different data type than a list
<neiluj>
because with the above function you have to match on the list to retrieve the args
<neiluj>
do you know if this is doable with some ocaml wizardry or not?
motherfsck has joined #ocaml
bartholin has quit [Quit: Leaving]
<discocaml_>
<froyo> it's not doable if n_args is required to be an int
<neiluj>
thanks!
<discocaml_>
<geoff> so, this isn't strictly an OCaml problem, but I've just been hit by a C++ library that I have written FFI oriented C bindings for updating to C++20. In order to interface with the `std::vector` types central to the library, I had been been been copying them into memory allocated by the caller such that they could be hidden behind an opaque typedef
<discocaml_>
<geoff> Now it seems like I `new` for `std::vector` is toast?
<discocaml_>
<geoff> I'm not really a C++ person so looking around for info/confirmation/ideas as to what I should do instead now is proving not as straightforward as I'd hope
<discocaml_>
<Et7f3 (@me on reply)> I don't understand the direction ?
John_Ivan_ has joined #ocaml
<discocaml_>
<MasterBuilder> toast how?
John_Ivan has quit [Ping timeout: 252 seconds]
<discocaml_>
<geoff> Say I try to allocate a vector with `auto vec = new (mem) std::vector<float>()`, the compiler doesn't stop on using `new`, but instead tells me that push_back doesn't exist:`vec->push_back(e)`
<discocaml_>
<Et7f3 (@me on reply)> instead of auto can you put `std::vector<float>*`
rf has joined #ocaml
Stumpfenstiel has joined #ocaml
<discocaml_>
<MasterBuilder> what are you trying to acheive by placement newing the vector at `mem`?
<discocaml_>
<MasterBuilder> only the vector object itself will be there, i.e. some pointers, the vector data itself will be wherever
<discocaml_>
<Et7f3 (@me on reply)> https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,selection:(endColumn:15,endLineNumber:10,positionColumn:15,positionLineNumber:10,selectionStartColumn:15,selectionStartLineNumber:10,startColumn:15,startLineNumber:10),source:'%23include+%3Cvector%3E%0A%0Achar+buf%5Bsizeof(std::vector%3Cfloat%3E)%5D%3B%0A%0Astd::vector%3Cfloat%3E*+make(float+v)%0A%7B%0A++++auto+vec+%3D+new
<discocaml_>
<geoff> actually I think I might be getting trolled by template errors sorry
<discocaml_>
<Et7f3 (@me on reply)> This seems to compile fine even on older c++
<discocaml_>
<geoff> seems that the overload that is breaking is returning another type but it was very buried
<discocaml_>
<geoff> Yes, but the point is that to `extern "C"` the vector has to be hidden
<discocaml_>
<Et7f3 (@me on reply)> and casting à new std::vector and casting to void* ?
<discocaml_>
<geoff> Can confirm, I panicked for nothing after not fully grasping the template error pile.
<discocaml_>
<Et7f3 (@me on reply)> and using a new std::vector and casting to void* ?
<discocaml_>
<Et7f3 (@me on reply)> Use clang for better error message
<discocaml_>
<geoff> basically, except in this case to `ClipperPathD *`, from `Clipper2Lib::PathD *` which is `std::vector<Clipper2Lib::PointD>`
<discocaml_>
<geoff> so the C interface is "typed"
<discocaml_>
<geoff> rather than void
<discocaml_>
<froyo> neiluj: you can however do something statically-known a-la printf, like this:
<discocaml_>
<froyo> ```ocaml
<discocaml_>
<froyo> type z = private Z
<discocaml_>
<froyo> type _ s = private S
<discocaml_>
<froyo>
<discocaml_>
<froyo> type _ nat =
<discocaml_>
<froyo> | Z : z nat
<discocaml_>
<froyo> | S : 'a nat -> 'a s nat
<discocaml_>
<froyo>
<discocaml_>
<froyo> type (_, _) vec =
<discocaml_>
<froyo> | [] : (unit# type z = private Z, z) vec
<discocaml_>
<froyo> | (::) : 'a * ('b, 'n) vec -> ('a * 'b, 'n s) vec
<discocaml_>
<froyo>
<discocaml_>
<froyo> let rec apply : type n. ((_, n) vec -> _) -> (_, n) vec -> _ = (@@)
<discocaml_>
<froyo>
<discocaml_>
<froyo> let _ = assert (apply (fun [a; b] -> a * int_of_string b) [5; "10"] = 50)
<discocaml_>
<froyo> ```
<discocaml_>
<froyo> but you probably already know this
<discocaml_>
<froyo> oh forget about the `_ nat`, it's useless
<discocaml_>
<Et7f3 (@me on reply)> new placing isn't mandatory
<discocaml_>
<froyo> nvm the paste is broken
<discocaml_>
<froyo> ```ocaml
<discocaml_>
<froyo> type z = private Z
<discocaml_>
<froyo> type _ s = private S
<discocaml_>
<froyo> type (_, _) vec =
<discocaml_>
<froyo> | [] : (unit, z) vec
<discocaml_>
<froyo> | (::) : 'a * ('b, 'n) vec -> ('a * 'b, 'n s) vec
<discocaml_>
<froyo>
<discocaml_>
<froyo> let apply : type n. ((_, n) vec -> _) -> (_, n) vec -> _ = (@@)
<discocaml_>
<froyo> ```
<discocaml_>
<froyo> here we go
<discocaml_>
<froyo> you could even probably forgo the number param actually
<discocaml_>
<froyo> since you already have the types encoding elements
<discocaml_>
<geoff> as in the stack (non pointer) vector would be fine without putting it behind a pointer?
<neiluj>
froyo: wow didn't expect such an answer, many thanks, reading it
<discocaml_>
<geoff> I can't remember if I ever tried that or if I just assumed I had to
<discocaml_>
<geoff> from reading other FFI bindings
<discocaml_>
<Et7f3 (@me on reply)> Not the stack just regular heap
<discocaml_>
<Et7f3 (@me on reply)> `auto vec = new std::vector<float>()`
<discocaml_>
<geoff> sure, but I provide the `void * mem` so that I can allocate in ocaml so it is registered by `Ctypes`
<discocaml_>
<Et7f3 (@me on reply)> If you allocate on the stack When you return the vector the destructor will be called
<discocaml_>
<froyo> wait we strayed a lot from the original question, you can't get a runtime int and return a type out of it.
<discocaml_>
<Et7f3 (@me on reply)> Ah ok then it is fine
<discocaml_>
<geoff> 👍 np it's my fault for giving incomplete context
<neiluj>
froyo: nice! how is your last example supposed to be used? tried apply (fun (a,(b,(c,()))) -> Printf.eprintf "\n %d %d %d \n" a b c) (1::1::1::[]);;
<neiluj>
but it's not correct
Anarchos has joined #ocaml
<neiluj>
ah apply (fun (a::b::c::[]) -> Printf.eprintf "\n %d %d %d \n" a b c) (1::1::1::[]);; works!
Tuplanolla has quit [Quit: Leaving.]
<discocaml_>
<NULL> You can use the full list syntax : `(fun [a; b; c] -> Printf.eprintf ... a b c) [1; 1; 1]`
<neiluj>
oh indeed!
<neiluj>
hmm, is it possible to build an args out of a list?
<neiluj>
it doesn't seem possible with fold_left because the accumulator type is fixed
<neiluj>
trying something with pattern matching
<discocaml_>
<NULL> No, the length is not included in the type information of alist, but is required in `args`
olle has quit [Ping timeout: 246 seconds]
<neiluj>
too bad, thanks :)
<discocaml_>
<froyo> anything that seems to create type information without that information being passed initially is a no-go
Stumpfenstiel has quit [Ping timeout: 255 seconds]
Haudegen has quit [Ping timeout: 255 seconds]
Haudegen has joined #ocaml
Stumpfenstiel has joined #ocaml
<discocaml_>
<froyo> the way I reason about it, idk if crude, is whenever I see a function arrow, the only way for a type variable to be on the right of it is for it to also be on the left.
<neiluj>
so no free variables?
<discocaml_>
<NULL> Not exactly that, but you can't have a return type which depends on an argument
<discocaml_>
<froyo> idk, like I said, my reasoning may be crude. Someone more familiar with type theory can be of better aid to you here. But the general idea is if you want to be deriving types solely from values, you're out of luck without a dependent language ¯\_(ツ)_/¯
<neiluj>
:)
<discocaml_>
<NULL> In OCaml, types cannot depend on values, only on other types. The way around is that GADT members carry more type information
Stumpfenstiel has quit [Ping timeout: 255 seconds]
Haudegen has quit [Ping timeout: 255 seconds]
Haudegen has joined #ocaml
Stumpfenstiel has joined #ocaml
bgs has quit [Remote host closed the connection]
Inst_ has joined #ocaml
Inst has quit [Ping timeout: 255 seconds]
Anarchos has quit [Quit: Vision[]: i've been blurred!]