<kluk>
How do I start using DynArray from the ocaml command line?
<kluk>
I have already done opam install extlib
<kluk>
I am a newbie at OCaml
mbuf has joined #ocaml
mro has joined #ocaml
mro has quit [Ping timeout: 272 seconds]
vicfred has quit [Quit: Leaving]
vicfred has joined #ocaml
kluk has quit [Read error: Connection reset by peer]
zodeishi has quit [Ping timeout: 268 seconds]
Wilfred has joined #ocaml
mro has joined #ocaml
mro has quit [Ping timeout: 272 seconds]
pieguy128 has joined #ocaml
vicfred has quit [Quit: Leaving]
mro has joined #ocaml
mro has quit [Ping timeout: 244 seconds]
mro has joined #ocaml
wonko has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Client Quit]
Haudegen has joined #ocaml
wonko has quit [Changing host]
wonko has joined #ocaml
berberman has joined #ocaml
berberman_ has quit [Ping timeout: 272 seconds]
wonko has quit [Ping timeout: 272 seconds]
olle has quit [Quit: leaving]
dhil has joined #ocaml
dockerusocamlus has joined #ocaml
<dockerusocamlus>
Hello! I'm minimizing an Alpine-based Docker image with OCaml installed via opam, and I'm trying to understand if I could erase some files to save some space. Basically, trying to understand if they are needed only on special situations, or if that would cause issues for users of the Docker image.
wonko has joined #ocaml
<dockerusocamlus>
For instance, in this image, I have file ~/.opam/<version>/lib/ocaml/expunge, which take 15 MB of space. I don't think I have ever used it, but I don't know if it's internally used by some other OCaml process.
<dockerusocamlus>
I don't have much documentation about it, and grepping ocaml's sources only shows a few occurrences. It seems related to the installation of the OCaml compiler itself, but even after removing it, I'm still able to do a `opam switch create` to install a different compiler, so... I guess it's fine to remove it?
bartholin has joined #ocaml
Wilfred has quit [Quit: Connection closed for inactivity]
<octachron>
This is a compiler tool which is used to build REPLs. It is also used by utop.
<dockerusocamlus>
Thanks!
olle has joined #ocaml
dockerusocamlus has quit [Quit: Connection closed]
dhil has quit [Ping timeout: 245 seconds]
Serpent7776 has quit [Quit: leaving]
swarm has joined #ocaml
swarm42 has joined #ocaml
swarm has quit [Ping timeout: 250 seconds]
spip has joined #ocaml
Guest74 has quit [Read error: Connection reset by peer]
spip is now known as Guest8492
noisy-bot has joined #ocaml
spip has joined #ocaml
Guest8492 has quit [Read error: Connection reset by peer]
<d_bot>
<EduardoRFS> yes but the compiler knows it
<adrien>
not sure how is the generated code but in that case it's not a new tuple
<zozozo>
there is a PR to do pretty much that (the link I posted above)
<theblatte>
I keep writing functions like `let f ((a,b) as x0) = let a' = g a in let b' = g b in if a == a' && b == b' then x0 else (a', b')`
<d_bot>
<EduardoRFS> in this case yes, but not all cases, I'm not asking about this specific tuple, I'm asking more about identical blocks that are known to be always identical
<companion_cube>
I don't think it's a very useful optimization to see if per chance two different variants of different types happen to have the same binary representation
<companion_cube>
more important stuff is to eliminate temporaries imho
<companion_cube>
like a tuple built just to be deconstructed in the same function
<companion_cube>
(or an option…)
<zozozo>
companion_cube: what do you mean by "temporaries"?
<d_bot>
<EduardoRFS> temporary allocations IIUC
<companion_cube>
data that doesn't escape the current function :p
<zozozo>
companion_cube: ah, well, avoiding these is more or less exactly the job of flambda, ^^
<d_bot>
<EduardoRFS> I'm looking on it, the argument of not being predictable is sad, it's a flat allocation reduction, no hidden allocation, not trying to make non efficient code efficient, but trying to make code that is efficient as possible more efficient
<zozozo>
companion_cube: also, note that sometimes, because of type subtleties, you need to write the "identity" function, as a pattern match that then reconstructs exactly the same value, but with a slightly different type (thing GADTs), in such cases, being able to detect that a switch returns exactly its argument, is a nice improvements, and you can't really write it differently because of the types
<adrien>
well, as theblatte said, the "as" construct should help for that case
<d_bot>
<EduardoRFS> that's exactly the case zozozo, for a lot of code in ocaml-migrate-types
<theblatte>
zozozo: yes!
<zozozo>
the advantage of the PR I linked is that it can trigger in cases where one cannot write code using "as"
<theblatte>
much sad when that happens
<d_bot>
<EduardoRFS> "as"?
<zozozo>
@EduardoRFS : `let f ((a, b) as pair) = pair`
<d_bot>
<EduardoRFS> oh but that works only for structural types
<companion_cube>
zozozo: good argument against GADTs ;)
<theblatte>
(in my case not phantom but "phantom" because it doesn't show up in some of the variants)
<companion_cube>
but it's the same constructors in this case.
<zozozo>
companion_cube: gadts are useful *sometimes*
<d_bot>
<EduardoRFS> I wonder if #8958 would be better as lambda layer
<d_bot>
<EduardoRFS> but tempting to rebase it ;/
<zozozo>
@EduardoRFS : the problem is that if you do that at lambda level, you miss out on situations where it happens after some inlining/simplification
<d_bot>
<EduardoRFS> yeah but you ensure same behavior between all backends
<zozozo>
(also, the code of lambda simplifications is quite a mess from what I hear)
<theblatte>
companion_cube: same constructors: yes, personally I would only care about preserving physical equality when the objects are actually equal but ymmv
<zozozo>
well.. there is now a pass specifically designed to implement optimizations, so why not use it ?
<theblatte>
I've seen several examples where it would have a material effect on perf
<d_bot>
<EduardoRFS> But the pass should not change behavior of code unless it provides a fallback, this is how I see most of it
<d_bot>
<EduardoRFS> maybe Sys.opaque_identity would ignore it
<d_bot>
<EduardoRFS> can we deprecate ==? That seems like a better idea overall
<companion_cube>
zozozo: because it only works for native?
<companion_cube>
ahahah
<companion_cube>
removing == kills perf for other programs
<theblatte>
#8958 ftw, I didn't know there'd been such a PR in flight for such a long time
<zozozo>
companion_cube: well, bytecode is pretty much meant to not care about performance, so from that point of view it's not unreasonable
<d_bot>
<EduardoRFS> not removing it, deprecating it, keep it under Obj.xx
<theblatte>
== is an important part of the language, not an extension
<zozozo>
the *good* solution would be to change the bytecode generation to use the result of flambda
<zozozo>
the semantics of "==" is largely not officially specified
<d_bot>
<EduardoRFS> NAH
<theblatte>
but not a bad idea to not give it such an easily-confused name :p eg use "phys_equal" instead
<zozozo>
and for any non-mutable record, there are next to no guarantees about "=="
<d_bot>
<EduardoRFS> unless we had a blazing fast flambda pass, bytecode is so fast right now
<d_bot>
<EduardoRFS> == is not exactly part of the language in many ways, and it's known to behave differently depending on the backend which should never happen for a specified feature of the language
<zozozo>
@EduardoRFS: are you talking about compilation time or runtime of the compild program ?
<d_bot>
<EduardoRFS> compilation time
<companion_cube>
zozozo: I wish I could agree
<companion_cube>
but some of us are stuck with bytecode
<d_bot>
<EduardoRFS> bytecode is slow in runtime, really slow
<companion_cube>
because that's the only official toplevel for now
<d_bot>
<EduardoRFS> but bytecode generated from flambda would still work with the toplevel
<zozozo>
companion_cube: yeah, but sometimes with others in my team, we talk about making it so that bytecode is generated after the flambda pass, which would solve all problems (if we can make it work)
<companion_cube>
sure
<companion_cube>
I mean in the future maybe we'll also have a JIT
<d_bot>
<EduardoRFS> there is any plan on deprecating closure middle end?
<companion_cube>
but for now it's not like there's a choice, and there's basically 0 optims on bytecode
<companion_cube>
which… ugh
<d_bot>
<dinosaure> it remmembers me one time when people compared ocsigenserver and http servers and used the bytecode version accidentally and say, OCaml is so bad
<companion_cube>
:D
<d_bot>
<EduardoRFS> D:
<companion_cube>
or even using dune without --profile=release
<companion_cube>
bye bye optims
<d_bot>
<EduardoRFS> TEZOS IS RUNNING WITHOUT PROFILE=RELEASE
<d_bot>
<EduardoRFS> even worse it is benchmarked without profile=release
<companion_cube>
hu, weirder
<zozozo>
well, if the switch is not using flambda, I don't think the difference is that important between the dev and release profiles
<companion_cube>
err, you still have a bit of cross module inlining, don't you?
<companion_cube>
with normal ocamlopt
<zozozo>
I'm not sure
<d_bot>
<EduardoRFS> yeah it makes difference, I benchmarked it, around 30% boost on some smart contracts
<d_bot>
<EduardoRFS> dune without profile=release runs under -opaque
<companion_cube>
I think it does, including for stuff like externals
<companion_cube>
exactly
<companion_cube>
--profile=release brings you back to normal behavior
<zozozo>
I think (but I'm not sure) the only thing cross-inlined would be externals, but those are in the .mlis so no need for cross-optimization actually
<d_bot>
<EduardoRFS> externals rely on the interface, so it doesn't depend on profile=release
<companion_cube>
zozozo: but the .cmx ?
<theblatte>
is profile=release different than passing -O3 to ocamlopt??
<zozozo>
ah, maybe the small functions that closure unconditionally inline are inliend cross-modules by vanilla ocamlopt
<d_bot>
<EduardoRFS> it is, because without profile=release you're under -opaque
<theblatte>
whaaaat
<theblatte>
:o
<d_bot>
<EduardoRFS> that's the only way to achieve blazing fast build speed
<companion_cube>
zozozo: the functions marked "inline" in .cmx files
<d_bot>
<EduardoRFS> yup, small functions like having `Module.equal` are not inlined and Module.equal a lot of times is literally a single cnstruction
<theblatte>
blazing fast = 6x slower than without -O3 ^^
<companion_cube>
that's what I was talking about
<zozozo>
companion_cube: indeed, ^^
<companion_cube>
so it can make a big difference :)
<companion_cube>
even without flambda
<theblatte>
ohhh, recently-ish we noticed marking some functor arguments as [@inline] made a big difference
<companion_cube>
:D
<zozozo>
that's not surprising
<theblatte>
is that sort of thing (adding @inline) not needed with flambda + release profile?
<theblatte>
or is that independent?
<companion_cube>
it still gives you better control
<zozozo>
iirc, flambda tries as much as possibvle to inline functor applicaiton that are at toplevel, so you shouldn't need the annotations in that particular case
<companion_cube>
do a lot of people use flambda1 in production?!
<zozozo>
companion_cube: jane street i guess ?
<companion_cube>
ahah maybe they have enough RAM
<zozozo>
also, the binary release of dolmen is now compiled with flambda, :D
<companion_cube>
I stopped using it years ago
<theblatte>
infer is 30% faster with flambda, so you bet
<companion_cube>
wow
<companion_cube>
well can't wait for flambda2
<companion_cube>
anyway, the point of --profile=release is to tell dune to not block optimizations, it doesn't enable new ones
<companion_cube>
for that you can use ocamlopt_flags
<d_bot>
<EduardoRFS> tezos is another 20% faster on flambda
<zozozo>
we're trying very hard on making it so that flambda2 is as fast as possible, but it's hard sometimes
<companion_cube>
zozozo: it's not just a question of "fast"
<companion_cube>
it's also "not gobble up RAM on bad cases"
<theblatte>
yes but I'm trying to understand if adding --profile=release will make a difference
<theblatte>
I'll try that
<companion_cube>
so, -p foo already switches to release mode
<companion_cube>
it's only if you use `dune build @all` and that kind of stuff that it matters
<zozozo>
companion_cube: right, can you send me (if you recall), the packages that were not working 'or taking ut too much RAM) ?
<companion_cube>
it makes compilation slower (removes -opaque) but enables optimization
<companion_cube>
zozozo: at least dose3
<companion_cube>
that was the blocker
<zozozo>
so that we can at least try and see what happens with flamdba2
<companion_cube>
and camlp4
<d_bot>
<EduardoRFS> even the new dose3?
<d_bot>
<EduardoRFS> dose3 6 changed quite a bit of stuff, even parmap they're using now
dwt_ has quit [Ping timeout: 265 seconds]
<theblatte>
companion_cube: we do "dune build infer.exe"
<companion_cube>
lol
<companion_cube>
yeah you need the flag
<companion_cube>
idk about dose3 6
<companion_cube>
I stopped trying flambda a while ago
<companion_cube>
using too much ram is a big problem imho
<d_bot>
<EduardoRFS> that seems weird, flambda reduces the number of allocations considerably
<companion_cube>
per module
<companion_cube>
with this you might also gain cross module
<theblatte>
ah I thought you meant too much ram used during compilation :)
<companion_cube>
that's what I meant yes
<companion_cube>
sorry
<companion_cube>
but theblatte, try the flag :p
<d_bot>
<EduardoRFS> yeah makes sense
<theblatte>
companion_cube: I am!!
<companion_cube>
and also, make sure .cmx are installed for all libraries
<d_bot>
<EduardoRFS> do we have an idea on what leads flambda to use so much memory?
<theblatte>
companion_cube: how?
<companion_cube>
well most should do it if they use dune
<d_bot>
<ggole> Is there any info on flambda2 floating around yet?
<companion_cube>
there's zozozo's brain
<companion_cube>
although it's not floating
<d_bot>
<dinosaure> technically, his brain is floating in his skull
<companion_cube>
he might be a robot
<companion_cube>
can't be sure
<d_bot>
<EduardoRFS> if he is doing flambda2 he is a robot
<zozozo>
right, I can try and answer questions about flambda2
<zozozo>
since I'm working on it, ^^
<companion_cube>
it'll be the default if it works well enough, right?
<zozozo>
that's the plan
<companion_cube>
🤞
<d_bot>
<ggole> Hmm, I'm not sure I know enough about it to ask good questions
<d_bot>
<ggole> Although maybe "what was not adequate about the first flambda design" is an obvious one
<theblatte>
companion_cube: ah, but actually we never use dune default profiles, we do --profile=opt (or dev). There's no -opaque in the build logs
<companion_cube>
ah, I see
<theblatte>
phew :)
<companion_cube>
(wait, there's a profile=opt??)
<theblatte>
you can name your profile however you want :p
swarm has joined #ocaml
<zozozo>
@ggole: basically, flambda2 now uses a CPS representation of source code, which is very useful (whereas flambda1 had an ANF representation iirc)
<theblatte>
then we have (env (opt (ocamlopt_flags (:standard -O3))), etc.
<theblatte>
maybe we should have -opaque for profile=dev though!
<d_bot>
<EduardoRFS> wondering, when the optimization mentioned in 8958 may be triggered after inlining?
<d_bot>
<EduardoRFS> It would be weird if flambda allocated two identical temporary blocks
<d_bot>
<Drup> I also have a question on flambda 2.0
<d_bot>
<ggole> @guigui CPS is an interesting direction. It used to be the IL style of choice, but seems to have gone right out of favour.
<zozozo>
Drup: fire away, ^^
<d_bot>
<Drup> Do you (the flambda team) intend to keep working on it instead of instantly decide to shoot the for moon and work on flambda 3.0 ?
<companion_cube>
lolol
<companion_cube>
I could say the same of ppx
<zozozo>
Drup: the plan is to continue working on flambda2
<d_bot>
<ggole> Although people who use ANF seem to have discovered the need for very continuation-like constructs with join points
<zozozo>
basically, doing flambda1 gave the team (note that this was before I joined) some insights about how to do and not to do some things
<d_bot>
<Drup> (you don't have to answer it, it's friday evening, and I know you don't really have a sway on this all that much)
<zozozo>
Drup: indeed, but I'm right now in a conference call with Pierre so I can ask him, ^^
<d_bot>
<Drup> Say hello from me :p
<zozozo>
Drup: he says hello to you too
<theblatte>
hi pchambart :)
<companion_cube>
coucou to him
<d_bot>
<Drup> but yeah, flambda in general is a bit moonshot infused sometimes. I understand why (it's much more fun to work on "The Perfect IR") but it's a bit infuriating.
<companion_cube>
like multicore has been for a while, too
<companion_cube>
or even opam 2.1
<companion_cube>
seems like a common theme in OCaml :p
<theblatte>
companion_cube: alright so something good still came out of that: compiling with -opaqe turns a 50s full build into a 40s one \o/ and I assume it's even better for incremental build?
<zozozo>
yeah, but now with flambda2 we should have a good enough IR to do what we want and need
dhil has quit [Ping timeout: 252 seconds]
<companion_cube>
theblatte: err it's faster builds, but slower code, yes
<d_bot>
<Drup> let's hope so
<theblatte>
companion_cube: it's for "dev" builds
<companion_cube>
then yes
<companion_cube>
with -opaque you have fully separate compilation
<theblatte>
I was wondering why dune was doing so much work on incremental compilation ^^
<theblatte>
thanks!
<d_bot>
<Drup> (I though dune already added `-opaque` for dev builds)
<d_bot>
<ggole> @guigui what was difficult before that's easy now?
<companion_cube>
seems like theblatte has his own profiles
<companion_cube>
zozozo: so in CPS, do you have 2 "kinds" of function calls? normal and continuations?
<companion_cube>
to make sure there's no new closures?
<d_bot>
<Drup> That doesn't seem very smart if those are less though-out than the normal ones :3
<theblatte>
dune profiles have... weird defaults
<theblatte>
fair enough :p
<zozozo>
companion_cube: continuations in flambda2 are more along the lines of static jumps
<companion_cube>
cool
<companion_cube>
zozozo: please stop delaying the PR for ocaml.org
<companion_cube>
plz
<zozozo>
sorry, ^^
<companion_cube>
why does a PR against a fracking website take a full week to be merged anyway
<zozozo>
right, that's a problem
<companion_cube>
if you want the website to go stale because no one opens a PR to update it, that's the best way to go
<octachron>
companion_cube, because there is noone clearly responsible? My commit right is normally mostly for OCaml releases
<companion_cube>
is Anil trying to do too many things? :p
<companion_cube>
definitely not blaming you octachron
<companion_cube>
just annoyed that this, which should have taken literally 5 minutes, is taking a week
<theblatte>
interesting, -opaque seems to make no difference for incremental compilation, only for full compilation
<companion_cube>
during which the information on the website is misleading
<companion_cube>
theblatte: try modifying a file deep in the dep graph, but only the implementation, not the interface
<theblatte>
that's what I tried
<companion_cube>
hu
<theblatte>
humm, there's a leftover -opaque in the logs, my experiment must have gone wrong, sorry, digging in further
<d_bot>
<EduardoRFS> theblatte: also opaque allows to build strictly against cmi which leads to better parallelism if you're using mli well
<d_bot>
<EduardoRFS> so opaque should definitely matter for incremental as without it you need to rebuilt the full tree if any module changes
<d_bot>
<EduardoRFS> maybe dune doesn't have this implemented?
<d_bot>
<EduardoRFS> @rgrinberg any idea here?
<theblatte>
I think because we use the "dev" name for our profile -opaque was already being passed!
<theblatte>
even though we override (flags ...)
<theblatte>
but not ocamlopt_flags
<octachron>
companion_cube, anyway my week ended 15 minutes ago, so the PR is merged.
<theblatte>
and we still see a win for the full build by forcing -opaque because it passes it in a bunch of places where dune doesn't by default
<theblatte>
looks like that's when building the entire libraries' .cmx
<adrien>
octachron: thanks :)
<theblatte>
so, hmmm, *shrug*
<companion_cube>
octachron: 😂 thank you
<companion_cube>
and the website is updated already, nice
<companion_cube>
didn't we discuss it here recently?
<companion_cube>
perhaps about bitvectors
mbuf has quit [Quit: Leaving]
<olle>
oooooh
olle has quit [Ping timeout: 272 seconds]
noisy-bot has quit [Ping timeout: 264 seconds]
bartholin has quit [Quit: Leaving]
Haudegen has quit [Quit: Bin weg.]
swarm has quit [Ping timeout: 245 seconds]
labor[m] has quit [Quit: node-irc says goodbye]
krnkktz has quit [Quit: node-irc says goodbye]
radiopotin[m] has quit [Quit: node-irc says goodbye]
fluxm has quit [Quit: node-irc says goodbye]
Sumera[m] has quit [Quit: node-irc says goodbye]
smondet[m] has quit [Quit: node-irc says goodbye]
labor[m] has joined #ocaml
krnkktz has joined #ocaml
fluxm has joined #ocaml
Sumera[m] has joined #ocaml
smondet[m] has joined #ocaml
radiopotin[m] has joined #ocaml
mikess has joined #ocaml
motherfsck has quit [Quit: quit]
motherfsck has joined #ocaml
swarm has joined #ocaml
Haudegen has joined #ocaml
zebrag has quit [Ping timeout: 245 seconds]
<zozozo>
@ggole : sorry for the delay, basically, control flow manipulation is much easier in cps form, also inlining a function's body is tricky to do in ANF (and can be exponential in the worst case if you need to ensure the result if in strict ANF)
zebrag has joined #ocaml
<companion_cube>
coudl you post a snippet of a tiny CPS AST? :p
<companion_cube>
sth where we could see let, application, and like a primitive like + ?
<zozozo>
sure
<companion_cube>
👍
<companion_cube>
I want to see how the continuations are represented
zebrag has quit [Client Quit]
zebrag has joined #ocaml
gareppa has joined #ocaml
gareppa has quit [Remote host closed the connection]
<zozozo>
basically, a continuation is a (unique) integer
<zozozo>
companion_cube: ^
<companion_cube>
so, apply_cont is where you jump
<zozozo>
yup
<zozozo>
also, after a function call (i.e. Apply_expr), you call the given continuation with the return value of the function call
<companion_cube>
and why is there 2 let?
<companion_cube>
yeah
<companion_cube>
and you call the function on already computed arguments
<zozozo>
you can bind continuations, and regular expressions
<companion_cube>
hmmm
<companion_cube>
I mean, Let_expr makes sense, it's a local definition, ok
<zozozo>
yup
<companion_cube>
but what's the "handler" in Let_cont?
<zozozo>
the code of the continuation
<companion_cube>
oh shit ok
<zozozo>
let_cont k args = handler in body
<companion_cube>
nice
<zozozo>
note that continuations are local to a function's body and cannot escape
<companion_cube>
so patmatch could also create such expressions, for example
mikess has left #ocaml [#ocaml]
<zozozo>
since continuations are not regular value (i.e. simples or named)
<companion_cube>
with explicit sharing and everything
<zozozo>
yes
<companion_cube>
(I imagine switch could also have a default case)
<zozozo>
in this case no, the switch has no default case
<zozozo>
it simplifies some things
<zozozo>
but in theory it could
<companion_cube>
even in flambda2?
<companion_cube>
I guess since you can share continuations, it's ok
<zozozo>
it's just that having no default case means the code is much more regular
<zozozo>
you can fold on the arms of the switch
<zozozo>
and not have to specifically treat the default case
<companion_cube>
heh, fair enough
<companion_cube>
I think the insight that continuations are not values, is sth I didn't realize
<companion_cube>
so thank you! :)
<zozozo>
no problem, ^^
<d_bot>
<ggole> zozozo: hmm, that's actually pretty close to what I expected. Thanks for taking the time to write it up.
<d_bot>
<ggole> When I tried CPS ILs I found it difficult to perform what should be simple transformations like commuting `case` expressions, but perhaps my approach was too naive.
<zozozo>
@ggole : well, commuting switches would be quite complicated indeed (and isn't done currently in flambda2)
<d_bot>
<ggole> That's one benefit of a more lambda-calculus like IL, it's quite easy to do context-directed optimisations (of which commuting is probably the most significant)
<zozozo>
yeah, but then again, I don't think commuting is really something that we want to do in flambda2
<d_bot>
<ggole> But there are downsides with scope
<d_bot>
<colin> will flambda2 carry through to faithful CPS compilation or what
<zozozo>
@colin : I'm not sure what you mean ?
<d_bot>
<ggole> SML/NJ style CPS all the way? Seems unlikely.
<d_bot>
<colin> I've seen compilers that use CPS as an IR yet blast to something slightly different to compile to something that still uses a runtime stack
<d_bot>
<colin> Yeah, I don't think SML/NJ or MLton can be described as using CPS to much of an extent nowadays tbh
<d_bot>
<ggole> I thought SML/NJ still used that for their `Cont` implementation
<zozozo>
ah well, the flambda IR is in CPS, but there will be no change to the other IR of the compiler, so that's that, ^^
<d_bot>
<colin> is the Apply_cont constructor in this cps.ml file representing "contificated"/static continuations?
<zozozo>
yeah, it represents static continuations bound previously by a Let_cont
<d_bot>
<colin> interesting, I've only ever seen the IR presented in Appel's CwC book
<d_bot>
<ggole> There's a nice paper on an CPS IR a bit like this that you might be interested in
<d_bot>
<colin> is it by Kennedy
<d_bot>
<ggole> Yeah
<d_bot>
<colin> yeah, I've seen that as well actually, it's the one most people seem to go with I think
<d_bot>
<ggole> Makes a lot of sense if you aren't supporting call/cc
<companion_cube>
zozozo: what comes after flambda? something with a control flow graph already?
<zozozo>
companion_cube: after flambda, it's cmm
<d_bot>
<colin> been a while since I've toyed with CPSing compilers because very few go the full mile with the whole "no runtime stack" - they go the chicken route and use it as a GC nursery because they can't get their C compiler to do the strict (tail) call -> jumps that CPS requires and LLVM certainly can't handle CPS so you're just stuck writing your own back-end each time
<zozozo>
(fun factoid: cmm quite literraly means C minus minus, :p )
<d_bot>
<ggole> If the continuations are second class as in this example, then you can probably linearise to SSA fairly successfully
<companion_cube>
hmm so cmm still has function calls and expressions, but no types, right?
<d_bot>
<colin> I just think going from ANF -> LLVM (SSA) is simpler
<d_bot>
<ggole> Although there's the usual complications of closure conversion and whatnot because LLVM is first order
<d_bot>
<colin> Oleg seems to have some strong views on actually doing faithful compilation of CPS as well, along the lines of "whole-program continuations are never useful" and uh "the garbage collector doesn't like this" etc. paraphrasing (perhaps inaccurately) here
<zozozo>
companion_cube: cmm has very minimal types (basically it says whether a value can/should be scanned)
<d_bot>
<ggole> Well, CPS as a compiler IL is a different storly to exposing continuations reified as functions
<companion_cube>
yeah, that's not typing ;)
<companion_cube>
but there you eliminate continuations again, right? towards some sort of static jump, like local exceptions?
<zozozo>
yup
<zozozo>
cmm has static jumps and flambda continuations maps perfectly to that
<zozozo>
(ofc continuations that are used exactly once can be inlined)
<companion_cube>
right
<d_bot>
<ggole> Either a return or a jump
<d_bot>
<colin> this discussion is urging me to actually go and read Shivers' k-CFA stuff since I've always just avoided any real detail/proposed benefit of program transformations in CPS
<companion_cube>
you can still use static jumps for patmathc and stuff
<d_bot>
<ggole> Or maybe an exception handler if double-barrelled CPS
<zozozo>
flambda actually has double-barrelled CPS
<zozozo>
(flambda2)
<d_bot>
<ggole> That makes sense, rather than duplicating all of the control constructs
<d_bot>
<ggole> And optims on them
<d_bot>
<colin> what's double-barrelled, just doing the CPS twice?
<companion_cube>
wait
<companion_cube>
does the second handler also work for effects?
<companion_cube>
or wolud there be a third handler?
<d_bot>
<ggole> Along with the usual return continuation you pass another continuation which is the error/exn path
<d_bot>
<colin> ah
<zozozo>
companion_cube: effects as in algebraic effects (cf multicore) ?
<companion_cube>
yes
<companion_cube>
runtime effects anyway
<companion_cube>
the one shot continuations :)
vicfred has joined #ocaml
<zozozo>
that's a very good question
<companion_cube>
I think exceptions will just be another effect, except in the type system, so you can probably only have 2
<d_bot>
<colin> who funds OCamlPro? INRIA? Jane Street? or is it its own company
<d_bot>
<Christophe> I have a question about the change log of 4.13. The change "type check x |> f and f @@ x as (f x) ` is marked as breaking change. What are the consequences of that change actually? (sorry for interrupting a very interesting conversation)
<companion_cube>
it might change a few things in a subtle way
<companion_cube>
like `f x` can be `f ?a ?b x`
<companion_cube>
if f has optional arguments
<zozozo>
@colin : OCamlPro is its own company, and janestreet is one client of ocamlpro
<d_bot>
<colin> Ah, I see, I was looking at compiler jobs at Jane Street (wishful thinking) but now they don't seem like they'd be as interesting as this flambda2 stuff (unless there's some ties between both companies)
<d_bot>
<Christophe> Ah yes, I didn't think of optional arguments, thanks!
<companion_cube>
aren't they funding flambda2? :D
<zozozo>
@colin : well, the work on flambda2 is funded by JaneStreet, ^^
noisy-bot has joined #ocaml
<d_bot>
<EduardoRFS> type check of `x |> f` as `f x` is something I was not expecting but I really appreciate
<d_bot>
<EduardoRFS> now we need to type check `let x = y` in the opposite order
<d_bot>
<EduardoRFS> can we implement this kind of subtyping or would it be unsound?
<d_bot>
<EduardoRFS> ```ocaml
<d_bot>
<EduardoRFS> module X : sig
<d_bot>
<EduardoRFS> type 'a t = private 'a
<d_bot>
<EduardoRFS> end = struct
<d_bot>
<EduardoRFS> type 'a t = 'a
<d_bot>
<EduardoRFS> end
<d_bot>
<EduardoRFS> let add (a : int X.t) (b : int) = a + b
<d_bot>
<EduardoRFS> ```
noisy-bot has quit [Ping timeout: 245 seconds]
<d_bot>
<octachron> This is already implemented, with an explicit coercion as usual: `let add a b = (a:int X.t:>int) + b`
Anarchos has joined #ocaml
waleee has joined #ocaml
rak has quit [Quit: Segmentation fault (core dumped)]
rak has joined #ocaml
Anarchos has quit [Quit: Vision[0.10.3]: i've been blurred!]
romildo has joined #ocaml
romildo has left #ocaml [Leaving]
wonko has quit [Ping timeout: 272 seconds]
dhil has joined #ocaml
dhil has quit [Quit: Leaving]
swarm has quit [Ping timeout: 264 seconds]
waleee has quit [Ping timeout: 244 seconds]
waleee has joined #ocaml
dhil has joined #ocaml
Tuplanolla has joined #ocaml
hackinghorn has joined #ocaml
<hackinghorn>
hi
<hackinghorn>
how do I run commands like ls for linux in ocaml?