rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
daimrod1 has quit [Ping timeout: 260 seconds]
daimrod1 has joined #ocaml
gahr_ has joined #ocaml
gahr has quit [Read error: Connection reset by peer]
micro has quit [Ping timeout: 260 seconds]
micro has joined #ocaml
jao has quit [Ping timeout: 252 seconds]
ado has joined #ocaml
bartholin has joined #ocaml
grobe0ba has quit [Ping timeout: 260 seconds]
zozozo has quit [Quit: WeeChat 2.9]
zozozo has joined #ocaml
grobe0ba has joined #ocaml
Serpent7776 has joined #ocaml
troydm has joined #ocaml
gahr has joined #ocaml
gahr_ has quit [Ping timeout: 260 seconds]
micro has quit [Ping timeout: 260 seconds]
micro has joined #ocaml
daimrod1 has quit [Ping timeout: 252 seconds]
daimrod1 has joined #ocaml
Tuplanolla has joined #ocaml
ado has quit [Quit: Connection closed for inactivity]
CalimeroTeknik has quit [Changing host]
CalimeroTeknik has joined #ocaml
grobe0ba has quit [Ping timeout: 260 seconds]
grobe0ba has joined #ocaml
Haudegen has joined #ocaml
jedb_ has joined #ocaml
jedb has quit [Ping timeout: 255 seconds]
<ski>
energizer : the ML interactors tend to (afaik) not support redefinition (rather than defining anew, possibly shadowing the old definition), and also not have condition handlers that allow you to have the expression in question compute to a then-user-provided value (expression), or retry the operation, possibly after live-/hot- swapping the implementation of something, like Lisp interactors often do (possibly
<ski>
some Prolog ones as well ?)
waleee has joined #ocaml
<ski>
(e.g. with SLIME, you can attach to a running Common Lisp process (there's also some versions for a few other languages, like some Schemes, i think Clojure, perhaps also some non-SExpy languages), and live-debug and live-edit it)
<ski>
as for why, i think partly it's differing culture (and lack of experience/familiarity with such systems) .. but quite probably also due to it being less clear how to integrate that well with static types, at least for several of those kind of things
<ski>
some SMLs (e.g. SML/NJ (`exportML',`exportFn')) have support for image-based interaction, where you can save the running state of a process into a file, and resume it later (can also be used to clone a process, or migrate it) .. like Lisps commonly allow (and Smalltalk systems, and Prologs)
<hannes>
ski: but with OCaml + bytecode + dynlink that should be possible with OCaml (+emacs integration) as well, no?
<ski>
to some extent at least, possibly
<ski>
(although i'm not aware of any implementation .. but i haven't looked, either)
<ski>
would that also support exchanging individual function definitions in a module ? or only whole compilation units (dynamically loaded) ?
<hannes>
ski: AFAIU the loading/unloading is done on a module basis
<hannes>
and I have barely any experience with that
<ski>
i know Erlang only supports hot-swapping whole modules (and the process will continue to run inside the old module code, which is not discarded yet, until it calls with an explicit module qualification, which is typically done when sending the process a "hand-off to new version" message, so that it can pass its state, and the new code module can receive that, convert to its internal format, and continue from
<ski>
where things left off)
<ski>
(although, iirc, it can only have at most two versions of a module loaded at the same time. so you'd better migrate all old processes, before you update yet again)
<ski>
hannes : it would still probably be a useful thing to try and see if one could get working
<hannes>
ski: yes, would be highly appreciated
<ski>
the main problem would be when you change the types, i thikn
<ski>
(Prologs routinely have "retry" in the (procedural, as opposed to declarative) debugger, allowing you to retry an operation again .. very useful, if you'er skipping calls left and right until you get an unexpected result, at which point you want to revisit that call in more detail .. of course, it doesn't undo side-effects, though, just variable instantiations, and the control state)
<ski>
(Mercury, which doesn't have an interactor per se, apart from its (procedural) debugger (which can be used, at least somewhat, as an interactor) (there was also a declarative one, that instead asked the user about whether results of intermediate operations were expected, but often could exploit data dependencies to avoid asking about calls that didn't contribute to a mismatch in expectation), does allow even
<ski>
retry of I/O, through "I/O tabling". what it does is generate a sequence of IDs to track the I/O state that's threaded through, and record the results for each primitive I/O operation. then, on "retry", those recorded (tabled) results are just replayed, rather than actually executed anew, until it reaches "present time" again)