- Haskell-Cafe - Haskell.org

Embedded scripting Language for haskell app
by Hemanth Kapila 18 Aug '10

18 Aug '10

Hi, Can some one please give me a suggestion on the best choice for an embedded scripting Language for a haskell application? I mean, something like guile/lua for c/c++ and groovy/jruby for java. For quite some time, I've been using a lisp-like interpreter that I implemented myself. But this is not going too well - going by this road, I suspect I will end up with a mule. I am looking for a pony (a declarative programming language). I am okay with a donkey too. baskell[1] seems interesting. And there's hslua[2]. Can one use hint[3] like this ? Thanks Hemanth K [1] baskell - http://hackage.haskell.org/package/baskell [2] hslua - http://hackage.haskell.org/package/hslua [3] hint - http://hackage.haskell.org/package/hint

7 6

Re: [Haskell-cafe] Embedded scripting Language for haskell app
by Felipe Lessa 18 Aug '10

18 Aug '10

On Tue, Aug 17, 2010 at 7:07 PM, Christopher Done <chrisdone(a)googlemail.com> wrote: > Sadly this is true. I went ahead and tested this to confirm; compiled > mueval (which uses hint), copied the executable to a virtual machine > and it required the GHC package repo among other GHC-related > libraries. > > The size is indeed a problem. But how much? How does this compare to Lua et al? IIRC, the Haskell Platform installer for Windows has around 70 MiB. So, if you want a simple installer to include in your installer, be prepared to have another 70 MiB. I said a dozen mebibytes (12 MiB) because I think the bare minimum needs to have at least this size to have something useful for an app, but this isn't backed up by anything. Lua, on the other hand, is embedded in the executable and weights less than 200 KiB, probably much less than a typical Haskell executable. I don't know about other interpreters. I just did a quick look at some executables I had in hand (compiled by GHC 6.12.3) and the smallest one weights at 2.3 MiB. Hmmm, let me see something: $ du -hs /usr/lib/ghc-6.12.3/ 588M /usr/lib/ghc-6.12.3/ Wow! That was unexpected. =) $ du -sm /usr/lib/ghc-6.12.3/* | sort -n | tail -n 5 23 /usr/lib/ghc-6.12.3/template-haskell-2.4.0.1 24 /usr/lib/ghc-6.12.3/ghc 77 /usr/lib/ghc-6.12.3/Cabal-1.8.0.6 78 /usr/lib/ghc-6.12.3/base-4.2.0.2 265 /usr/lib/ghc-6.12.3/ghc-6.12.3 $ du -sm /usr/lib/ghc-6.12.3/ghc-6.12.3/* | sort -n | tail -n 5 1 /usr/lib/ghc-6.12.3/ghc-6.12.3/ZipDataflow.p_hi 30 /usr/lib/ghc-6.12.3/ghc-6.12.3/libHSghc-6.12.3-ghc6.12.3.so 43 /usr/lib/ghc-6.12.3/ghc-6.12.3/HSghc-6.12.3.o 56 /usr/lib/ghc-6.12.3/ghc-6.12.3/libHSghc-6.12.3.a 111 /usr/lib/ghc-6.12.3/ghc-6.12.3/libHSghc-6.12.3_p.a Ah, so this one file alone takes 111 MiB =). But 30 MiB of libHSghc.so probably will need to be included. $ xz -9 < /usr/lib/ghc-6.12.3/ghc-6.12.3/libHSghc-6.12.3-ghc6.12.3.so | wc -c 4507512 So using one of the best generic compression algorithms available, the size of one of the biggest libraries that a program using hint may need comes down to 4.5 MiB. Probably if someone is careful enough to include only what really is necessary, the program installer will be at most 10 MiB and will need at most 50 MiB on disk. I think this is doable, but a lot more than Lua; hint can't be used on set-top boxes =). > Sandboxing and import whitelisting with hint is also a no-brainer -- > see mueval and http://tryhaskell.org/. I also implement import > filtering here with haskell-src-exts: > http://github.com/chrisdone/haskell-json/blob/master/haskell-json.hs#L137 > So import whitelisting is trivial. Sweet, I had forgotten about mueval. And wouldn't it be nice if we could hand haskell-src-exts's parse tree directly into GHC? Cheers! =) -- Felipe.

3 3

Which Mail editor or mail chain do you use ?
by Luc TAESCH 18 Aug '10

18 Aug '10

Gentlemen, Slightly off topic, but when reading this list , I was ( happily ) surprised when reading this list, about the quality of typing, including redaction,paragraph, greeks and footnote ref like , in just a (pure) text list ... baskell[1] seems interesting. And there's hslua[2]. Can one use hint[3] like this ? Thanks [1] baskell - http://hackage.haskell.org/package/baskell [2] hslua - http://hackage.haskell.org/package/hslua [3] hint - http://hackage.haskell.org/package/hint Is this some kind of idiom that developped over time and habit ( of people reading papers) , particularly educated, and in need for others recognition, or born out of using an (arche)typical environment/ toolchain Markdown - latex like ? May I ask you how you redact your answers and which toolchain you are using ? Thanks for quenching my curiosity Luc

4 3

Question about memory usage
by Tako Schotanus 17 Aug '10

17 Aug '10

I was reading this article: http://scienceblogs.com/goodmath/2009/11/writing_basic_functions_in_has.php And came to the part where it shows: > fiblist = 0 : 1 : (zipWith (+) fiblist (tail fiblist)) Very interesting stuff for somebody who comes from an imperative world of course. But then I read that "Once it's been referenced, then the list up to where you looked is concrete - the computations *won't* be repeated." and I started wondering how that works. Because this seems to mean that functions could have unknown (to the caller) memory requirements. How does one, programming in Haskell, keep that in check? And when does that memory get reclaimed? Cheers, -Tako

11 16

Re: [Haskell-cafe] Re: String vs ByteString
by Tako Schotanus 17 Aug '10

17 Aug '10

On Tue, Aug 17, 2010 at 13:29, Ketil Malde <ketil(a)malde.org> wrote: > Tako Schotanus <tako(a)codejive.org> writes: > > >> Just like Char is capable of encoding any valid Unicode codepoint. > > > Unless a Char in Haskell is 32 bits (or at least more than 16 bits) it > con > > NOT encode all Unicode points. > > And since it can encode (or rather, represent) any valid Unicode > codepoint, it follows that it is 32 bits (and at least more than 16 > bits). > > :-) > > (Char is basically a 32bit value, limited valid Unicode code points, so > it corresponds to UCS-4/UTF-32.) > > Yeah, I tried looking it up but I could find the technical definition for Char, but in the end I found that "maxBound" was "0x10FFFF" making it basically 24 bits :) I know for example that Java uses only 16 bits for its Chars and therefore can NOT give you all Unicode code points with a single Char, with Strings you can because of the extension points. -Tako

3 2

Re: [Haskell-cafe] Re: String vs ByteString
by Tom Harper 17 Aug '10

17 Aug '10

> I agree, Data.Text is great. Unfortunately, its internal use of UTF-16 > makes it inefficient for many purposes. In the first iteration of the Text package, UTF-16 was chosen because it had a nice balance of arithmetic overhead and space. The arithmetic for UTF-8 started to have serious performance impacts in situations where the entire document was outside ASCII (i.e. a Russian or Arabic document), but UTF-16 was still relatively compact, compared to both the UTF-32 and String alternatives. This, however, obviously does not represent your use case. I don't know if your use case is the more common one (though it seems likely). The underlying principles of Text should work fine with UTF-8. It has changed a lot since its original writing (thanks to some excellent tuning and maintenance by bos), including some more efficient binary arithmetic. The situation may have changed with respect to the performance limitations of UTF-8, or there may be room for it and a UTF-16 version. Any takers for implementing a UTF-8 version and comparing the two? > A large fraction - probably most - textual data isn't natural language > text, but data formatted in textual form, and these formats are > typically restricted to ASCII (except for a few text fields). > > For instance, a typical project for me might be 10-100GB of data, mostly > in various text formats, "real" text only making up a few percent of > this. The combined (all languages) Wikipedia is 2G words, probably less > than 20GB. > > Being agnostic about string encoding - viz. treating it as bytes - works > okay, but it would be nice to allow Unicode in the bits that actually > are text, like string fields and labels and such. Is your point that ASCII characters take up the same amount of space (i.e. 16 bits) as higher code points? Do you have any comparisons that quantify how much this affects your ability to process text in real terms? Does it make it too slow? Infeasible memory-wise?

8 12

putStrLn "ß"
by Henk-Jan van Tuyl 17 Aug '10

17 Aug '10

L.S., When I try putStrLn "ß" (Eszett (sharp S)) in WinGhci, the interpreter seems to have disappeared; ctrl-C gives the message "Interrupted" in a separate window, but no new prompt. When I start GHCi in a shell, the interpreter displays: Prelude> print "ß" "\223" Is this a known issue? Other experiments with WinGhci: >print "αγδ" "a?d" (Trying to print alpha, gamma, delta.) >print "β" (Trying to print beta) interpreter hangs again. Details: - WinGhci 1.0.2 - GHCi, version 6.12.3 - Windows XP Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html --

4 3

ANN: primes-0.2.0.0
by Sebastian Fischer 16 Aug '10

16 Aug '10

Hello, I have uploaded new versions of the primes package to Hackage: http://hackage.haskell.org/package/primes Version 0.2.0.0 significantly improves the memory requirements (and as a result also the run time) compared to 0.1.1. The run time is now almost linear and when streaming an infinite list of primes the memory requirements are almost constant. I think, primes is now the most efficient prime generator on Hackage. The interface has been generalised to support arbitrary Integral types and not just Integers and I have added two convenience functions: isPrime :: Integral int => int -> Bool primeFactors :: Integral int => int -> [int] These functions can be used for numbers with moderately large prime factors but are impractical when passing RSA numbers [1] because they simply use trial division [2]. The performance improvements have also been implemented in version 0.1.1.1 which provides the old interface. As the only API changes (of 0.2) are additions and the generalisation to Integral types, switching directly to 0.2 should be straightforward. The implementation is similar to Melissa O'Neil's code on the Haskell Wiki [3] which is one of the most efficient (pure) prime generators (without an upper bound) in Haskell that I know of. My goal was to simplify her implementation without sacrificing performance significantly. The performance of the prime package now almost matches the performance of Melissa's code. Judge for yourself whether you find the implementation more readable: http://github.com/sebfisch/primes/blob/0.1.1.1/Data/Numbers/Primes.hs The 0.2 tarball contains (source, not binary) programs that can be used to measure the performance of my implementation using Criterion (runtime.hs) and checking the memory requirements when generating large primes (memory.hs). Cheers, Sebastian [1]: http://en.wikipedia.org/wiki/RSA_numbers [2]: http://en.wikipedia.org/wiki/Trial_division [3]: http://www.haskell.org/haskellwiki/Prime_numbers -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

1 0

expression problem
by Patrick Browne 16 Aug '10

16 Aug '10

Hi, The expression problem [1] can be described as the ability to add new variants (either constructors or methods) to a data type without changing the existing code. The Haskell and OO language issues are well described at [1] It seems that the expression problem does not exist in Maude[2]. My question is: Using basic and easy parts of the Haskell, does Haskell currently handle the expression problem. In other words I would like to avoid demanding and sophisticated coding techniques or non-standard Haskell extensions (i.e. it should be easy for the average programmer to use). If there is a simple solution could you please point me to an example. Thanks, Pat [1] Dr. Ralf Laemmel http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Dr-Ralf-Laemmel-Advan… [2]http://lists.cs.uiuc.edu/pipermail/maude-help/2010-January/000336.html This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie

2 1

Deprecated gtk2hs functions
by Alex Rozenshteyn 16 Aug '10

16 Aug '10

I recently started playing around with gtk2hs. I noticed that `onClicked`, `afterClicked`, etc. functions have been deprecated, presumably in favor of the `on` and `after` functions in the Glib signals module, but I couldn't find a collection of the appropriate signals to replace the functionality. Am I simply being blind? -- Alex R

3 4