
Hello everyone; I've been using haskell for quite some time now, but, as usual, I still find myself resorting to c code too much often due to the performance penalty introduced. FFI is all nice and dandy, yet, the need to compile the code and separate the implementation in two is a mayor development issue I'd like to eliminate along with batch compilation. In the way I like to work, I only use the interpreter (I mainly started with this approach with ocaml); just program interactively; close the whole session and pretend to resume the work next time I reopen the interpreter. Unfortunately, the interpreted performance is, many times, not sufficient for my purposes. In the past I've been coding several programs that would allow the user to extend the functionality at runtime through real c code. The "host" program itself could start an internal editor that accepted c code. The code would then be sent to the system compiler, generating a dynamic object that would be loaded in the current program (and executed) immediately. With some voodoo usage of "unexelf", I could create a simple runtime environment with very good performance (except for the initial compilation delay), interactivity and persistence, but, as you might expect, almost no resilience to errors and difficult debugging issues. I would like to resume this idea. Programming the core (minimal) application in c and then adding an extension mechanism always led to better and faster programs in my experience than trying to use directly an higher-level language and (ab)use the various forms of FFI. UI latency was one of the primary reasons in many cases. The amount of c code needed was always lower too, in the end, as the code was extended beyond the original minimal requirements. The extensions, being wrapped around the core data structures, tended to be more specialized and concise than general all-purpose libraries. Has anyone experienced similar situations? Is there some documentation about integrating an haskell interpreter in host programs that would allow session persistence and some minimal form of debugging? Which interpreter works better in this context? Thanks

Off-topic, so stop reading now if you want ;-) , but reminds me of my experience using Python and C++. Python and C++ are both great languages, with their own strengths, and one might think that combining thing gets the best of both. However, using Swig etc to join Python to C++ takes a significant amount of time, and one needs project members now to learn two languages. Then I discovered a different language (not Haskell) that combined the ease of Python with the speed of C++. It's really a big advantage.

In article <837db430709021625ye53068fo357f775324f465dc@mail.gmail.com>,
"Hugh Perkins"
However, using Swig etc to join Python to C++ takes a significant amount of time, and one needs project members now to learn two languages.
That's a non-issue in my context. The first real problem is wasting time generating glue code. The second problem is interrupting the current work to correct the bindings, or the underlying code itself. The ability to correct, inspect and debug all the code at runtime without ever stopping almost outweighs the language capabilities or syntax. If elegance weren't an issue ;), I would solely use lisp, or maybe some scheme, or maybe even CINT.
Then I discovered a different language (not Haskell) that combined the ease of Python with the speed of C++. It's really a big advantage.
Is that something originally coming from digital mars? The list of languages that argue to have that target performance is quite long... ;)

G'day all.
Quoting Hugh Perkins
However, using Swig etc to join Python to C++ takes a significant amount of time, [...]
Supposedly, Boost.Python is pretty good.
Then I discovered a different language (not Haskell) that combined the ease of Python with the speed of C++.
The suspense is killing me! Cheers, Andrew Bromage

Well, then you should take a look at Boo... http://boo.codehaus.org I wrote half a million lines of C# code the last years, and I've looked at many languages, and currently Haskell is the most beautiful one I could find. But since I'm still a Haskell newbie, I can't really judge, but it is my gut feeling... But the .NET framework and all the tools are indeed very very handy when it somes to writing "industrial applications", although I still find it "imperative hacking" Hugh Perkins wrote:
On 9/3/07, ajb@spamcop.net
wrote: Then I discovered a different language (not Haskell) that combined the ease of Python with the speed of C++.
The suspense is killing me!
Oh, I thought that I'd been an obvious C# fanboy for long enough that I didnt need to mention it by name ;-) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 9/3/07, Peter Verswyvelen
Well, then you should take a look at Boo... http://boo.codehaus.org
Yes, I've looked at Boo a little. It looks cool. It made me think that a lot of language wars boils down not just to the syntactic sugar that hits one in the face at the start, but to the libraries available behind the scenes, and to the efficiency and implementation of the runtime. ie, Boo, C#, meme combat...

On 9/3/07, Peter Verswyvelen
Well, then you should take a look at Boo... http://boo.codehaus.org
What about Nemerle, guys? I don't remember seeing it mentioned here at Haskell-cafe. And no, I've never programmed a single line in Nemerle, just heard about it sometime in the past. http://nemerle.org/ -- Felipe.
participants (5)
-
ajb@spamcop.net
-
Felipe Almeida Lessa
-
Hugh Perkins
-
Peter Verswyvelen
-
Yuri D'Elia