<div dir="ltr"><div>On Wed, Feb 19, 2014 at 9:30 AM, Kiwamu Okabe <<a href="mailto:kiwamu@debian.or.jp">kiwamu@debian.or.jp</a>> wrote:</div><div>> Hi Johnny, I had forgotten important point.</div><div>></div><div>
> > On Wed, Feb 19, 2014 at 11:57 PM, Johnny Billquist <<a href="mailto:bqt@update.uu.se">bqt@update.uu.se</a>> wrote:</div><div>> >> Maybe someone with more insight could explain to an idiot like me how</div>
<div>> >> Haskell garbage collection is handled when running in the kernel?</div><div>></div><div>> Running a simple logic in the kernel, it doesn't call GC.</div><div><br></div><div>Having looked over the source, I couldn't get much of a feel for it -</div>
<div>it mostly seemed to be FFI & type declarations. Which does make sense</div><div>since the goal is to provide strong type checking in the kernel. Maybe</div><div>I'm looking in the wrong place in that rather large repository?</div>
<div><br></div><div>My question is how much does coding to meet the requirements for a</div><div>device driver - not doing GC being one of them - warp the resulting</div><div>Haskell code? Is it still pretty much idiomatic Haskell, or would it</div>
<div>be easier for a Haskell programmer to figure out the C it replaced?</div><div>Most of the time I've seen people try and get a modern language to</div><div>meet such requirements (me included), you might as well have stuck</div>
<div>with C as far as code improvement goes.</div><div><br></div><div>One of the advantages C has in the kernel - the BSD kernels, anyway,</div><div>reading Linux kernel makes me queasy - is that it isn't that different</div>
<div>from C in userland. And the kernel groups have been working on</div><div>reducing over the differences.</div><div><br></div><div>       Thanks,</div><div>       <mike</div><div><br></div></div>