<d_bot_>
<sabas3dgh> Is it Ocaml this hard or all the functional ones are like this. I don't remember Elisp being this complicated. ... Reading your back and forth is like being is strange place.
<d_bot_>
<sabas3dgh> Learning the abilities that ocaml has let me thinking why so little of marketplace it has amoung other languages.
<d_bot_>
<NULL> I don't understand what you wrote
<sleepydog>
"hard" is subjective and depends on a lot of factors, only some of which are inherent to the language
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<energizer>
popularity is rather self-fulfilling. people want to use languages that have large ecosystems
<d_bot_>
<sabas3dgh> @NULL hi. What didn't you understand.
rgrinberg has joined #ocaml
<d_bot_>
<sabas3dgh> energizer : well you may be right.
<d_bot_>
<sabas3dgh> Do we have sets and maps and keysets in ocaml?
<d_bot_>
<sabas3dgh> Is there a link for data structures and their relevant operations for OCaml?
<d_bot_>
<NULL> I'm pretty sure the sentences you wrote are broken, so much so that I can't understand what you mean
<d_bot_>
<sabas3dgh> Reading the post in the channel made me feel like a stranger in different country.
<d_bot_>
<NULL> What post ?
<sleepydog>
you mean the conversation about the let .. = .. syntax? or just in general?
<d_bot_>
<sabas3dgh> The talks on tagless and make errors .... All in All
<d_bot_>
<sabas3dgh> Yes. That for example
<d_bot_>
<sabas3dgh> But in general.
<d_bot_>
<sabas3dgh> Do we have local mutability in OCaml?
<sleepydog>
yes
<sleepydog>
it's going to be tedious for you to learn something by asking yes/no questions over IRC :). may I recommend https://www.ocaml.org/learn/ ?
<d_bot_>
<sabas3dgh> Sure
<sleepydog>
ocaml is very powerful, and with that power comes the ability to confuse yourself. it's very easy to write "plain" code that most programmers would understand, but the power is there when you need it
zebrag has quit [Quit: Konversation terminated!]
humasect has joined #ocaml
gravicappa has joined #ocaml
azimut has quit [Remote host closed the connection]
azimut has joined #ocaml
gravicappa has quit [Ping timeout: 256 seconds]
hsw has quit [Read error: Connection reset by peer]
<d_bot_>
<Manas (prometheansacrifice)> Does anyone happen to know why the new js_of_ocaml use dune install in it's recipe instead of just dune build -p %name
<d_bot_>
<mseri> `@install` tells duene to only compile code that will be installed, the alternatives are `@all` which compiles everything that can be compiled, `@runtest` compiling and running tests, maybe more and custom aliases
<d_bot_>
<mseri> In this case it is just to be explicit, since `@install` is the default behaviour. But it is robust if this changes in the future
<d_bot_>
<mseri> `dune install` is not related to this, it is a command that allows to install the artifacts compiled by `dune build -p %name @install` into the right place
mro has quit [Ping timeout: 256 seconds]
mro has joined #ocaml
bobo has quit [Quit: Konversation terminated!]
bartholin has quit [Ping timeout: 252 seconds]
Haudegen has quit [Quit: Bin weg.]
bartholin has joined #ocaml
gravicappa has joined #ocaml
mro has quit [Remote host closed the connection]
cedric has quit [Quit: Konversation terminated!]
bartholin has quit [Ping timeout: 272 seconds]
mro has joined #ocaml
bartholin has joined #ocaml
Anarchos has joined #ocaml
Haudegen has joined #ocaml
<companion_cube>
is it me, or is async cancellation still an unsolved problem?
<olle>
Erlang?
<companion_cube>
what about it
<olle>
Solves all
<companion_cube>
it doesn
<companion_cube>
doesn't really have a notion of "async", does it?
<olle>
Not as a keyword, no
<d_bot_>
<Bluddy> I don't really understand the problem myself.
<d_bot_>
<Bluddy> Would it be possible to ELI15?
<Corbin>
In formal message-passing situations, cancellation is itself a message.
<companion_cube>
olle: it doesn't have a notion of promise
<companion_cube>
it's all actors, which is also very interesting, but not relevant to OCaml
<olle>
Maybe Erlang was the OCaml we made along the way...?
humasect has joined #ocaml
<d_bot_>
<Bluddy> so the problem is that you create a promise, which is a future action, but you may change your mind on executing that promise before it runs?
<companion_cube>
what are you even talking about olle
<companion_cube>
@Bluddy: yeah, or it might even be partially done (if it has lots of internal steps)
wonko has quit [Ping timeout: 245 seconds]
humasect has quit [Ping timeout: 256 seconds]
<d_bot_>
<orbitz> @companion_cube I'm not sure if it's an unsolved problem or just the nature of the problem means there will always be hairy edge situations
<companion_cube>
is there a difference? :)
<companion_cube>
"unsolved" can mean it's unsolvable
<d_bot_>
<orbitz> Depends. I interpret it as "it's not known if this is the best we can do", in which case if you know the only possible solution is these hair edge cases, I wouldn't call it unsolved
<olle>
companion_cube: You wanna kill ongoing processes ungracefully?
<olle>
Or you want to enforce promises to listen to kill signals?
<d_bot_>
<orbitz> I believe he is referring to cancelling an ongoing asynchronous operation
<companion_cube>
this, of course
<companion_cube>
as is discussed on discuss
<olle>
Yes?
<d_bot_>
<orbitz> No?
<olle>
So you have those two alternatives, no?
<companion_cube>
what alternatives
<d_bot_>
<orbitz> olle: I'm not quite sure what you're saying. "processes" is not a concept really in ocaml (beyond making OS processes) and "kill signals" tend to have a specific meaning in terms of a SIGKILl or similar
<olle>
I mean process = async thingy running
<companion_cube>
futures are not erlang processes
<d_bot_>
<orbitz> a process is a word with a lot of previous definitions usually around memory guarantees
<d_bot_>
<orbitz> which Ocaml does not have, as companion_cube said
<Anarchos>
futures and promises, aren't they all continuations ?
<olle>
I'll read the thread instead of blabbering ^^
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<d_bot_>
<orbitz> Anarchos: That probably really depends on who you ask
mro has quit [Remote host closed the connection]
mbuf has quit [Quit: Leaving]
<companion_cube>
promises are definitely not just continuations
<companion_cube>
they have to store some state
<olle>
gashe used "fibre"
waleee has joined #ocaml
bartholin has quit [Ping timeout: 252 seconds]
<companion_cube>
pretty sure it's not an erlang process
Anarchos has quit [Ping timeout: 240 seconds]
adanwan has quit [Remote host closed the connection]
<olle>
Sure
adanwan has joined #ocaml
bartholin has joined #ocaml
rgrinberg has joined #ocaml
<d_bot_>
<darrenldl> reminds me a bit of ada's `select then abort`
<d_bot_>
<joris> quite impressive speedup by "tweaking" GC. This is with dune 3
<d_bot_>
<joris> `OCAMLRUNPARAM='o=500,a=2,s=256m,O=1000000'` this is build_and_eat_my_ram
<companion_cube>
@joris have you tried the `--trace=…` option of dune? it's quite cool
<d_bot_>
<joris> yep. But this is purely ocamlc/ocamlopt. 40% of cpu is spent in GC mark and sweep 😄
<theblatte>
@joris: wow, nice!
<companion_cube>
oh in ocamlopt itself, damn
<d_bot_>
<VPhantom> Ah ha! 😛
<d_bot_>
<joris> caveat is that as the name implies, it obviously eats your ram. 3 times more ram, with number of jobs = 16 it uses around 5G max, instead of 1G
<d_bot_>
<VPhantom> (Seriously though, 40% of CPU in GC is more than I would've thought for any kind of work. That's fascinating.)
<d_bot_>
<joris> caveat again it is a guesstimate. This is basically sweep_slice + mark_slice as appearing in perf top during build
<d_bot_>
<joris> but yeah they stay roughly at 40% of samples both of them
<d_bot_>
<joris> dune 3 is a blast in term of perf anyway ❤️
mro has quit [Remote host closed the connection]
mro has joined #ocaml
rgrinberg has joined #ocaml
quartz has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Haudegen has quit [Quit: Bin weg.]
dalek_caan has joined #ocaml
mro has joined #ocaml
Anarchos has joined #ocaml
mro has quit [Ping timeout: 240 seconds]
<d_bot_>
<cemerick> insofar as there is no clear consensus on how a lot of details should work, a diversity of userland approaches seems ideal
<d_bot_>
<Bluddy> This will be disastrous as there will be no compatibility between different libraries.
<sadiq>
joris: what version of OCaml?
<d_bot_>
<cemerick> if and when it becomes clear that any given approach is strictly inferior, then that "disaster" becomes long-term survivability
<sadiq>
guessing 4.13 since best-fit is default in 4.14
<sadiq>
oh no, 4.13 it's the default
<d_bot_>
<cemerick> I remember the massive upheaval when it became clear that Java's original threading approach was a dead-end. The only reason the language survived was because Sun and BEA and IBM were awash in cash they could use to retrofit the model and all of the major apps onto native threads.
<d_bot_>
<mbacarella> what was the original threading model in Java?
<d_bot_>
<mbacarella> oh. is that what "greenthreads" is?
<d_bot_>
<cemerick> yup
<d_bot_>
<cemerick> basically fibers, depending on your definitions
<d_bot_>
<mbacarella> that seems like a really strange bet to have made. would have been curious to sit in on the design decisions.
<d_bot_>
<mbacarella> prediction: SMP is a fad?
<d_bot_>
<cemerick> as multi-CPU and multicore architectures became more common, there was some thrashing as they tried to implement an "M:N" scheme, where you'd have M lightweight threads scheduled onto N hardware threads in order to parallelize and get better concurrency
<d_bot_>
<cemerick> SMP was only a consideration on the highest-end workstations at the time
<sadiq>
this is all pretty funny given project loom
<sadiq>
which is M:N again
<d_bot_>
<cemerick> sadiq: yeah, it goes round and round
<d_bot_>
<mbacarella> right. perhaps Sun found the idea of SMP becoming commonplace unsettling because they didn't think they could compete in that space
<d_bot_>
<cemerick> which is why having a diversity of userland approaches sounds *great* IMO
<d_bot_>
<cemerick> well, sun was aggressively trying to go downmarket
<d_bot_>
<cemerick> set top boxes being Oak's original target
<d_bot_>
<mbacarella> huh.
<d_bot_>
<mbacarella> so, just didn't think SMP could go downmarket?
<companion_cube>
so why was M:N a disaster?
<d_bot_>
<cemerick> in 1994 or whatever? No, that probably seemed fanciful
<d_bot_>
<mbacarella> maybe i'm forgetting how slow computers used to be
<d_bot_>
<cemerick> IIRC, the scheduling overhead swamped the benefit of having N hardware threads
<d_bot_>
<mbacarella> hmm. beos was incepted in... 1995. something i consider an all-in bet on threads and SMP
<companion_cube>
that's hilarious given that now the high-perf architectures do that
<companion_cube>
(well, some do pinned threads I suppose, but still)
<d_bot_>
<cemerick> don't take my word for it, super IIRC here
rgrinberg has joined #ocaml
<d_bot_>
<RegularSpatula> I think I remember a manuscript talking about the more and more memory you give a GC program, the more competitive it gets with manually managed program. Does anyone know this paper, or am I just misremembering and it was some blog post rather than someone's journal paper?
<d_bot_>
<RegularSpatula> that dune benchmark above reminded me of it
<companion_cube>
introducing a new line of fragmentation along the ocaml 5 divide seems… bad?
<d_bot_>
<joris> @sadiq still version 4.12
<d_bot_>
<cemerick> I never understand the concern re: fragmentation
<d_bot_>
<cemerick> lwt "won" on its own merits, the same will likely happen between eio et al. 🤷♂️
<d_bot_>
<joris> i think the N:M issues from 20 years ago also came from the fact that inter core communication and memory bandwidth uses to be super slow, and the nobody was used to the programming model
<companion_cube>
@cemerick but now we risk having half the ecosystem on eio, and half on lwt
<companion_cube>
and then you have to choose your camp because of course interop will suck
quartz has quit [Quit: WeeChat 3.4]
<d_bot_>
<joris> i was involved in some project to implement pthreads with N:M, and the performance was terrible. But mostly because C programs were designed to work with with one thread one core, so it would have needed a rewrite. Then apple released their parallel framework, and it was quite good because all the interface and primitive were built for this
<d_bot_>
<joris> @companion_cube there is already async + lwt technically
<companion_cube>
yes
<companion_cube>
it'd be good to not introduce more fragmentation
<d_bot_>
<cemerick> it's wasteful ofc, but only compared to an imaginary timeline where someone _knows_ what the right solution for the next NN years is, today
<d_bot_>
<joris> in this area rust was smart by managing to define a common interface and having several implementation
<d_bot_>
<joris> but the interface still constrain the implementation quite a bit
<d_bot_>
<cemerick> if there was any kind of consensus among the participants in the spate of design threads of late, then sure, seems worth taking the risk of growing it in stdlib. But there appears to be nontrivial counterclaims and in general a lot of uncertainty.
mro has joined #ocaml
humasect has joined #ocaml
kakadu has quit [Remote host closed the connection]
humasect has quit [Ping timeout: 250 seconds]
<d_bot_>
<orbitz> IMO, I think it'd be great to get a scheduler into the stdlib, kind of like GHC. Us Ocamlers love to do things our own way, but if it's in the stdlib there is a common ground we are bounded by.
<d_bot_>
<orbitz> All solutions will have limitations of some kind, and there is value in eeryone just having to put-up with the same limitations.
mro has quit [Ping timeout: 256 seconds]
<companion_cube>
@cemerick no one is proposing to move eio's stuff into the stdlib
<companion_cube>
and I'd rather not have a standard scheduler, just standard effects
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<d_bot_>
<orbitz> I'm not 100% sure, but I think I'd like a standard scheduler
<companion_cube>
how does this work on jsoo? :p
<companion_cube>
in any case I think it's never going to happen: the compiler and Coq can definitely live without a scheduler
<d_bot_>
<orbitz> depending on how it's implemented, the same way jsoo currently works with the ability to replace implementations of other functions?
<companion_cube>
I think it'd go a bit beyond that
<companion_cube>
although it'd be nice if you could just replace the standard scheduler with JS promises
<d_bot_>
<orbitz> I'm not sure how ghcjs does it. Probably in a way that isn't that helpful to us
<companion_cube>
ghc is also in a very different initial spot
<companion_cube>
lazy IOs and all that stuff
<companion_cube>
OCaml is a lot lower levels, I'd argue.
<companion_cube>
lower leve*
<companion_cube>
lower level*
<companion_cube>
plz buy me basic typing lessons :s
<d_bot_>
<orbitz> But Lwt codes works native and JS so it seems possible to solve in a way such that other solutions could be developed on top without core team having to care about jS, just being careful to not make other things imposisble.
<d_bot_>
<EduardoRFS> is the JSOO + Effects solved?
<companion_cube>
idk
<d_bot_>
<orbitz> companion_cube: I'm not sure why that's relevant. Haskell is certianly a different language, but it offers a green thread scheduler and compiles to native to JS
<companion_cube>
maybe effects were indeed rushed…
<d_bot_>
<orbitz> Well the upside is if they are out, hopefully peopel who are capable will be motivated to finish 🙂
<companion_cube>
@orbitz yeah well, OCaml has had non lazy IOs via a thin C layer for decades, whereas ghc has had light threads and all that for decades as well
<companion_cube>
can't move from one to the other overnight
<companion_cube>
I think I just need to force myself to not give a shit and keep doing my things in my corner
<d_bot_>
<orbitz> companion_cube: I could be wrong but I don't think things are so different than you're making them out to be. My point is not that we can transition from now to whatever Ocaml offers in 5.0 over night, my point is GHC solves scheduler + compiling to native and JS, I dont' think there is a fundamental issue here
<companion_cube>
ah well, it's not clear to me that ghcjs is viable though
<companion_cube>
if it makes multi-MB bundles it's just a nice poc
Anarchos has joined #ocaml
<d_bot_>
<orbitz> Maybe. But even if that is true, that isn't necessarily related to the aspect we are talking about.
bartholin has quit [Quit: Leaving]
<companion_cube>
sure, I do think carefully designed futures could become JS promises and use the JS scheduler, which would be nice
<companion_cube>
but a whole scheduler in the stdlib still seems quite unlikely
<companion_cube>
especially since it'd be optional
mro has joined #ocaml
Haudegen has joined #ocaml
mro has quit [Ping timeout: 256 seconds]
quartz has joined #ocaml
hyphen has quit [Ping timeout: 252 seconds]
hyphen has joined #ocaml
<d_bot_>
<sabas3dgh> Hello.
<dmbaturin>
companion_cube: If someone were to add a function for removing all items matching certain criteria from a list to containers, what would you like it to be named? I.e. `('a -> bool) -> 'a list -> 'a list`
<companion_cube>
like an anti_filter?
<d_bot_>
<sabas3dgh> Could someone tell me what the heck OCaml is doing with the Quarkus(a Java Framework)? What is the rekation? What is its usecase?
<dmbaturin>
companion_cube: Yes. CCList.remove is quite limiting since you need a `'a -> 'a -> bool` function for it.
<dmbaturin>
sabas3dgh: COuld you point us to a link to source code or docs that confuse you?
<companion_cube>
dmbaturin: I mean `filter (fun x -> not (f x))` no?
<dmbaturin>
companion_cube: Ah, I see what you mean. Maybe that's not worse indeed.
mro has joined #ocaml
mro has quit [Ping timeout: 240 seconds]
dextaa_ has joined #ocaml
dalek_caan has quit [Quit: dalek_caan]
vicfred has joined #ocaml
quartz has quit [Quit: WeeChat 3.4]
mro has joined #ocaml
<d_bot_>
<Bluddy> Regarding the point about having competing user-mode libraries compete, I think it misses 2 points:
<d_bot_>
<Bluddy> 1. In reality, most competing alternative libraries don't have a clear winner. Lwt and Async have slightly different semantics, but neither one has sufficient competitive advantage to defeat the other.
<d_bot_>
<Bluddy> 2. Also in the real world, highly complex software usually isn't written by hobbyists on their spare time, but rather is sponsored by stakeholders. Those stakeholders, who put money into development of their library, aren't going to easily give up on it. And so, the competing libraries live on, continuing to fragmenting the community.
Anarchos has quit [Quit: Vision[]: i've been blurred!]
mro has quit [Ping timeout: 250 seconds]
mro has joined #ocaml
mro has quit [Ping timeout: 272 seconds]
Haudegen has quit [Quit: No Ping reply in 180 seconds.]
Haudegen has joined #ocaml
mro has joined #ocaml
<d_bot_>
<VPhantom> Well put @Bluddy. I've seen a lot of work in the libraries I looked into, invested in abstracting lwt vs async in order to support both, for example, because choosing one would alienate too many users.
x88x88x has joined #ocaml
Tuplanolla has joined #ocaml
gdd has quit [Quit: WeeChat 3.3]
gravicappa has quit [Ping timeout: 240 seconds]
gdd has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
quartz has joined #ocaml
waleee has joined #ocaml
mro has quit [Ping timeout: 250 seconds]
hyphen has quit [Ping timeout: 240 seconds]
oriba has joined #ocaml
<companion_cube>
ahah damn, atdgen is broken since the last menhir release
<quartz>
Hello, can someone please explain the syntax behind "val xor : bool * bool -> bool = <fun> from this image? https://i.ibb.co/R2tqRGs/image.png
<d_bot_>
<NULL> `val <ident> : <type> = <value printed the best it can be>` ?
<quartz>
Huh?
<quartz>
Is p a variable in this case?
<d_bot_>
<NULL> Not sure what "syntax" you want explained
<d_bot_>
<NULL> `let <id> <arg1> ... <argn> = <expr>` is sugar for `let <id> = fun <arg1> ... <argn> -> <expr>`, so variable or formal argument, whichever you want to call it
<quartz>
Hmmm, OK.
<sleepydog>
the syntax highlighted in red is distinct. in this case, it's the ocaml interpreter's description of the value defined in the preceding expression. it happens to match OCaml's syntax for module signatures
<d_bot_>
<cemerick> FWIW, at least according to opam stats, lwt is used by ~6x more packages than async. JS keeps on with async for their own (probably good) reasons, but I think that kind of lopsided usage denotes a "winner"
<d_bot_>
<NULL> sleepydog: Only if you disregard `= <fun>` though
<sleepydog>
ah, yes, good catch
<d_bot_>
<cemerick> every language community has competing implementations satisfying a similar set of functionality, even those that include an implementation in their standard libraries. Competition (even leading to schisms in integration) is a sign of community size and health, not the opposite IMO
<sleepydog>
I think I generally agree with cemerick, but I always get a sense of FOMO when I'm forced to choose between two implementations. What if I made the wrong choice?
<d_bot_>
<VPhantom> Personally I see competition in a very small community as too expensive, whereas I see it as healthy in large communities with ample man-hours to invest. Since I have chosen Lwt, I will not consider using packages that use Async. That's an unfortunate fragmentation of an already small community.
<d_bot_>
<Anurag> There is a fair bit of async code that will never be seen on opam. Multiple industrial users (not Janestreet) use async.
<sleepydog>
It would be nice if some core types were defined in the stdlib, and then lwt/async/etc just provided implementations of those types, and library authors only worked with those types and didn't have to care about what concurrency runtime their callers used
<d_bot_>
<cemerick> absolutely granted, but we can only evaluate that which is publicly known
<d_bot_>
<VPhantom> (Luckily a lot of packages go through the extra trouble to support both.)
<sleepydog>
but I think it was said earlier, it's very hard to define the right abstractions, as everything has a tradeoff
<d_bot_>
<VPhantom> That would be lovely @sleepydog.
<sleepydog>
I like where gasche is trying to push the eio discussion towards basic questions, like how to block, how to cancel, etc.
<d_bot_>
<Anurag> @sleepydog: types are not the only thing that differs in async and lwt though. They have different semantics around binds, and very different approaches to error handling.
<sleepydog>
I like to think that those differences could remain as they are by finding common ground at a lower level. But I'm not well versed enough in either library.
<d_bot_>
<cemerick> an analogue situation would be something like e.g. web frameworks. It seems obviously good that there are multiple, and surely more to come, and at a certain point of adoption, there will be framework-specific extension libraries that aren't easily portable to others. Why is that situation different from other categories of libraries/frameworks?
<sleepydog>
I think web frameworks are easier to compose with each other, though, so the duplication of effort is not as tragic.
<d_bot_>
<cemerick> tell that to the rails and merb folks some years back
<d_bot_>
<cemerick> concretely, there's all sorts of niggly details in a web framework (streaming vs wholesale response generation, for example) that make having a unitary set of abstractions pretty challenging
quartz has quit [Ping timeout: 256 seconds]
dextaa_ has quit [Remote host closed the connection]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<companion_cube>
Even the basic types are not shared
Tuplanolla has quit [Ping timeout: 240 seconds]
<companion_cube>
The problem with async libraries is that they're so fundamental that there's a whole ecosystem on top of each
<companion_cube>
Redis clients, db connectors, graphql stuff, all sorts of protocols, are all dependent on the basic underlying concurrency library
<companion_cube>
If we had at least a standard future type, we could hope for better interop, but alas it never happened