<crime>when the website says compiler frontends for lua, does this mean that guile will run on lua, or that I'll be able to use lua in guile? <crime>oh, neat. there's a lot of great lua code already written, just waiting to be exploited <daviid>crime: afaict, this is still a bit experimental, but I don't develop it neither do I use it, maybe other guilers here can tell you more... <crime>ah, I gotcha. I actually write lua for now, so that's why I was curious. I've got my eye on Guile though, should it be possible to write lua in guile in guil(e)emacs, that's primarily what I'd be interested in. long term goal, obv <ijp>I fixed it to work with some of the changes to the compiler, but overall it's not very good <ijp>you can't even use it at the repl properly because the parser tries to read the whole file, and rewriting the parser was more effort than I wanted to put in <shanemikel_>Hey guys. I want to try and write low level bindings for Haskell.. Can somebody help me understand the SCM type? I don't need to do direct manipulation of it in Haskell yet. I'll start by relying on marshalling between c primitives and Haskell types in conjunction with the wrapping the c API. For now, all I need is a type that will allow me to retrieve SCM values and pass them back into guile functions unmolested <ijp>what do you need to know? <ijp>the "data representation" section of the manual should be enough to get started <shanemikel_>So both immediates and heap SCM values are the size of a machine word? <ijp>nvm, they are addresses like other heap values <rain1>why are you connecting haskell and scheme? just curious <ijp>rain1: seems weird to me too, but then again, I want to write a haskell compiler in Scheme, so I'm not in much of a position to talk <rain1>why write a haskell compiler in scheme? <ijp>it avoids the bootstrap issue <ijp>I already know guile's language infrastructure pretty well, so I could even integrate <mark_weaver>shanemikel: it would be best to avoid hardcoding assumptions about the size of SCM. but you can assume that they are fairly small anyway. <ijp>I don't know why I assumed we treated pairs differently (well we do, but differentlyer) <mark_weaver>shanemikel: at present, they are the same size as a pointer, but I'd prefer to avoid promising that it will always be the case. <ijp>mark_weaver: how would he write this in a forwards compatible manner? <mark_weaver>one option would be for the configure script to determine the size <ijp>the configure script would need to check more than just size though <ijp>the whole representation of SCM could change <rain1>would be great to have a new haskell compiler! <ijp>e.g. suppose we arbitrarily decided to swap the tag for integers and pointers <mark_weaver>indeed, we reserve the right to change the details of the representation between major versions <mark_weaver>shanemikel: there are many macros and C functions for inspecting SCM values and converting them to/from C <shanemikel>yeah, but I don't want to convert just to receive a SCM val if the only thing I'm gonna do is pass it to another guile func <mark_weaver>they are documented along with the types themselves in sections 6.6 and 6.7 of the guile manual <ijp>shanemikel: keep SCM opaque in haskell, and only convert it in explicit procedures? <mark_weaver>shanemikel: okay, sure, you can store and pass around the SCM values. I'm not clear on what you're missing. <ijp>so you'd have a function foo :: SCM -> SCM <rain1>shanemikel: was wondering what it is you are doing with combining scheme and haskell? <ijp>or probably some monad to handle error cases <shanemikel>rain1: you don't think ffi bindings are a good idea? <mark_weaver>shanemikel: btw, what's your plan for garbage collection with the guile and haskell runtimes together in a single process? <rain1>no I was asking what your doing <rain1>you dont have to explain if you ddont want to <ijp>rain1: I just always assume "because it's there" when people do weird things <shanemikel>I have no clue what I'm gonna do about that.. I just started reading about how to manage the gc in c <shanemikel>I assumed I could use the guile gc as if I were using guile with c <shanemikel>but now I'm starting to realize that's probably a naive idea <mark_weaver>shanemikel: what haskell implementation are you planning to use? <shanemikel>has nobody written bindings for another garbage collected lang yet? <ijp>shanemikel: it sounds familiar, but I suspect they didn't have a good gc answer either <ijp>but maybe I'm just misremembering the guile/emacs situation <shanemikel>mark_weaver: I'm not getting anything on google for that <shanemikel>so any project in c, or say c++, would be required to use bdwgc or no gc at all? <mark_weaver>so, this is a serious problem, but not entirely insurmountable. but if there are two separate garbage collectors, then things get a lot more complex and error prone with memory management at the boundaries between the two worlds. <mark_weaver>so much so that I would try hard to avoid these complexities <ijp>consider an object foo, that you translate to haskell space, gets gced in scheme, and then passed back to guile <mark_weaver>but basically it boils down to this: Guile's garbage collector won't be able to see references to Scheme data from Haskell data without special handling <ijp>the object you pass back in won't be eqv? to the original object <shanemikel>but doesn't that amount to the same considerations a c programmer would need to take? <mark_weaver>but IMO, it would be much better to use only a single non-trivial language runtime per process <shanemikel>yeah.. actually scheme in haskell is really easy, but the guile project is pretty cool, and it means one implementation for users <mark_weaver>FWIW, I would be glad to see Haskell implemented in Guile <shanemikel>No doubt my implementation would deviate from the scheme spec a little <mark_weaver>well, one of us may get around to it one of these days :) <shanemikel>rain1: I was just interested in learning about guile, getting comfy with ffi and lower level stuff in haskell, and an exercise in building a higher level abstraction over a lower level interface <shanemikel>and if it's ever usable, it'd be nice to have a guile interface in later projects <rain1>shanemikel: maybe what you could try doing is using haskells C FFI to create a Guile monad that lets you execute bits of guile code passed in <shanemikel>I am trying to use the C FFI.. I'm starting with the guile c api before I start thinking about higher level abstractions like monad <rain1>yeah thats a good place to start <shanemikel>okay, so I've read the "Guile Implementation" stuff in the manual. Still a few more things I'd like to understand about the garbage collection <shanemikel>so, generally speaking, what situations cause for the garbage collector to be willing to collect my stuff? First I'm assuming it has to be of type SCM or scm_t_bits.. next, does it need to be created through the interpreter, or merely at some point need to have passed trough a libguile procedure? <shanemikel>and am I correct in assuming I don't need to worry about this for immediates? <shanemikel>Okay, actually beyond garbage collection, I might be faced with the bigger problem of exceptions ***Daniel is now known as Guest25675
<ecraven>does geiser completion take the active module into account? from looking at the code, it seems it doesn't :-/ <wleslie>it does, but you have to have run the module. ***random-nickname is now known as random-nick
<civodul>paroneayea: congrats on the 8sync release! \\o/ <davexunit>ACTION tries to figure out how to make a .sig file for haunt-0.2.tar.gz <paroneayea>I'm writing up a little bit of 8sync documentation right now <jmd>How can I explicitly call a lamba expression ? <rain1>just call it like a normal function <davexunit>and to be pendatic, it's a procedure, not a lambda expression <davexunit>a lambda expression evaluates to a procedure object <cojy>to be pedantic its a closure not a procedure <jmd>To be pedantic, I want to call the procedure to which it evaluates. <rain1>jmd: if its f just do (f x y) <davexunit>oops, got a 'make distcheck' failure... hmmm <floor13>does currying affect performance, at all? specifically if I have the option to pass the procedure I'm working with, or just bake it right in, is it faster to bake it right in? the only reason I'm considering passing it is because it'll make testing easier <floor13>further, if there's a way to do some profiling on this myself, specifically with guile, I'd also love to be pointed to that <mejja>don't worry about performance <mark_weaver>floor13: type ",help profile" at the guile repl for some repl commands that can help <mark_weaver>floor13: currying can affect performance, but in most cases it's probably not significant. it depends on the details. <mark_weaver>if you have some tight loop that you wish to optimize, I could take a look and make suggestions <floor13>mark_weaver: sure, lemme finish this definition and commit. <floor13>check out verbose-lump-attempt and quiet-lump-attempt, their only difference is the call in the lambda <mark_weaver>floor13: looks to me like you won't lose anything significant by parametrizing that inner procedure name <mark_weaver>but when in doubt, use the profiler and see for yourself <floor13>mark_weaver: okay, neat. is statprof the go to? going off the guile ref manual, it doesn't seem like it's ready, but I have the feeling this man hasn't been updated in a long time ***random-nickname is now known as random-nick
***daviid is now known as Guest81842
***Guest81842 is now known as daviid
<paroneayea>I'm interested in knowing if people find it useful <paroneayea>davexunit: btw let me know when the haunt release is out :) <paroneayea>davexunit: promoted on the pumpiverse and on twitter <davexunit>paroneayea: the tutorial is informative and entertaining <civodul>there's a couple of 'set!' that i'd avoid but they're okay here ;-) <civodul>and congrats davexunit for Haunt! :-) <paroneayea>civodul: I decided to go mutation'y for brevity / simplicity <paroneayea>8sync of course does not use GOOPS and doesn't need set! <paroneayea>but, it's fun to whack mutations at the health of a character :) <paroneayea>(8sync's actor model sub-system (in progress) does use GOOPS though (but not any mutation, unless you decide to), but that's not 8sync core) <paroneayea>civodul: davexunit: anyway, I'm glad you both thought it was fun and interesting. Raises my hope! <paroneayea>next one will hopefully involve writing an irc bot ~"from scratch"