[Haskell-cafe] compilation to C, not via-C
bulat.ziganshin at gmail.com
Sat Apr 25 15:51:56 EDT 2009
Saturday, April 25, 2009, 11:40:05 PM, you wrote:
btw, are you seen MetaLua? it's pretty piece of software that makes
Lua very FPish
> 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.
> 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.spam at gmail.com]
> Sent: 24 April 2009 18:14
> To: Sam Martin
> Cc: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] compilation to C, not via-C
> 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
> 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.martin at 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
>> 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,
>> Sam Martin
>> Lead Programmer
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
Bulat mailto:Bulat.Ziganshin at gmail.com
More information about the Haskell-Cafe