replacing guile with haskell?
I'm wondering what the possibilities are for replacing the use of guile with a haskell interpereter? I'd like to be able to embed a haskell interpereter (presumably hugs) withing my program, so that the input file could be a haskell program. The application is a numerical simulation code, for which the input is (among other things) a photonic crystal structure. Practically, this means that the input file needs to be a program (or the user needs to write a program to generate the input file--ugly). Currently my code works as a C++ library, but that isn't particularly convenient (except for development). A similar code (mpb--it's available in debian) by a coworker has the input format in scheme using guile. That's nice in many ways, except I can't stand scheme. So I'm wondering whether there might be some convenient way to accomplish the same goal with haskell. Currently, my best (and only) idea is to make the input file a script with #!/usr/bin/env runhugs at the top (and compiling an interface module with ffihugs). There are a couple of issues with this. The first is that I've heard that hugs isn't intended for numerical work (which is what I'm doing). I'm not sure if this will be a problem, since hugs won't be doing any of the real work anyways. The other is that according to the man page, it seems that hugs only supports ffi on x86, powerpc and sparc, which seems likely to be a show stopper. Since I'll need to run the code on supercomputers, I won't always have a choice of architectures, and at least support for POWER (maybe comes free with powerpc?) would be necesary--IBM SP machines are quite nice. In this regard, ghc seems worse than hugs (the thought of bootstrapping ghc on a supercomputer gives me the shivers), and nhc98 last time I looked didn't support 64 bit platforms. Is there a solution to these problems, or will I be stuck with thousands of parentheses in my input file? -- David Roundy http://www.abridgegame.org/darcs ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: hSetBuffering stdin NoBuffering messes up terminal
On Tue, Oct 14, 2003 at 09:11:47AM -0400, I wrote: On my terminal (aterm), calling hSetBuffering stdin NoBuffering within my program messes up the terminal settings somehow, so that backspace no longer works when I run my program (without the NoBuffering) a second time. [...] A simple call to hSetBuffering stdin LineBuffering doesn't seem to fix the problem. That is actually not true. My call of hSetBuffering stdin LineBuffering wasn't actually happening (I put it after a call to exitWith). Just for the archives (and anyone interested) I figured I should clarify that bit of misinformation. It seems that as long as you set stdin's buffering back to LineBuffering before you exit, you are safe from messing up the terminal settings. -- David Roundy http://www.abridgegame.org ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: replacing guile with haskell?
I'm wondering what the possibilities are for replacing the use of guile
with a haskell interpereter? I'd like to be able to embed a haskell
interpereter (presumably hugs) withing my program, so that the input file
could be a haskell program.
Do you want to embed Haskell code or to embed a Haskell interpreter?
Embedding Haskell code is supported by the ffi specification and, in
particular, by GHC which will give good performance and trustworthy numeric
results.
Currently, my best (and only) idea is to make the input file a script with
#!/usr/bin/env runhugs
at the top (and compiling an interface module with ffihugs).
You might get a little more value out of the Hugs server interface which lets
you unload and reload modules, etc.
See hugs98/docs/server.{html,tex}.
The documentation on
http://www.reid-consulting-uk.ltd.uk/alastair/publications/hugs-server/
server.ps.gz
is an out of date version of this document but gives a reasonable overview.
Googling for hugs server will find you various articles about using this
API.
There are a couple of issues with this. The first is that I've heard that
hugs isn't intended for numerical work (which is what I'm doing). I'm not
sure if this will be a problem, since hugs won't be doing any of the real
work anyways.
It's hard to comment on this. Hugs numeric routines are a lot better than
when the original don't use advice was written - but people do complain
every now and then.
The other is that according to the man page, it seems that hugs only
supports ffi on x86, powerpc and sparc, which seems likely to be a show
stopper. Since I'll need to run the code on supercomputers, I won't always
have a choice of architectures, and at least support for POWER (maybe comes
free with powerpc?) would be necesary--IBM SP machines are quite nice. In
this regard, ghc seems worse than hugs (the thought of bootstrapping ghc on
a supercomputer gives me the shivers), and nhc98 last time I looked didn't
support 64 bit platforms.
It's only calling Haskell functions from C which is non-portable.
Unfortunately, I'd guess that's the bit you need!
Porting Hugs' ffi to a new platform is pretty easy for someone with assembly
code experience since you only have to write one function - albeit a tricky
one. Less if ghc has already been ported to that platform since we can steal
code from them :-) The code involved is the function 'mkThunk' in hugs98/
src/builtin.c
GHC is available for powerpcs so it's probably just the operating system that
will cause trouble.
I would guess that nhc is easy to port to 64 bit machines since (at least
some) C compilers provide flags to compile for 32-bits. But I could easily
be wrong...
[Note: both GHC and NHC will need pretty much the same assembly code magic
that Hugs needs.]
--
Alastair Reid www.haskell-consulting.com
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Old Messages
Is there a place where I can search through the old messages to see if someone has already answered my question? Archives: http://haskell.org/pipermail/haskell/ http://haskell.org/pipermail/haskell-cafe/ http://www.mail-archive.com/[EMAIL PROTECTED]/ General mailing list info: http://haskell.org/mailman/listinfo http://www.haskell.org/mailinglist.html -- Alastair Reid ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: replacing guile with haskell?
On Fri, Oct 17, 2003 at 02:08:06PM +0100, Alastair Reid wrote: I'm wondering what the possibilities are for replacing the use of guile with a haskell interpereter? I'd like to be able to embed a haskell interpereter (presumably hugs) withing my program, so that the input file could be a haskell program. Do you want to embed Haskell code or to embed a Haskell interpreter? I actually would like to embed a Haskell interpreter. There are a couple of issues with this. The first is that I've heard that hugs isn't intended for numerical work (which is what I'm doing). I'm not sure if this will be a problem, since hugs won't be doing any of the real work anyways. It's hard to comment on this. Hugs numeric routines are a lot better than when the original don't use advice was written - but people do complain every now and then. That's good news. I'll hope that since the heavy lifting is in C++ I should be fine... The other is that according to the man page, it seems that hugs only supports ffi on x86, powerpc and sparc, which seems likely to be a show stopper. Since I'll need to run the code on supercomputers, I won't always have a choice of architectures, and at least support for POWER (maybe comes free with powerpc?) would be necesary--IBM SP machines are quite nice. In this regard, ghc seems worse than hugs (the thought of bootstrapping ghc on a supercomputer gives me the shivers), and nhc98 last time I looked didn't support 64 bit platforms. It's only calling Haskell functions from C which is non-portable. Unfortunately, I'd guess that's the bit you need! H. I may be able to get by without calling haskell functions from C. Most of the work would be done in C, and haskell would just be the glue language to let the user flexibly specify what he/she wants done. It *would* be nice, however, to let the user specify the dielectric function as a function of position as a haskell function! But in most cases, the user will build up the structure out of primitives (cylinders, spheres, etc), and that can be done without calling haskell from C. Porting Hugs' ffi to a new platform is pretty easy for someone with assembly code experience since you only have to write one function - albeit a tricky one. Less if ghc has already been ported to that platform since we can steal code from them :-) The code involved is the function 'mkThunk' in hugs98/ src/builtin.c That's encouraging, but alas I have no real assembly code experience. I would guess that nhc is easy to port to 64 bit machines since (at least some) C compilers provide flags to compile for 32-bits. But I could easily be wrong... H. The catch is that you'd then be using 32 pointers, and I doubt that the MPI libraries will run in 32 bit mode... Thanks for the advice! I'm a bit more optimistic now that the runhugs solution will work. I've still got a week or two of C++ work to go, plus putting a C wrapper around everything, before I can seriously consider starting work on a haskell interface. -- David Roundy http://civet.berkeley.edu/droundy/ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: hSetBuffering stdin NoBuffering messes up terminal
Glynn Clements [EMAIL PROTECTED] writes: David Roundy wrote: On my terminal (aterm), calling hSetBuffering stdin NoBuffering within my program messes up the terminal settings somehow [...] Disabling buffering with hSetBuffering not only disables the user-space buffering (analogous to setvbuf() etc in C), it also disables the terminal's buffering (more precisely, disables canonical mode). According to me, hSetBuffering should not touch the terminal settings ever. It is not mentioned in the Report and it is not implied by its name. It only leads to confusion. BTW, if your program actually needs unbuffered terminal input (i.e. you want to receive individual key codes without waiting for the user to hit Return), and hSetBuffering didn't change the terminal settings, you would have to do it yourself anyhow, leading to the same issues. In my experience, one seldom wants to do this. There are specialised libraries which do things like this well and easily. Each time I wanted unbuffered input terminal was used for testing only, in which case backspace is useful. For stupid little programs we could provide some stupid little functions which have the word 'Magic' in their name, instead of abusing standard operations. Strictly in my opinion, Feri. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: hSetBuffering stdin NoBuffering messes up terminal
On Tue, Oct 14, 2003 at 03:47:29PM +0100, Glynn Clements wrote: Removing the TTY handling from hSetBuffering is even simpler. For simple, stupid programs, we could just provide e.g. hSetCooked, so programs which want the current behaviour can use: hSetBuffering stdin NoBuffering hSetCooked stdin False Programs which don't want this behaviour would just omit the hSetCooked call, which is substantially easier than the current situation (figure out if stdin is a tty, save the terminal settings, disable buffering, restore the settings). yes! this would be ideal. John -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: replacing guile with haskell?
David Roundy [EMAIL PROTECTED] writes: Do you want to embed Haskell code or to embed a Haskell interpreter? I actually would like to embed a Haskell interpreter. (snip) H. I may be able to get by without calling haskell functions from C. Most of the work would be done in C, and haskell would just be the glue language to let the user flexibly specify what he/she wants done. I've always wanted to see some way to do embed Haskell in an application the way you can for Guile. This would be great for Embedded Domain-Specific languages :) Is that what you've got here? peace, isaac ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: listProduct -- is this a standard function?
I'm pretty sure this is sequence. Brandon ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
