[Haskell-cafe] compilation to C, not via-C

[Bulat Ziganshin]

Hello Sam,

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.
>  
>  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.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
>  
>  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.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
 >> 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 at haskell.org
 >> http://www.haskell.org/mailman/listinfo/haskell-cafe
 >>
>  
>   
>   
>    


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com