On Tue, Jan 17, 2006 at 08:43:55PM -, Brian Hulley wrote:
> An advantage of this would be that you'd no longer need to think up
> different field names for each record that you use to keep track of state
> when traversing a data structure - something that quickly becomes extremely
> difficul
I have a chunk of Haskell code I would like wrap up and distribute as
a library. Is there a way to build a static library (*.a) that
includes my code plus the Haskell runtime, which C programs can easily
link against? Here is what I have tried so far...
ghc --make -fffi MyLib # Builds MyLib.o
> Hello,
>
> Well it seems like you haven't started another flame war (yet :-).
Indeed; I am a little surprised to hear the silence.
> I'm afraid I haven't properly understood your proposal, because I
> don't have much time right now. It seems to be a bit like George
> Russels proposal (aka "exec
Hello,
Well it seems like you haven't started another flame war (yet :-).
I'm afraid I haven't properly understood your proposal, because I
don't have much time right now. It seems to be a bit like George
Russels proposal (aka "execution contexts").
Personally I have never felt the need for threa
On 1/17/06, Keean Schupke <[EMAIL PROTECTED]> wrote:
> Just made a few modifications and thought it might be useful to
> people. I have rewritten the functions as
> "liftR" and "bracketR" over a "MonadIO" monad interface (allowing
> monad-transformers to be used).
I'm sorry, but what is "Lib.M
On Tuesday 17 January 2006 22:44, Brian Hulley wrote:
> Tomasz Zielonka wrote:
> > On Sun, Jan 08, 2006 at 01:06:18PM -, Brian Hulley wrote:
> >> 5) We can get all the advantages of automatic namespace management
> >> the OOP programmers take for granted, in functional programming,
> >> by usin
Hi Bulat,
On Wed, Jan 18, 2006 at 12:10:45AM +0300, Bulat Ziganshin wrote:
>
> Monday, January 16, 2006, 12:52:42 AM, you wrote:
>
> IL> OK, I have one library which provides
>
> IL> inflate :: [Word8] -- The input
> IL> -> ([Word8], -- A prefix of the input inflated (uncompr
Tomasz Zielonka wrote:
On Sun, Jan 08, 2006 at 01:06:18PM -, Brian Hulley wrote:
5) We can get all the advantages of automatic namespace management
the OOP programmers take for granted, in functional programming, by
using value spaces as the analogue of objects, and can thereby get
rid of co
Hello Ian,
Monday, January 16, 2006, 12:52:42 AM, you wrote:
IL> OK, I have one library which provides
IL> inflate :: [Word8] -- The input
IL> -> ([Word8], -- A prefix of the input inflated (uncompressed)
IL> [Word8]) -- The remainder of the input
you can use s
On Tue, 2006-01-17 at 13:42 -0600, Green Bryan - bgreen wrote:
> Does anyone know of libtiff having been wrapped for Haskell? If not,
> where could I find a good tutorial on wrapping a c library with
> functions that have variable argument parameters?
The Haskell FFI does not support calling "var
Tomasz Zielonka wrote:
[A bit late reply - I've just returned from vacation]
On Sun, Jan 08, 2006 at 05:47:19PM -, Brian Hulley wrote:
All I'm proposing is that the compiler should do all this painful
work for you, so that you don't need to bother creating a different
file that then needs t
Title: libtiff
Does anyone know of libtiff having been wrapped for Haskell? If not, where could I find a good tutorial on wrapping a c library with functions that have variable argument parameters?
Thanks,
Bryan Green
**
--- Brent Fulgham <[EMAIL PROTECTED]> wrote:
> As expected, GHC makes quite a good showing, moving
> to 4th position behind ...
Rather than look at rank position look at the relative
performance (and remember that Bigloo tops ackermann
on The Sandbox).
http://shootout.alioth.debian.org/sandbox/f
Hi Oleg,
Just made a few modifications and thought it might be useful to
people. I have rewritten the functions as
"liftR" and "bracketR" over a "MonadIO" monad interface (allowing
monad-transformers to be used). This is now
usable as Region library, as you can lift any arbitrary IO functio
Spurred out of my typical lazy state by the recent
activity on
Haskell-cafe, I went ahead and bumped Ackermann to
9,10, and 11
to see what would happen.
http://shootout.alioth.debian.org/debian/benchmark.php?test=ackermann&lang=all
As expected, GHC makes quite a good showing, moving to
4th positi
First of all, we recently had a thread 'Shootout favouring imperative code',
and I named this one after that. I certainly did not intend to insinuate
(otherwise than mockingly) that the benchmarks were intentionally chosen so
as to make one particular language look good/bad.
I apologize for all
16 matches
Mail list logo
