pi3ce has quit [Read error: Connection reset by peer]
pi3ce has joined #ocaml
pi3ce has quit [Client Quit]
bartholin has quit [Quit: Leaving]
pi3ce has joined #ocaml
szkl has joined #ocaml
raskol has joined #ocaml
ds-ac has quit [Ping timeout: 260 seconds]
raskol has quit [Ping timeout: 246 seconds]
Serpent7776 has joined #ocaml
YuGiOhJCJ has joined #ocaml
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #ocaml
contificate has joined #ocaml
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #ocaml
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #ocaml
pi3ce has quit [Read error: Connection reset by peer]
pi3ce has joined #ocaml
ds-ac has joined #ocaml
gooby323 has joined #ocaml
<gooby323>
Good afternoon my fellow camels
contificate has quit [Quit: Client closed]
alexherbo2 has joined #ocaml
alexherbo2 has quit [Remote host closed the connection]
gooby323 has quit [Quit: Konversation terminated!]
alexherbo2 has joined #ocaml
<discocaml>
<gooby_clown> It invites the Haskell demons
<discocaml>
<gooby_clown> And other evil spirits
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ocaml
raskol has joined #ocaml
bartholin has joined #ocaml
<discocaml>
<lukstafi> Can I get the return module type of a functor without being as ugly as `include module type of F(struct type t = my_t let x = assert false end)`?
<discocaml>
<octachron> This use of `module type of` is very brittle. You will better served writing down the functor return module type yourself.
f[x] has joined #ocaml
<discocaml>
<octachron> (using either `with` constraints or the module type within a functor trick)
f[x] has quit [Remote host closed the connection]
f[x] has joined #ocaml
trillion_exabyte has quit [Ping timeout: 255 seconds]
trillion_exabyte has joined #ocaml
toastal has joined #ocaml
<discocaml>
<lukstafi> Any tips to investigate why `include M_common with ty := ty` could make `ty` abstract, while if I comment the include line out `ty` remains concrete?
<discocaml>
<reynir1396> does it help to write `with type nonrec ty := ty`?
<discocaml>
<octachron> `type ty := ty` is correct, since the LHS and RHS don't live in the same environment.
<discocaml>
<lukstafi> No -- `:=` should be like textual substitution, so the behavior I see (based on VSCode type annotations)
<discocaml>
<lukstafi> looks impossible.
<discocaml>
<lukstafi> But `M_common` has `ty` via another `include`.
<discocaml>
<lukstafi> The situation is `module type M = sig include M_types include M_common with type ty := ty` -- where `M_types` has the concrete definition of `ty` and `M_common` has `type ty` as abstract.
Haudegen has joined #ocaml
<discocaml>
<lukstafi> Even `module type M = sig include M_types type nonrec ty = ty = {...} include M_common with type ty := ty end` does not make `ty` non-abstract in what gets reported for `M`... I'll fix other type errors and fingers crossed this disappears.
<discocaml>
<lukstafi> Ahh fixed! `M_common` was shadowing a type that's part of the concrete definition of `ty`, so this works: `module type M = sig include M_types include M_common with type ty := ty and ty_part := ty_part end`
Phandal has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ocaml
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ocaml
spew has joined #ocaml
Phandal has quit [Ping timeout: 276 seconds]
Phandal has joined #ocaml
<discocaml>
<barconstruction> This isn't really it. Module functors are named by loose analogy with category theoretic functors not by a formal correspondence
<discocaml>
<softwaresirppi> Oh!
<discocaml>
<softwaresirppi> Also I was thinking why string type exists?
<discocaml>
<softwaresirppi> Why not just use a char list like Haskell?
<discocaml>
<softwaresirppi> [Char]
<discocaml>
<._null._> It's not a lined list, that would be wildly inefficient
<discocaml>
<barconstruction> I don't think Haskell users really ever use [Char] when performance is at hand
<discocaml>
<._null._> It's not a linked list, that would be wildly inefficient
<discocaml>
<softwaresirppi> Just make the compiler smarter?
<discocaml>
<barconstruction> I don't think Haskell users really ever use [Char] when performance is a matter at hand
Phandal has quit [Ping timeout: 244 seconds]
<discocaml>
<softwaresirppi> Oh that's not magically optimized to be an array ?
<discocaml>
<._null._> That's unreasonable levels of smart. We already have float arrays and they can get very annoying
<discocaml>
<softwaresirppi> Okay fair enough
<discocaml>
<softwaresirppi> How to pattern match a string then?
<discocaml>
<._null._> Either as a literal or not. Or use regex / parsing tools
<discocaml>
<barconstruction> Not afaik but you should confirm with a Haskell user.
<discocaml>
<softwaresirppi> I don't know either
<discocaml>
<softwaresirppi> I really like the cleanness of haskell
<discocaml>
<softwaresirppi> People say Ocaml is also a clean and elegant language. Let's see how it goes!
<discocaml>
<contificate> people say this and then dig into any moderately complex Haskell codebase
<discocaml>
<softwaresirppi> Lol idk man I'm just a passer-by
<discocaml>
<deepspacejohn> You can use Scanf for lightweight regex-style string matching.
<discocaml>
<barconstruction> You should consider the value of transparency in reasoning about the performance of code. The "smarter" the compiler is, the less you are able to understand what happens, the less you are able to assure yourself of the running time of the code you are writing.
<discocaml>
<barconstruction>
<discocaml>
<barconstruction> If Haskell claimed textually that a string was a linked list of characters but then optimized it to be an array then the runtime costs would be completely different than the user expects. They would be unable to perform basic algorithmic analysis on their code.
<discocaml>
<barconstruction> When a language is "What you see is what you get" then it's more straightforward to analyze the performance of algorithms.
<discocaml>
<lukstafi> I just had a situation where the compiler refused to accept code using `type st = s t` shortcuts claiming that "`M1.s` is different than `s`", I couldn't figure out why, but when I removed the shortcuts `st` it was happy.
Tuplanolla has joined #ocaml
Phandal has joined #ocaml
gareppa has joined #ocaml
gareppa has quit [Quit: WeeChat 4.1.1]
gareppa has joined #ocaml
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ocaml
Anarchos has joined #ocaml
f[x] has quit [Remote host closed the connection]
f[x] has joined #ocaml
Anarchos has quit [Quit: Vision[]: i've been blurred!]
Anarchos has joined #ocaml
gareppa has quit [Quit: WeeChat 4.1.1]
<neiluj>
thinking about writing a toy functional programming language compiling to LLVM's IR... hesitating between ocaml and haskell, curious to try out haskell as it has some nice libraries like megaparsec
<neiluj>
does someone has experience writing in both and would chose one over the other for a particular task?
<neiluj>
oh nice! what a life saver! not interested in learning LLVM indeed :)
<neiluj>
so with ocaml-gccjit one needs to compile to a C-like language
<discocaml>
<contificate> I just generally prefer OCaml - I think the LLVM bindings are pretty good. The issue for functional languages is bending LLVM to support things you'd want in a non-toy implementation.
<discocaml>
<contificate> A small benefit of Haskell is that it has an LLVM library that doesn't do native bindings, it's a subset of the IR construction logic in Haskell.
<neiluj>
thanks!
honeydatax has quit [Quit: Leaving]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
Everything has joined #ocaml
bartholin has quit [Quit: Leaving]
Phandal has quit [Quit: leaving]
f[x] has quit [Remote host closed the connection]
<discocaml>
<softwaresirppi> Okay this contrasts two schools of thought. Code is the intent vs Code is actual instructions. I understand your point. If that's the case why not we all write a good enough preprocessor on top of assembly, and call it a day?
<discocaml>
<softwaresirppi> Fair
<discocaml>
<softwaresirppi> Yeahh but I kinda wished something like that being there in pattern matching. But alright
<discocaml>
<softwaresirppi> Okay this contrasts two schools of thought. Code is the intent vs Code is actual instructions. I understand your point. If that's the case why not we all write a good enough preprocessor on top of assembly, and call it a day?
<discocaml>
<softwaresirppi>
<discocaml>
<softwaresirppi> I'm not only talking about making linked strings to vector strings... This could apply to any type? The compiler figures out which is better?
<discocaml>
<contificate> There's sedlex, which would be raw perfection if it supported submatch extraction (matching groups) by way of `as ..`
Haudegen has joined #ocaml
Serpent7776 has quit [Ping timeout: 260 seconds]
Tuplanolla has quit [Quit: Leaving.]
Everything has quit [Quit: leaving]
neiluj has quit [Quit: WeeChat 4.2.1]
<discocaml>
<darrenldl> what kind of string pattern matching are you looking for? (or if you have examples from other languages that do what you want)
<discocaml>
<softwaresirppi> A simple cons? `first :: rest` ?
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ocaml
alexherbo2 has quit [Remote host closed the connection]