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

Rick R rick.richardson at gmail.com
Fri Apr 24 14:12:42 EDT 2009


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
<bulat.ziganshin at gmail.com>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 at gmail.com]
> > Sent: 24 April 2009 17:53
> > To: Sam Martin
> > Cc: haskell-cafe at 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 at gmail.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
We can't solve problems by using the same kind of thinking we used when we
created them.
   - A. Einstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090424/26a37d39/attachment.htm


More information about the Haskell-Cafe mailing list