Haskell vs Ruby as a scripting language
Is anyone using Haskell as a scripting language in their app? I'm thinking of viable it would be to embed ghc in a Mac (Cocoa) app. TextMate [1] uses Ruby as the extension language and quite successfully at that. Everybody loves Ruby since it's simple. I need a trading systems language and I'm afraid the combination of ... everything that makes Haskell otherwise great will prove a drawback in my case. What do you think? Thanks, Joel [1] http://macromates.com/ -- http://wagerlabs.com/
On 2/10/07, Joel Reymont
Is anyone using Haskell as a scripting language in their app?
I'm thinking of viable it would be to embed ghc in a Mac (Cocoa) app.
Is your application primarily written in Haskell? If not, you would have to create an interface between that language and Haskell in order for your Haskell programs to manipulate your domain objects and user interface. I think people would be happy if you did this because then there would be a Haskell API for Cocoa, but it seems like a lot of work. My guess is that it would be easier to do such bindings for Javascript due to its dynamic nature and it being an object-oriented language. Also, several projects have embedded Javascript successfully and so you would have many examples to base your project on. Visual Haskell also embeds GHC (into Visual Studio). However, Visual Haskell makes my Visual Studio unstable and often unresponsive. Because of this, I decided to use a multi-process design when embeddeding GHC into an editor--I built a customized version of the stock GHC executable that accepts commands from its parent process instead of through the command line. This way, any crashing or similar problems in the modified compiler will not result in the user losing any work in the editor. Also, I don't have to worry about threading problems, I can more clearly monitor the memory usage of the compiler/code-analyzer distinctly from that of the editor, and it should also be easier to swap in another Haskell implementation (e.g. jhc, yhc) if I wanted to. But, there were disadvantages too (e.g. I had to implement my own lexer because doing doing it with GHC via IPC was too slow for interactive use). Also, I recommend looking into embedding YHC. I have not had a chance to use it yet, but it looks like it is a better fit to an "interpreter-only" embedding situation than GHC--with GHC, you are getting a lot more than you seem to be asking for. - Brian
On Feb 10, 2007, at 2:25 PM, Brian Smith wrote:
Is your application primarily written in Haskell? If not, you would have to create an interface between that language and Haskell in order for your Haskell programs to manipulate your domain objects and user interface.
It would be Objective-C and Haskell, the exact split yet unknown.
I think people would be happy if you did this because then there would be a Haskell API for Cocoa, but it seems like a lot of work.
You already have this in HOC (http://hoc.sourceforge.net/)
My guess is that it would be easier to do such bindings for Javascript due to its dynamic nature and it being an object-oriented language. Also, several projects have embedded Javascript successfully and so you would have many examples to base your project on.
I don't see how this is different from Ruby.
Visual Haskell also embeds GHC (into Visual Studio). However, Visual Haskell makes my Visual Studio unstable and often unresponsive.
I'm not sure this would apply to me as I'm on Mac OSX.
But, there were disadvantages too (e.g. I had to implement my own lexer because doing doing it with GHC via IPC was too slow for interactive use).
Well, yes, I would want syntax highlighting and formatting. I would, in fact, need a built-in Haskell IDE.
Also, I recommend looking into embedding YHC. I have not had a chance to use it yet, but it looks like it is a better fit to an "interpreter-only" embedding situation than GHC--with GHC, you are getting a lot more than you seem to be asking for.
I would want to compile code as well. Compile bits of code <100 lines at a time and load them back into my app for execution. Does YHC compile and how efficiently? Thanks, Joel -- http://wagerlabs.com/
Hi
Also, I recommend looking into embedding YHC. I have not had a chance to use it yet, but it looks like it is a better fit to an "interpreter-only" embedding situation than GHC--with GHC, you are getting a lot more than you seem to be asking for.
I would want to compile code as well. Compile bits of code <100 lines at a time and load them back into my app for execution. Does YHC compile and how efficiently?
Yhc can happily compile code and run it. You'll probably pay a factor of 2-8 times slower than GHC, depending on what the code does. The entire Yhc binary distribution on Windows is 8Mb, of which 6Mb is the compiler. Thanks Neil
Neil Mitchell wrote:
Hi
Also, I recommend looking into embedding YHC. I have not had a chance to use it yet, but it looks like it is a better fit to an "interpreter-only" embedding situation than GHC--with GHC, you are getting a lot more than you seem to be asking for.
I would want to compile code as well. Compile bits of code <100 lines at a time and load them back into my app for execution. Does YHC compile and how efficiently?
Yhc can happily compile code and run it. You'll probably pay a factor of 2-8 times slower than GHC, depending on what the code does.
Benchmarks please! Let's see some comparisons on the nofib suite. If there's a factor of 2 or less between GHC -O2 and YHC for any of the nofib programs, I'll eat my keyboard for lunch :-) Cheers, Simon
Hi Simon,
Yhc can happily compile code and run it. You'll probably pay a factor of 2-8 times slower than GHC, depending on what the code does.
Benchmarks please! Let's see some comparisons on the nofib suite. If there's a factor of 2 or less between GHC -O2 and YHC for any of the nofib programs, I'll eat my keyboard for lunch :-)
I remember having some benchmark where Yhc was only twice as slow as GHC - possibly without -O2 (or even -O). Can't remember what, but I was slightly surprised to see it. I will try and get some Yhc vs GHC benchmarks at some point. We are also working on an optimiser for Yhc, and a C backend, so does the keyboard eating offer still encompass that version of Yhc? :) Thanks Neil
Hello Neil, Tuesday, February 13, 2007, 4:43:46 PM, you wrote:
Benchmarks please! Let's see some comparisons on the nofib suite. If there's a factor of 2 or less between GHC -O2 and YHC for any of the nofib programs, I'll eat my keyboard for lunch :-)
I will try and get some Yhc vs GHC benchmarks at some point. We are also working on an optimiser for Yhc, and a C backend, so does the keyboard eating offer still encompass that version of Yhc? :)
Simon, how about proposing limited time offer? :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Hi Simon
Benchmarks please! Let's see some comparisons on the nofib suite. If there's a factor of 2 or less between GHC -O2 and YHC for any of the nofib programs, I'll eat my keyboard for lunch :-)
http://www.cse.unsw.edu.au/~dons/nobench/bench.results Test: pidigits (lazy, arbitrary precision integers) http://www.cse.unsw.edu.au/~dons/code/nobench/imaginary/pidigits ghc 3.200 seconds (1.0 x) ghci 3.500 seconds (1.1 x) ghc-old 3.600 seconds (1.1 x) yhc 5.740 seconds (1.8 x) Would you like ketchup with that? ;) Thanks Neil
Neil Mitchell wrote:
Hi Simon
Benchmarks please! Let's see some comparisons on the nofib suite. If there's a factor of 2 or less between GHC -O2 and YHC for any of the nofib programs, I'll eat my keyboard for lunch :-)
http://www.cse.unsw.edu.au/~dons/nobench/bench.results
Test: pidigits (lazy, arbitrary precision integers) http://www.cse.unsw.edu.au/~dons/code/nobench/imaginary/pidigits ghc 3.200 seconds (1.0 x) ghci 3.500 seconds (1.1 x) ghc-old 3.600 seconds (1.1 x) yhc 5.740 seconds (1.8 x)
Would you like ketchup with that? ;)
pidigits is not (currently) one of the nofib programs (phew :-). I suppose the reason for the results is because the test spends most of its time in GMP? There are some other odd results in nobench, like the 2 programs where Hugs beats GHC that we need to look into. Cheers, Simon
simonmarhaskell:
Neil Mitchell wrote:
Hi Simon
Benchmarks please! Let's see some comparisons on the nofib suite. If there's a factor of 2 or less between GHC -O2 and YHC for any of the nofib programs, I'll eat my keyboard for lunch :-)
http://www.cse.unsw.edu.au/~dons/nobench/bench.results
Test: pidigits (lazy, arbitrary precision integers) http://www.cse.unsw.edu.au/~dons/code/nobench/imaginary/pidigits ghc 3.200 seconds (1.0 x) ghci 3.500 seconds (1.1 x) ghc-old 3.600 seconds (1.1 x) yhc 5.740 seconds (1.8 x)
Would you like ketchup with that? ;)
pidigits is not (currently) one of the nofib programs (phew :-). I suppose the reason for the results is because the test spends most of its time in GMP?
Right. If you look at the shootout, it really is a gmp bottleneck.
There are some other odd results in nobench, like the 2 programs where Hugs beats GHC that we need to look into.
Hugs only wins on one, atom, ghc hugs spectral atom 3.52 0.55 this entry says in the src that hugs has historically beaten ghc here (by up to 20x in the past.
From the src:
It has the interesting property that Classic Hugs runs it 20x faster than GHC! Reason: runExperiment calls itself with identical parameters, and Hugs commons that up for some reason. (Even with that fixed, STG Hugs ran the program a lot slower than Classic Hugs.) So it seems like an interesting program. It appears here in the form with the silly self-call, because that makes it run a nice long time. It thrashes floating point multiplication and lists. The 'constraints' entry is also interesting, in that hbc is a fair bit faster there. The two where nhc98 wins are due to nhc98 producing the wrong output. The testsuite doesn't diff the output yet.. Another interesting one is clausify, which has a heap oflow in 6.6, but runs fine in 6.4.2. Generally things look pretty good. The Hbc (and possibly Hacle/Clean) results might indicate some areas to look at more closely. -- Don
dons@cse.unsw.edu.au (Donald Bruce Stewart) wrote:
The two where nhc98 wins are due to nhc98 producing the wrong output. The testsuite doesn't diff the output yet..
Only one of those gives the wrong output (spectral/integer). The other (spectral/calendar) looks right to me. Interestingly, when I tried to debug the broken one (using Hat of course), it ceased to be broken. Grr, heisenbugs. Regards, Malcolm
Hi
pidigits is not (currently) one of the nofib programs (phew :-).
Shame...
I suppose the reason for the results is because the test spends most of its time in GMP?
Taking a brief look that does indeed appear to be true. I don't think there could be any other reason for Yhc getting so close :) And in light of these benchmarks I'd like to restate my performance claims of Yhc to "between 2x and 100x slower than GHC, usually". Thanks Neil
joelr1:
Is anyone using Haskell as a scripting language in their app?
I'm thinking of viable it would be to embed ghc in a Mac (Cocoa) app.
TextMate [1] uses Ruby as the extension language and quite successfully at that. Everybody loves Ruby since it's simple. I need a trading systems language and I'm afraid the combination of ... everything that makes Haskell otherwise great will prove a drawback in my case.
What do you think?
Embedding GHC-api seems a reasonable thing to do, though definitely experimental.
participants (7)
-
Brian Smith -
Bulat Ziganshin -
dons＠cse.unsw.edu.au -
Joel Reymont -
Malcolm Wallace -
Neil Mitchell -
Simon Marlow