IRC channel logs

2016-10-24.log

back to list of logs

***micro` is now known as Guest38587
***siel_ is now known as siel
<sapientech>hi all, do guiles numeric procedures use ad-hoc or parametric polymorphism, or does c handle type coersion?
<sapientech>or if none of that, how are they implemented :)
<mark_weaver>the core functions are defined in libguile/numbers.c. see scm_sum for an example.
<mark_weaver>the C functions understand a certain fixed set of core numeric representations, and handle those internally. otherwise, it is dispatched to GOOPS to handle user-defined numeric types.
<mark_weaver>they use ad-hoc polymorphism
<mark_weaver>at the C level, all scheme values have the same type: SCM
<mark_weaver>so C is not handling our type coercion
<sapientech>mark_weaver: thanks for the response! cool to know that goops is involved here, since i was suspecting it could be used, and makes sense that we have ad-hoc in c
<ArneBab_>ijp: :) - that’s true, but still does not remove the advantage I see in having Guile be a Scheme. Yes, there are Schemes for which only a subset of my Guile skills is useful, and the performance behavior is surely different, but when switching from those Schemes to Guile, I could keep most of my skills.
<ArneBab_>ijp: what I wouldn’t want is to have Guile be *only* a Scheme. It should be free to move beyond the Scheme standard (which it obviously is already).
<spk121>It is the 9th anniversary of the 1st release of the ncurses binding. I really should finish that someday. It has been 90% done for a long time. :)
<amz3>hélllo :)
<random-nick>what has less overhead? FFI bindings or C bindings?
<random-nick>I'm guessing FFI bindinga
<paroneayea>hello, *
<OrangeShark>hello paroneayea
<amz3`>random-nick: FFI is prefered, but I don't know which has less overhead
<amz3`>o/
***C_Keen is now known as C-Keen
***berndj-blackout is now known as berndj
***Guest38587 is now known as micro`
<davexunit>wingo: serializable continuations. I hear they are possible in other languages (I think Stackless Python is one example), are they possible in guile? I'm not sure if it's a good thing to want or not.
<davexunit>thinking about this for coroutine-based game scripting. in the context of video games, the classic design is the hand-written state machine with an 'update' function that advances the simulation. here it is trivial to save the game state at any arbitrary point and reload it later since there is no state that has been closed over. not so with coroutines.
<paroneayea>davexunit: seems like it would be tricky if you have any C involved in the mix...
<davexunit>delimited continuations cannot capture C stack frames
<paroneayea>davexunit: oh right that's true
<davexunit>so I think we're OK there.
<davexunit>I'm asking because I really don't understand what would be involved here. maybe it's not worth it at all.
<paroneayea>davexunit: I linked something recently about something done by Jonathan Rees and ?? with a decentralized scheme OS
<paroneayea>and it had continuations
<paroneayea>coordinated over a network
<paroneayea>maybe of interest
<davexunit>hmm
<davexunit>perhaps it has some insight
<paroneayea>ah right
<paroneayea>Kali Scheme
<paroneayea> https://github.com/tonyg/kali-scheme
<davexunit>using games as an example, it's easy enough to serialize the state of the world, but you have to start your scripts over.
<davexunit>you couldn't capture the current state of an enemy's AI script.
<paroneayea>i,i "you wouldn't capture an AI continuation"
<davexunit>haha
<paroneayea>davexunit: http://community.schemewiki.org/?kali-scheme-revival
<paroneayea>> Kali Scheme is a distributed implementation of the Scheme that permits efficient transmission of higher-order objects such as closures and continuations.
<paroneayea>so that's where I got the impression from, I guess.
<davexunit>oh neat
<davexunit>thanks for the reference
<paroneayea>yup!
<paroneayea>davexunit: that's the same Jonathan Rees of the "rees thesis" / security capabilities w/ scheme and the lambda calculus
<davexunit>cool, I haven't read that.
<paroneayea> http://mumble.net/~jar/pubs/secureos/secureos.html
<paroneayea>davexunit: a great read
<davexunit>you're full of papers today!
<davexunit>thanks
<paroneayea>davexunit: I don't know much about Kali, but the above paper is pretty amazing
<paroneayea>I recommend giving it a print-out and read-over.
<spk121>,
***karswell` is now known as karswell