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

[Rick R]

I really like the idea of the region based mem management (and other GC
options) in JHC. It could potentially remove the need for any runtime at
all, which is nice.

Two fundamental differences of Timber is that it is purely strict, and not
pure functional.
This makes the implementation and use of IO intensive systems slightly more
straightforward IMO.

Also, when I tested JHC, I couldn't get it to compile my test case. Note
that I am not qualified to speak on the quality of the compiler since my
Haskell skills are mediocre at best.

One big advantage of JHC once it matures is that it will be able to leverage
the cornucopia of haskell libs in hackage, wheras Timber will have to start
pretty much from scratch.



On Fri, Apr 24, 2009 at 2:19 PM, Bulat Ziganshin
<bulat.ziganshin at gmail.com>wrote:

> 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
> > <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
> >
>
>
>
>
>
>
>
> --
> Best regards,
>  Bulat                            mailto:Bulat.Ziganshin at gmail.com
>
>


-- 
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/448a5978/attachment.htm