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.zigans...@gmail.comwrote:
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.zigans...@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.zigans...@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,
Bulatmailto:bulat.zigans...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
