Hello Alex, Friday, April 24, 2009, 8:57:40 PM, you wrote:

...

so, if you just need haskell-C++ interaction, you may look into using FFI [1,2]. if you believe that you can compile some java/ruby/haskellwhatever code down to C++ and incorporate it into your function - sorry, they all have too different computing model

Actually some Scheme compilers have a "c-declare" form that lets you create C functions, which can be called from C, Haskell, Java, Ruby etc.

and it supports lazy lists? :) all compiled languages has some FFI, the problem is that FFI limited to common subset of all those languages - i.e. primitive types and pointers -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Thanks Bulat and Miguel. Unless I've missed something, the FFI is an great description of how to bind C and Haskell - I think it's fine. I've read most of the content either on or referenced by the wiki - although I could well be missing something. I believe the problem is with the actual code compilation itself. I need a list of .c and .h files as an end result of the Haskell compilation stage. I expect these c files will need to include Haskell runtime C code to operate, and therefore have some dependencies in order to compile and link. Afaict, GHC as it stands does not allow me to do this, even though it presumably generates C in the process of compiling binary objects. Actually having C source as an end result is critical as I need control over exactly how the source is compiled and linked. For example: - I need to compile to different targets: either a static C lib, exe, dll or C++ lib. - I need to support multiple compilers. - I might want to produce a custom runtime. In short, I'd like to use Haskell as a code-generator. I can't see that this would be unachievable, particularly given it's generating C already. Have I missed something? Cheers, Sam -----Original Message----- From: Bulat Ziganshin [mailto:bulat.ziganshin@gmail.com] Sent: 24 April 2009 17:53 To: Sam Martin Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] compilation to C, not via-C Hello Sam, Friday, April 24, 2009, 8:36:50 PM, you wrote:

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.

well, you can intercept these files. once i wrote simple 4-line haskell utility (it may be 20 lines of C++ or so) and compiled it down to C. results was 300 lines or so which it's impossible to understand so, if you just need haskell-C++ interaction, you may look into using FFI [1,2]. if you believe that you can compile some java/ruby/haskellwhatever code down to C++ and incorporate it into your function - sorry, they all have too different computing model btw, my own program [3] goes this way - i combine fast C++ and complex Haskell code via FFI/dll to produce fast, feature-rich application [1] http://www.haskell.org/haskellwiki/GHC/Using_the_FFI [2] http://www.haskell.org/haskellwiki/FFI_cook_book [3] http://freearc.org -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Sam, Friday, April 24, 2009, 9:09:43 PM, you wrote: well, GHC generates .o files. so you may solve some of your questions. if you can absolutely ignore performance, you can use so-called non-registerized compilation what generates ansi-compatible C code most Haskell libs are written for ghc, so for other compilers you will need to write almost self-contained code

I need a list of .c and .h files as an end result of the Haskell compilation stage. I expect these c files will need to include Haskell runtime C code to operate, and therefore have some dependencies in order to compile and link.

Afaict, GHC as it stands does not allow me to do this, even though it presumably generates C in the process of compiling binary objects.

Actually having C source as an end result is critical as I need control over exactly how the source is compiled and linked. For example: - I need to compile to different targets: either a static C lib, exe, dll or C++ lib. - I need to support multiple compilers. - I might want to produce a custom runtime.

In short, I'd like to use Haskell as a code-generator.

I can't see that this would be unachievable, particularly given it's generating C already. Have I missed something?

Cheers, Sam

-----Original Message----- From: Bulat Ziganshin [mailto:bulat.ziganshin@gmail.com] Sent: 24 April 2009 17:53 To: Sam Martin Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] compilation to C, not via-C

Hello Sam,

Friday, April 24, 2009, 8:36:50 PM, you wrote:

...

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.

well, you can intercept these files. once i wrote simple 4-line haskell utility (it may be 20 lines of C++ or so) and compiled it down to C. results was 300 lines or so which it's impossible to understand

so, if you just need haskell-C++ interaction, you may look into using FFI [1,2]. if you believe that you can compile some java/ruby/haskellwhatever code down to C++ and incorporate it into your function - sorry, they all have too different computing model

btw, my own program [3] goes this way - i combine fast C++ and complex Haskell code via FFI/dll to produce fast, feature-rich application

[1] http://www.haskell.org/haskellwiki/GHC/Using_the_FFI [2] http://www.haskell.org/haskellwiki/FFI_cook_book [3] http://freearc.org

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

Hello Rick, Friday, April 24, 2009, 10:12:42 PM, you wrote: what you think about JHC? it seems that Timber is close to it

You may wish to look at Timber. It is a Haskell descendant designed for embedded systems. Its current default output is C which is then compiled. It is a very young language, but given the current list of use cases, I am sure that it will never abandon it's C output model, because most people in embedded disciplines seem to prefer it. It does, like Haskell, include a runtime, but it is small, and light. Since it is targetted towards embedded systems the garbage collector is one that can be interacted with to guarantee response times on the microsecond level.

http://timber-lang.org/

I too write software for time critical applications and multiple platforms (such as the iPhone). I surveyed over a dozen compilers in multiple languages, and my search ended with Timber. As I mentioned, it is very young, it has very little standard library to speak of, but it has strong possibilities.

On Fri, Apr 24, 2009 at 1:34 PM, Bulat Ziganshin wrote: Hello Sam,

Friday, April 24, 2009, 9:09:43 PM, you wrote:

well, GHC generates .o files. so you may solve some of your questions. if you can absolutely ignore performance, you can use so-called non-registerized compilation what generates ansi-compatible C code

most Haskell libs are written for ghc, so for other compilers you will need to write almost self-contained code

...

I need a list of .c and .h files as an end result of the Haskell compilation stage. I expect these c files will need to include Haskell runtime C code to operate, and therefore have some dependencies in order to compile and link.

...

Afaict, GHC as it stands does not allow me to do this, even though it presumably generates C in the process of compiling binary objects.

...

Actually having C source as an end result is critical as I need control over exactly how the source is compiled and linked. For example: - I need to compile to different targets: either a static C lib, exe, dll or C++ lib. - I need to support multiple compilers. - I might want to produce a custom runtime.

...

In short, I'd like to use Haskell as a code-generator.

...

I can't see that this would be unachievable, particularly given it's generating C already. Have I missed something?

...

Cheers, Sam

...

-----Original Message----- From: Bulat Ziganshin [mailto:bulat.ziganshin@gmail.com] Sent: 24 April 2009 17:53 To: Sam Martin Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] compilation to C, not via-C

...

Hello Sam,

...

Friday, April 24, 2009, 8:36:50 PM, you wrote:

...

...

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.

...

well, you can intercept these files. once i wrote simple 4-line haskell utility (it may be 20 lines of C++ or so) and compiled it down to C. results was 300 lines or so which it's impossible to understand

...

so, if you just need haskell-C++ interaction, you may look into using FFI [1,2]. if you believe that you can compile some java/ruby/haskellwhatever code down to C++ and incorporate it into your function - sorry, they all have too different computing model

...

btw, my own program [3] goes this way - i combine fast C++ and complex Haskell code via FFI/dll to produce fast, feature-rich application

...

[1] http://www.haskell.org/haskellwiki/GHC/Using_the_FFI [2] http://www.haskell.org/haskellwiki/FFI_cook_book [3] http://freearc.org

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

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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

Sam Martin wrote:

In short, I'd like to use Haskell as a code-generator.

I can't see that this would be unachievable, particularly given it's generating C already. Have I missed something?

For the case of GHC at least, you may be. The "C" that GHC compiles Haskell into isn't C in the normal linguistic sense, but rather C as a syntax for portable assembly. The GHC runtime is an STG-machine, so the "C" code for a program is really just declarations of the language of thunks and closures for the STG to do graph reduction on. I seem to recall that there are other Haskell compilers which make more of an effort to target C as an output language (rather than targeting portable assembly), though I haven't tried them myself. -- Live well, ~wren

Ryan Ingram wrote:

There was another talk about compiling Haskell into Excel spreadsheets for finance, but I can't seem to locate it right now.

It was an ICFP experience report. http://www.earth.li/~ganesh/research/paradise-icfp08 Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

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@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 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

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

Hallo, On 4/24/09, Donn Cave wrote:

Quoth Alex Queiroz ,

...

Actually some Scheme compilers have a "c-declare" form that lets you create C functions, which can be called from C, Haskell, Java, Ruby etc.

That would be like what you get with Haskell FFI "export"?

When I do this with nhc98, I need a nhc98 "main", and I would expect the same with GHC. Part of the deal would be smuggling in and initializing the Haskell runtime. Also figuring out storage, if returning any values from the exported Haskell function (as opposed to poking them into address parameters.) I can see how this would not be suitable for a library.

Incurring the risk of being too much off-topic, I'll just say that I use the Gambit-C Scheme compiler to produce C code that I link with my C driver code. I need to write the driver ("main" and friends) in C because my software is compiled as a Windows service or POSIX daemon, which requires special care. But of course you must link in the Scheme runtime, with the garbage collector, Scheme data types etc. Cheers, -- -alex http://www.ventonegro.org/