myrkraverk has quit [Read error: Connection reset by peer]
mbuf has joined #ocaml
myrkraverk has joined #ocaml
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
tomku has quit [Ping timeout: 248 seconds]
tomku has joined #ocaml
cedb has joined #ocaml
pieguy128_ has joined #ocaml
pieguy128 has quit [Ping timeout: 252 seconds]
dreadedfrog has joined #ocaml
alexherbo2 has joined #ocaml
Serpent7776 has joined #ocaml
olle has joined #ocaml
<discocaml>
<ada2k> i’m failing to see where immutable arrays are really useful. for most functional applications linked lists are surprisingly fine anyway
<discocaml>
<ada2k> i don’t really use normal arrays that much either though
<discocaml>
<octachron> If you are using lists as literals for containing multiple values, immutable arrays are just a better choice.
<discocaml>
<octachron> For linear algebra, you often don't want immutable arrays either.
<discocaml>
<octachron> *mutable arrays
<discocaml>
<ada2k> if it’s ready no reason not to include it, the stdlib should be larger
<discocaml>
<ada2k> maybe i’ve just not encountered enough situations where they would be useful (or used lists or bigger abstractions at the cost of performance)
<olle>
Access time is different for arrays and lists
<olle>
O(n) vs O(1)
<olle>
Other way around :)
<discocaml>
<octachron> My opinion is that I agree that immutable arrays can nudge people to use a more compact memory representation by not defaulting to a list.
<discocaml>
<octachron> olle, when you need random memory access, using arrays is already the natural choice with or without immutable arrays.
<olle>
octachron: sure, but with immutable arrays you don't have to choose between O(1) and immutability?
<olle>
idk
<olle>
Feels like a wrapper around array module would do the trick, heh
<olle>
But I didn't follow the discussion.
szkl has quit [Quit: Connection closed for inactivity]
Tuplanolla has joined #ocaml
<discocaml>
<otini_> Since the notion of immutable array already exists in the compiler’s intermediate language, it is cheap to add a few primitives to construct such arrays and a standard module using these primitives. In addition to nudging toward not choosing between immutability and constant access, it provides niceties such as static allocation of statically-known arrays (i.e., such arrays can be directly written to the read-only data section of the program
<discocaml>
<otini_> I agree it is not much, but the cost to having that is low, too
<discocaml>
<otini_> I also suspect that an immutable data structure will play well with future features and optimizations that we may want to introduce
bartholin has joined #ocaml
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ocaml
Inline has joined #ocaml
tcfhk has joined #ocaml
olle has quit [Ping timeout: 264 seconds]
tcfhk is now known as ethqvk
inline__ has joined #ocaml
Inline has quit [Killed (iridium.libera.chat (Nickname regained by services))]
inline__ is now known as Inline
ethqvk has quit [Remote host closed the connection]
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ocaml
Inline has quit [Quit: Leaving]
Inline has joined #ocaml
alexherbo2 has quit [Remote host closed the connection]
<companion_cube>
if you want to do linear algebra don't use OCaml :p
<companion_cube>
anyway, immutable arrays are not bad in absolute terms, they're just a really niche improvement
<companion_cube>
and dog knows OCaml has more pressing issues
<octachron>
OCaml development is not exactly a single priority queue. Whatever are your "more pressing issues", they would probably not progress faster with or without immutable arrays.
<companion_cube>
🤷
<companion_cube>
I mean I think you're right. My problem is more with the set of priority queues than with their precise content.
<companion_cube>
(I mean "problem" is not great, I'm not entitled to anything, just fairly pessimistic)
<discocaml>
<drupyog> by curiosity, what are you current "most pressing issues" ?
<companion_cube>
ha!
<companion_cube>
hold on a minute, I need to gather my thoughts in a semi coherent form :p
<discocaml>
<drupyog> Bonus question: have they changed in the last 10 years and how ? :p
<companion_cube>
oh good one, yeah! :)
Inline has quit [Ping timeout: 264 seconds]
<companion_cube>
for a start I think it's dependent on whether the core team wants OCaml to be successful beyond {Coq, Inria, ocamllabs} and a few shops that have been using OCaml for a while
<companion_cube>
but assuming it's the case, I think the team needs to realize that they have to care about more than data structures in the stdlib (it's almost all about the stdlib, the language is fine aside from GC perf issues)
<companion_cube>
ie, they need to get the stdlib in working shape for people who are not writing batch-style theorem provers
<discocaml>
<drupyog> (for how long I've known you, I feel you have always been sort-of-critical towards the "sets of priority queues", as you say, but I'm not convinced you didn't ended up with many features from your own priorities, on top of the rest)
<companion_cube>
yeah I've been a grouch for a long time, it is known
<discocaml>
<drupyog> 😄
<companion_cube>
what changed is the rest of the world, I think OCaml is a lot less competitive now just because the bar has risen much higher in the mean time
<companion_cube>
anyway, you want OCaml to have a fighting chance for stuff 90% of people are paid to write? standardize json, http, compression, ideally a scheduler (libuv?) even if it's swappable, integrate picos (or sth like it), etc.
<companion_cube>
might come as a huge surprise, but, err, rework the IOs *hard* (probably around bigstrings)
<discocaml>
<drupyog> I mean, I don't completely disagree, but I'm not sure so many succesful language really have that much stuff in their standard library
<companion_cube>
adding immutable arrays is really worrying about the bikeshed's style of door knob
<companion_cube>
well, compare with Go or Java
<discocaml>
<drupyog> and in many cases, "standard library is here library go to die"
<companion_cube>
Go being the n°1 competitor at this point
<discocaml>
<drupyog> and in many cases, "standard library is where libraries go to die"
<companion_cube>
yeah that might be true for python and stuff irrelevant for 20 years
<discocaml>
<drupyog> probably, unfortunately
<companion_cube>
OCaml is high level, I think it really should have a standard concurrency/IO story (whcih again could be libuv)
alexherbo2 has joined #ocaml
<companion_cube>
(oh and, ofc, standardize a domain pool or get rid of domains altogether, although I know it won't happen)
<companion_cube>
oh I didn't even mention cryptography, base64, hex, etc. but that's part of it all ofc
<companion_cube>
without a reasonable alternative to Go's stdlib, OCaml will stagnate at best
<discocaml>
<drupyog> So dramatique :p
<discocaml>
<drupyog> There are lot more people doing stuff in OCaml now that when we started though, it's quite incompatible
<discocaml>
<drupyog> There are lot more people doing stuff in OCaml now that when we started though, it's quite incomparable
<companion_cube>
are there? I'm not even sure
<companion_cube>
besides the growth of JST, that is
<discocaml>
<drupyog> oh yeah
<companion_cube>
lots of people have left, too
<companion_cube>
on balance I'm really not sure it's that much bigger
<discocaml>
<drupyog> I mean, you might be in a corner when not many people do OCaml, so you only see the online presence
<companion_cube>
otoh you're in Paris which is obviously a stronghold :)
<discocaml>
<drupyog> I'm not in Paris anymore :p
alexherbo2 has quit [Remote host closed the connection]
<companion_cube>
Rennes?
<discocaml>
<drupyog> but yes, definitely a lot more people doing OCaml things than 10 years ago
<discocaml>
<drupyog> Lyon
<companion_cube>
oh nice
<discocaml>
<lecondorduplateau> you're a competitor ccube
<discocaml>
<lecondorduplateau> why you want ocaml to be competitive
<discocaml>
<lecondorduplateau> Lyon 🔥🔥
<companion_cube>
cause language mindshare is a competition? :)
<discocaml>
<otini_> companion_cube: I don’t disagree with any of your priorities, have you tried pushing for them
<companion_cube>
in other words, a language whose community stagnates or shrinks over time, becomes less and less relevant
<companion_cube>
(meaning the ecosystem rots, there's no jobs, existing code bitrots, etc.)
<companion_cube>
(eventually you become cobol)
Inline has joined #ocaml
<discocaml>
<lecondorduplateau> no matter what, I'll keep writing my little programs in OCaml like a software craftsman
<companion_cube>
@otini_ I'm not going to change the mindset and roadmap of the core team :D
<discocaml>
<drupyog> And a language with a dying community is just not very pleasant to use: you have noone to interact with, and a swamp of unmaintained libraries
<companion_cube>
exactly
<discocaml>
<drupyog> (Cf Prolog ...)
<companion_cube>
look at perl, too
<discocaml>
<otini_> companion_cube isn’t the core team evolving with time though?
<discocaml>
<otini_> well so will I, except if one day it becomes just too annoying to install the tools, have a decent dev experience and distribute the result
<discocaml>
<otini_> which could happen if ocaml were to fall behind
<companion_cube>
distributing is already a bit of a pain, the rest is fine
<discocaml>
<otini_> atm I see rather the opposite trend
<discocaml>
<drupyog> @companion_cube you have to admit that the tooling has progressed a lot though
<companion_cube>
for sure, dune, ocamllsp are great
<companion_cube>
I have my qualms with ocamlformat and opam but at least they do the job
<discocaml>
<drupyog> and odoc&co ✨
<companion_cube>
tools are pretty good in good part because JST is bankrolling them
<companion_cube>
yes, my bad, odoc is good too (and ocaml-setup, etc.)
<octachron>
I agree that the state and process of evolution of the standard library is not great, there is too much friction. My feeling is part of the issue is that compiler writers are not necessarily standard library writers.
<companion_cube>
and I don't imagine Inria wants to fund people to work on the stdlib
<companion_cube>
but the _scope_ of the stdlib should grow, imho, not just add a few modules there and there
<discocaml>
<drupyog> gasche wanted to form a stdlib team, but that didn't seem to get traction, which is a shame
<companion_cube>
(adding modules has been good, not questioning that!)
<octachron>
Pitching the idea to recruit a full time "OCaml stdlib" engineer could be fun, I fear it will hard to find a spot between quantum computers and AI hires.
Inline has quit [Quit: Leaving]
<octachron>
Maybe by convincing people that Catala really needs a better OCaml stdlib?
<discocaml>
<drupyog> there might be an angle as part of the Gospel project, but it'll be tricky
<companion_cube>
turning the ship now is hard, for sure
<companion_cube>
and academic research in a funding drought (except for AI) is not the best vehicule to fund a language :(
Inline has joined #ocaml
Inline has quit [Ping timeout: 265 seconds]
alexherbo2 has joined #ocaml
<discocaml>
<thepuzzleddev> does anyone know of a compiler for standard ml
<discocaml>
<thepuzzleddev> does anyone know of an interpreter for standard ml
alexherbo2 has quit [Remote host closed the connection]
pfcaut has quit [Remote host closed the connection]
<discocaml>
<ada2k> (as a relative newcomer) it just seems like the issue is having like, max 3 organisations, really invested
<discocaml>
<ada2k> it means that a lot of the code actually landing up used is what JST wants, which might not align with beginners or other users
<companion_cube>
in a way it'd be almost easier if we _all_ switched to the JST ecosystem, that'd kill the fragmentation
<companion_cube>
(but it'd also kill backward compatibility! and stability promises)
<discocaml>
<octachron> That's not really the case? Typically, JST was not really interested by multicore as far as I remember.
<companion_cube>
they seem interested in effects though, and in Eio at least in the recent past
<discocaml>
<ada2k> i’m not saying it as a blanket statement or even a negative thing (having a large company care that much at all is good)
<discocaml>
<ada2k> but even if they didn't back multicore, there's not many orgs that can say push for design changes in the biggest multicore scheduler ;p
<discocaml>
<ada2k> just a fact of life, although i do seem to use more software with links to mirage than jst
Inline has quit [Quit: Leaving]
Inline has joined #ocaml
toastal has joined #ocaml
<discocaml>
<thepuzzleddev> how can I turn a string into a list?
Inline has quit [Quit: Leaving]
waleee has joined #ocaml
<discocaml>
<thepuzzleddev> how can I pattern match a string
<discocaml>
<yawaramin> you can use string literal patterns or bind the string to a name pattern
Inline has joined #ocaml
<discocaml>
<thepuzzleddev> what does that look like?
<discocaml>
<yawaramin> ```ocaml
<discocaml>
<yawaramin> match str with
<discocaml>
<yawaramin> | "hello" -> 1
<discocaml>
<yawaramin> | nohello -> 2
<discocaml>
<yawaramin> ```
mbuf has quit [Quit: Leaving]
<discocaml>
<thepuzzleddev> Is there a way to do something like ```ocaml
<discocaml>
<thepuzzleddev> match str with
<discocaml>
<thepuzzleddev> | "-" ^ foo -> 1
<discocaml>
<thepuzzleddev> | _ => 2
<discocaml>
<thepuzzleddev> ```
<discocaml>
<ada2k> you can use a `when` clause to match against variables
<discocaml>
<yawaramin> no, you will need to use alternative approaches for that
<discocaml>
<ada2k> e.g. `| _ when String.ends_with foo -> 1`
<discocaml>
<ada2k> whoops, that doesn't actually work
<discocaml>
<yawaramin> for example ^
<discocaml>
<yawaramin> but really in this case might as well use if/else because you're not doing any structural matching
<discocaml>
<thepuzzleddev> Well, ye, but in a real case i'd be more complex than that
<discocaml>
<thepuzzleddev> I also read that you can convert a string to a sequence, but I could not find anything on how to pattern match it
<discocaml>
<ada2k> i use when causes quite a lot since it's syntactically nicer
<discocaml>
<yawaramin> i use `String.split_on_char` a lot and then pattern match on the output list
<discocaml>
<ada2k> aside but if you’re doing a lot of string stuff you might want to look in stringext or containers, it’s much more complete than the stdlib
<discocaml>
<thepuzzleddev> I mean, can I just turn the string into a list?
torretto has quit [Remote host closed the connection]
torretto has joined #ocaml
toastal has left #ocaml [Error from remote client]
Anarchos has joined #ocaml
<discocaml>
<deepspacejohn> you can also use Scanf
tomku has quit [Ping timeout: 260 seconds]
tomku has joined #ocaml
<discocaml>
<.armael.> I’ve recently used Astring and it’s Sub module for substrings with good success for that kind of string matching/ad-hoc parsing
<discocaml>
<.armael.> Though going through Seq works as well if your strings aren’t big
Anarchos has quit [Ping timeout: 260 seconds]
alexherbo2 has joined #ocaml
<discocaml>
<._null._> Why do you want to do that? It's expensive and very rarely useful
<discocaml>
<thepuzzleddev> Ye, I ended up finding another way that worked better I was originally for argument parsing, but then I relzied I could just use `starts_with`
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ocaml
alexherbo2 has quit [Remote host closed the connection]
Serpent7776 has quit [Ping timeout: 264 seconds]
<discocaml>
<swayingfish> Anyone know if there is a documentation for effect handler related syntax in OCaml 5.3.0?
TCZ has joined #ocaml
YuGiOhJCJ has joined #ocaml
<discocaml>
<dx3mod> Did they add a new syntax or do you mean `type .. +=`?
twobitsp1ite has joined #ocaml
<twobitsp1ite>
how important are interface files in applications (as opposed to libraries)?
twobitsp1ite is now known as twobitsprite
<twobitsprite>
how important are interface files in applications (as opposed to libraries)? ((nick-collided myself))
bartholin has quit [Quit: Leaving]
<discocaml>
<Kali> ocaml 5.3.0+trunk merges the new effect syntax but there isn't a new version of the manual yet officially, i believe
<discocaml>
<Kali> although it seems only the pattern matching part of it got added and not the effect declaration syntax, unless i'm misreading
<companion_cube>
twobitsprite: not important
aljazmc has joined #ocaml
<twobitsprite>
thanks
<discocaml>
<dx3mod> Wow 😲
<twobitsprite>
another question, would the standard OCaml graphics library be efficient (or sufficient) for simple 2D game development using sprites and spritemaps, or should I use something more sophisticated like tsdl?
<companion_cube>
graphics is 20 years obsolete, I'd say g with sdl indeed :)
<companion_cube>
Go with*
<twobitsprite>
lol, ok, thanks
<twobitsprite>
is tsdl the best / most up to date SDL library?
<discocaml>
<dx3mod> I'm still using version 5.1. Otherwise, opam downgrades the compiler, especially for ocaml-lsp-server.
<twobitsprite>
I see there's also a OCamlSDL2 package, but it seems like it hasn't been updated in a few years...
<twobitsprite>
or maybe it would be easier to just 'external' my way into the SDL functions I need..?