Hi Ryan, Nice to hear from another games industry coder on the Haskell lists :)
Thanks, this is exactly the kind of detail I was after. I had heard rumours of the Evil Mangler but hadn't found a concrete reference to it before. This makes a lot of sense. Given this and the other helpful comments I tend to agree with Wren that a different compiler might be a better starting point. I'll follow up JHC and YHC in more depth and have a nose at Timber and Gambit-C as well. I'm pretty much undecided on whether haskell and games are going to play well at the moment. For me, it's very difficult to call, but I think it still looks interesting enough to pursue. I note there is at least a precedent set for functional languages in games by Naughty Dog's GOAL (http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp). As it happens, I tried to stir up the coders on the gd-algorithms mailing list recently to see how much interest there was in Haskell for games. There was a fair amount of cyber-tumbleweed :). Please feel free to chip in :) I agree the runtime is definitely where a big chunk of the problem is - particular garbage collection - but incidentally this is the bit I'm least worried about. It's all work, but I think there are ways of managing this predictably and efficiently. The 'clump and dump' approach the Eaton guys have used (and maybe region marking in JHC?) was one idea that had sprung to mind already - assuming it's the same one :). The monad->code approach sounds interesting as way of implementing small DSLs, but it sounds like it wouldn't scale up particular far? If this is true, I'm not sure how well approach would compete with existing scripting languages used in games. I'm not especially excited about using Haskell as a game scripting language. I want to find something to eat into the vast swath of C++ written for games that lua/python/unrealscript/homebrew scripting can't touch. Say, for instance, writing a procedural LOD generator. Cheers, Sam Martin ps. As a disclaimer - I'm emailing from my work address, but this is all just my own stuff and not necessarily representative of the views of Geomerics! We are definitely not about to ship Haskell-generated C to anyone ;). I'll reply off-list about Geomerics. -----Original Message----- From: Ryan Ingram [mailto:ryani.s...@gmail.com] Sent: 24 April 2009 18:14 To: Sam Martin Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] compilation to C, not via-C Sam, I work on graphics engine/pipeline for Spore at Electronic Arts, and I've had some similar thoughts as you. But I don't think this is the right path for games right now. The "via C" compiler does generate C code that it puts through GCC. There is a post-process step after the code is converted to assembly by GCC (see http://hackage.haskell.org/trac/ghc/wiki/Commentary/EvilMangler); a perl script rewrites the calling convention of all the functions to optimize for the code that GHC generates. From what I understand, performance is significantly worse without the mangler. So interoperability of the generated C-from-Haskell code directly with your C code is tricky at best. However, the generated code is only half the story. The other half is that you need the Haskell runtime to go with your program. This manages the garbage collector, multithreading-support, etc. As a middleware developer, I'm sure you're aware that it would be quite difficult to sell "you need this big runtime with unpredictable memory requirements" to your potential customers. That said, don't lose hope. Lots of Haskell development is being done for embedded systems, and other things at a similar level as to what you want. But what these systems generally do is write a custom monad that *outputs* code. You can look at some of the CUFP2008 talks about this topic (http://cufp.galois.com/2008/schedule.html); I recommend "Controlling Hybrid Vehicles with Haskell". There was another talk about compiling Haskell into Excel spreadsheets for finance, but I can't seem to locate it right now. The basic strategy is to encapsulate all your operations in a monad, then write "code generation" that converts the results into C code which you can then compile and ship. Unless you're willing to make the jump to Haskell as a host language with FFI outcalls to native code, I think this is the right strategy right now. Good luck, and keep us informed how it goes. I expect to hear from you at CUFP next year :) -- ryan P.S. I saw some demos of Geomerics products; it looks pretty cool. What are you guys up to now? On Fri, Apr 24, 2009 at 9:36 AM, Sam Martin <sam.mar...@geomerics.com> wrote: > Hi Everyone, > > It appears the GHC compiler (and other) compile Haskell *via-C* but not > *to C*. I've never really understood why there isn't a C generation > option, or why GDC ships with its own compulsory copy of gcc. > > I work in Games middleware, and am very interested in looking at how > Haskell could help us. We basically sell C++ libraries. I would like to > be able to write some areas of our libraries in Haskell, compile the > Haskell to C and incorporate that code into a C++ library. > > As an example, I think Haskell would be great at doing geometry > processing. I don't want to write all our geometry processing code in > C++. I'd prefer to write a big chunk of it in Haskell and wrap that in > C++. > > The pattern here is using Haskell to generate C code as the end result. > It sounds like this end result isn't that far out of reach, so I'm > curious as to why it doesn't appear to be possible at present. > > Have I missed something? Is there some fundamental reason this isn't > possible? Has anyone wished for this before? > > Any thoughts/help much appreciated, > > Thanks, > Sam Martin > > --- > Lead Programmer > www.geomerics.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
