cantstanya has quit [Remote host closed the connection]
cantstanya has joined #ocaml
amiloradovsky has quit [Quit: amiloradovsky]
amiloradovsky has joined #ocaml
olle has quit [Ping timeout: 240 seconds]
olle_ has quit [Ping timeout: 246 seconds]
olle has joined #ocaml
Jeanne-Kamikaze has joined #ocaml
GuerrillaMonkey has joined #ocaml
FreeBirdLjj has joined #ocaml
Jeanne-Kamikaze has quit [Ping timeout: 240 seconds]
FreeBirdLjj has quit [Ping timeout: 256 seconds]
Jeanne-Kamikaze has joined #ocaml
GuerrillaMonkey has quit [Ping timeout: 256 seconds]
Tuplanolla has quit [Quit: Leaving.]
amiloradovsky has quit [Remote host closed the connection]
Haudegen has quit [Ping timeout: 260 seconds]
madroach has joined #ocaml
madroach_ has quit [Ping timeout: 256 seconds]
mfp has quit [Ping timeout: 240 seconds]
nicoo has quit [Ping timeout: 240 seconds]
andreas303 has quit [Ping timeout: 240 seconds]
nicoo has joined #ocaml
andreas303 has joined #ocaml
GuerrillaMonkey has joined #ocaml
Jeanne-Kamikaze has quit [Ping timeout: 246 seconds]
raver has quit [Ping timeout: 256 seconds]
Jeanne-Kamikaze has joined #ocaml
GuerrillaMonkey has quit [Ping timeout: 240 seconds]
raver has joined #ocaml
GuerrillaMonkey has joined #ocaml
nicoo has quit [Remote host closed the connection]
Jeanne-Kamikaze has quit [Ping timeout: 260 seconds]
nicoo has joined #ocaml
GuerrillaMonkey has quit [Quit: Leaving]
Jeanne-Kamikaze has joined #ocaml
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
zebrag has quit [Remote host closed the connection]
zebrag has joined #ocaml
Jeanne-Kamikaze has quit [Quit: Leaving]
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
sleepydog has quit [Ping timeout: 246 seconds]
zebrag has quit [Remote host closed the connection]
dborisog has joined #ocaml
waleee-cl has quit [Quit: Connection closed for inactivity]
decentpenguin has quit [Quit: ZNC crashed or something]
decentpenguin has joined #ocaml
narimiran has joined #ocaml
adrien has quit [Ping timeout: 256 seconds]
andreas303 has quit [Quit: andreas303]
andreas303 has joined #ocaml
adrien has joined #ocaml
dborisog has quit [Ping timeout: 272 seconds]
tizoc has quit [Quit: Coyote finally caught me]
tizoc has joined #ocaml
andreas303 has quit [Remote host closed the connection]
andreas303 has joined #ocaml
bartholin has joined #ocaml
Tuplanolla has joined #ocaml
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
cantstanya has quit [Remote host closed the connection]
cantstanya has joined #ocaml
vicfred has quit [Quit: Leaving]
cantstanya has quit [Ping timeout: 240 seconds]
cantstanya has joined #ocaml
olle_ has joined #ocaml
<olle_>
oh, xavier leroy is active on the forum?
mfp has joined #ocaml
steenuil has quit [Quit: Leaving]
steenuil has joined #ocaml
tane has joined #ocaml
olle_ has quit [Ping timeout: 246 seconds]
Haudegen has joined #ocaml
olle_ has joined #ocaml
nullcone has quit [Quit: Connection closed for inactivity]
dborisog has joined #ocaml
dborisog has quit [Ping timeout: 246 seconds]
waleee-cl has joined #ocaml
jlr has joined #ocaml
dborisog has joined #ocaml
Anarchos has joined #ocaml
jlr has quit [Ping timeout: 260 seconds]
Anarchos has quit [Quit: Vision[0.10.3]: i've been blurred!]
<olle_>
how much can you reasonably get done with dynamic memory allocation? that is, setting upper bounds for all computations.
<companion_cube>
Nothing. OCaml always needs a ton of allocations
<companion_cube>
The best you can hope for is that most allocations are short lived and stay in the minor heap
<olle_>
companion_cube: no, I mean in general.
<companion_cube>
Complicated topic, I think
<olle_>
sure
<olle_>
you end of doing your own memory pooling
<companion_cube>
Embedded software typically doesn't allocate, but otherwise if you want to deal with arbitrary inputs you want to allocate
<olle_>
you can still set an upper bound
<olle_>
and allocate a buffer on the stack
<companion_cube>
Maybe in C in some restricted cases
<olle_>
looks like it
<olle_>
"I did it once in an embedded environment where we were writing "super safe" code for biomedical machines. Malloc()s were explicitly forbidden, partly for the resources limits and for the unexpected behavior you can get from dynamic memory"
<companion_cube>
Not in any gc'd language I know of
<olle_>
from stackoverflow
<companion_cube>
Sure, that's embedded
<companion_cube>
Also it's for a specific medical machine, sizes are known
<olle_>
there's no gc language that mix gc with stack allocations?
<d_bot>
<ggole> There are a few
<companion_cube>
There's D and Go at least I think
<companion_cube>
But truly, if you use such a language, allocating shouldn't be forbidden
<zozozo>
at least for ocaml, flambda implements some kind of partial solution for stack-allocation-like behaviour, which it call unboxing, which basically splits an allocated blocks into its fields, each of which will go on the stack
<companion_cube>
What is even the point? Limiting yourself to a few MB of stack instead of a large heap?
<qwr>
Nim also mixes
<d_bot>
<ggole> A sharp bound on the cost of deallocation is nice
<olle_>
zozozo: yes, but i'm not talking about compiler optimizations, but explicit behaviour by the programmer. "do gc on this, but this can be stack allocated."
<zozozo>
olle_: yeah, but if you start on that road, you'll very likely to wuickly get insanely long complicated specs, which would probably make the entry barrier for ocaml higher I guess
<zozozo>
and complicate the life of compiler devs, XD
<olle_>
zozozo: really?
<companion_cube>
ggole: you could have explicit malloc I think
<olle_>
not talking about ocaml specificly, but languages in general :d
<companion_cube>
Less bad than forcing yourself to use the stack
<qwr>
it's actually a choice of abstactin level of the language/code - what decisions the programmer has to make
<qwr>
abstraction*
<companion_cube>
olle_: that's generally the point of "value types" when they're available
<companion_cube>
Not allocated separately
<Armael>
isn't that what rust gives you
<companion_cube>
But it's hard on the runtime
<qwr>
Rust actually forces you to do manual memory management, although a safe and nicer one than for example C
<olle_>
companion_cube: hm. swift does this, it seems. with structs.
<qwr>
a bit buggy AFAIK, but otherwise seems quite real
<qwr>
the lifetime rules in nim related to stack allocations kind of remind an ad hock subset of rusts ownership model
<Drup>
a lot of rules in nim seems like ad-hock subset of a properly sought-out language.
<olle>
qwr: hm
<olle>
why would they call it procedures instead of functions? bah
<olle>
things like that sometimes makes it hard for me to take things seriously
webshinra has quit [Read error: Connection reset by peer]
webshinra has joined #ocaml
olle_ has joined #ocaml
hnOsmium0001 has joined #ocaml
Jesin has quit [Quit: Leaving]
jlr has joined #ocaml
<companion_cube>
Drup: thought-out? :p
<companion_cube>
maybe it's more ad-hoc, but they als make a lot of pragmatic choices
<companion_cube>
better interop with C, compile time evaluation, macros
<companion_cube>
stuff we could use 🙄
<olle_>
nim?
<companion_cube>
yeah it has some good stuff
<companion_cube>
it mostly lacks a really strong compiler I think
<companion_cube>
s/strong/robust
<Drup>
last time I looked, the implementation of ADT was just all over the place
<Drup>
as in "I just saw a 5 minutes demo of ADTs and cobbled together what I think is an implementation of it"
<companion_cube>
yeah I agree, the ADT are not there
<companion_cube>
main reason I didn't pursue
<companion_cube>
(the guy thinks there's no real need to check that fields of the right variant are accessed… 🙄)
<Drup>
the fact that such a relatively simple feature, when implemented, is half botched, doesn't really inspire confident in the language.
<olle_>
One-man team?
<companion_cube>
I'm not sure if pascal checks that kind of stuff
<companion_cube>
and nim is definitely a pascal language disguised as python
<Drup>
in general, the type system felt ... well, "amateur" might be one word
oni_on_ion has joined #ocaml
oni-on-ion has quit [Ping timeout: 260 seconds]
Jesin has joined #ocaml
<companion_cube>
it seemed quite pascal-y to me, again (+ generics)
<companion_cube>
nothing wrong with that
<companion_cube>
I do think crystal will be nicer as a mainstream-ish compiled language… if they ever reach 1.0
<olle_>
"Nim was created to be a language as fast as C, as expressive as Python, and as extensible as Lisp."
<olle_>
Ambitious mission statement ^^
* qwr
has written a bit nim to try it, it is generally more low-level than, for example ocaml, and mostly imperative - yeah, like pascal well done
<olle_>
how can it be low-level if it is gc? oO
<companion_cube>
it's not necessarily GC'd
<companion_cube>
it can be refcounted (favored version actually) and you can use manual allocation
<olle_>
"--gc:none. No memory management strategy nor a garbage collector"
<olle_>
hehe
<olle_>
super fast!
<companion_cube>
there's Arc which is like swift (I think), and Orc which is more experimental but has multi-thread compatible cycle detection
<companion_cube>
olle_: well you can still use malloc
<companion_cube>
it has unmanaged pointers
<companion_cube>
which are easier to do if you don't also have a tracing GC
<qwr>
they plan to make orc (refcount with cycle detector) a future default
<olle_>
hm
olle_ has quit [Ping timeout: 256 seconds]
mxns has joined #ocaml
mxns has quit [Ping timeout: 268 seconds]
Jeanne-Kamikaze has joined #ocaml
dborisog has quit [Ping timeout: 264 seconds]
olle_ has joined #ocaml
jlr has quit [Ping timeout: 260 seconds]
narimiran has quit [Ping timeout: 256 seconds]
<olle_>
"Rust stack-allocates by default"
<olle_>
:d
flux67 has joined #ocaml
<flux67>
how do you use List.fold in base?
<flux67>
i tried: List.fold [1,2,3] 0 (+);;
<flux67>
but i'm getting an error
<flux67>
the type is `- : 'a list -> init:'accum -> f:('accum -> 'a -> 'accum) -> 'accum = <fun>` so i don't know what i'm doing wrong
<zozozo>
flux67: List.fold [1;2;3] ~init:0 ~f:(+) , note the ; (and not ',') in the list tu build a list with multiple elemnts and not a list of triplets
<flux67>
sigh, this error again, i wonder if i'll ever learn >_<
<flux67>
haha thanks
<flux67>
why won't it work if the arguments aren't labeled?
<zozozo>
hm.. well in case of a full application, the labels should be omittable (modulo whether the relevant warning is activate and whether warnings as errors is also activated, which are both the defaults using dune iirc)
<flux67>
and is there an easy way to do product? if i replace (+) by (*) the (*) operator acts like a comment :)
<zozozo>
flux67: use ( * )
<zozozo>
you need the spaces for the parser to not confuse it with a comment
<flux67>
i see
<flux67>
wow, just spent 30 minutes trying to debug for this :D
<zozozo>
^^
<flux67>
i just started using ocaml, but to me it's such a strange language
<zozozo>
where do you come from (in terms of programming languages) ?
<flux67>
but even from a haskell perspective i find some of the quirks a bit weird
<flux67>
like ; and +. and =
<zozozo>
tbh, I extremely rarely use ; nowadays (oftentims I prefeer just writing let () = ... in because it helps not break the flow of the code)
<flux67>
i also think it's a little weird that base has different syntax than the standard library
<flux67>
like fold_left has a different order of arguments
<flux67>
is there some explanation for that?
<olle_>
relevant xkcd:
<olle_>
standards etc
<zozozo>
ofc, ^^
dhil has joined #ocaml
<zozozo>
well more than that, Base (and Core iirc) has chosen to make use of labelled arguments more than the stdlib
<olle_>
for even more fun, ask why std lib use exceptions for control flow :)
<zozozo>
and with that, you can re-order arguments more easily when you have full applications
<companion_cube>
flux67: base and core come from janestreet, a rich company that uses OCaml a lot, so they have their own foundations
<zozozo>
olle_: well it's simple: it's more efficient !
<olle_>
pfff
<flux67>
is there some way to fix my .merlin to stop showing stdlib's types and start using base's types?
<companion_cube>
they've had decades to develop their own internal OCaml culture
<flux67>
where does the efficiency comes from here?
<zozozo>
flux67: if you use dune to build your project, dune will generate correct merlin files (which is useful)
<companion_cube>
flux67: a bit less allocations in general
<flux67>
zozozo: hmm, so I have an "open! Base", and Base.List.fold_left gives a right annotation but List.fold_left doesn't
<flux67>
even though i am using dune
<zozozo>
that's strange...
<zozozo>
have you tried building your project (dune build @check), and re-start your editor (just in case, to ensure it picks up the latest .merlin files) ?
<flux67>
yeah
<flux67>
well i just did a dune runtest
<flux67>
and the merlin file did have `B /home/user/.opam/default/lib/base`
<flux67>
which i assume loads base
<zozozo>
hm... might be an issue with merlin I guess ?
<flux67>
i did get this error: ppx_inline_test: extension is disabled because the tests would be ignored(the build system didn't pass -inline-test-lib)
<flux67>
but well, i'm not sure what it means or how to fix it
<flux67>
maybe i need to include something in the dune?
mxns has joined #ocaml
<zozozo>
possibly, though I haven't used inline tests much so I can't tell ohh my head
<zozozo>
*off the top of my head
<zozozo>
anyway, I've got to go sleep, hope you manage to solve your problems, ^^