[Haskell-cafe] Re: Problems with Haskell Program Coverage
Malcolm Wallace Malcolm.Wallace at cs.york.ac.uk writes:
Dominic Steinitz dominic.steinitz at blueyonder.co.uk wrote:
I want to use hpc to check that the ASN.1 library tests cover all the
code. When I run it with a set of tests that I *know* don't test
certain things, it reports that they have been covered i.e. there are
not coloured in the markup that hpc produces. I would have expected a
lot of yellow.
The record of coverage is cumulative across multiple runs. Is it
possible that you did not remove an old .tix file before running the
tests?
Thanks for your reply I was beginning to worry I might be the only person trying
to use this.
I've done a bit of investigation and it seems there are at least two problems:
1. I have literate haskell files (.lhs).
2. Even if I run them through the pre-processor (ghc -E) they still don't work
but if I manually remove these lines (which seem to get inserted by the
pre-processor)
{-# LINE 1 ASNTYPE.lhs #-}
#line 1 ASNTYPE.lhs
then it does actually work.
It looks like a bug to me. I guess I should report it on the ghc trac.
I still have a problem with another project which doesn't use literate haskell
but does require the use of -cpp and has got #ifdef's. I haven't got to the
bottom of it yet but I'm suspicious that lines starting with # cause hpc to
misbehave.
It's strange that hpc should behave like this as I would have thought it
wouldn't care about hs / lhs and # as ghc would have done some of its standard
processing before hpc got engaged.
Dominic.
hpc_index.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Am Samstag 25 April 2009 08:48:16 schrieb Thomas Davie: On 24 Apr 2009, at 14:37, Loup Vaillant wrote: 2009/4/23 Miguel Mitrofanov miguelim...@yandex.ru: On 23 Apr 2009, at 12:17, Thomas Davie wrote: Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. 200 sounds awfully long. Do you have any example? Sure... arrow :: forall (~) b c d e. ( Arrow (~), Show (d ~ e), Show (c ~ d), Show (b ~ c), Show b, Show c, Show d, Show e, Arbitrary (d ~ e), Arbitrary (c ~ d), Arbitrary (b ~ c), Arbitrary b, Arbitrary c, Arbitrary d, Arbitrary e, EqProp (b ~ e), EqProp (b ~ d), EqProp ((b,d) ~ c), EqProp ((b,d) ~ (c,d)), EqProp ((b,e) ~ (d,e)), EqProp ((b,d) ~ (c,e)), EqProp b, EqProp c, EqProp d, EqProp e) = b ~ (c,d,e) - TestBatch . In all seriousness though, that one got broken, but I do find that I occasionally have lines around 100 characters that just look silly if I break them, this is a good example: filterNonRoots (GCase e bs) = filter ((/= e) ^()^ (not . (`elem` bs))) Not that I'd deny that it can sometimes be more readable to have longer lines*, but in this example, would filterNonRoots (GCase e bs) = filter ((/= e) ^()^ (not . (`elem` bs))) be any less readable in your opinion? [*] but I think 200 characters is beyond the limit Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Something like newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) Nobody would be really interested in deriving clause, because it basically says derive everything possible. Therefore, it seems pointless to move it to another line. On 24 Apr 2009, at 16:37, Loup Vaillant wrote: 2009/4/23 Miguel Mitrofanov miguelim...@yandex.ru: On 23 Apr 2009, at 12:17, Thomas Davie wrote: Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. 200 sounds awfully long. Do you have any example? Loup ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Thread priority?
Count me in too I've got a library that endeavours to deliver 'rate-equivalence' - i.e there may be some jitter in when the events should have occurred but their long term rate of progress is stable. Testing has shown that I can get events to occur at the right time within 1ms (99%+ of the time, with 50%+ of the events 0.5ms) - choose your O/S carefully though. And this is without resorting to marking the threads as real time with the kernel. If it matters you can tune the scheduling to further reduce the timer scheduling latency (at the cost of more CPU) and increase the fidelity of event timing another order of magnitude or more. As for 'garbage collection ruins my real time properties' argument - I've been pragmatic about this, you can configure the scheduler to go and perform a GC if it knows that it is going to sleep for a while (yes, this doesn't resolve the issues of external events arriving in that time but read on) but not perform that too often. Turning off GHCs timers (to stop it garbage collecting after it has actually been idle for a while) and having code that doesn't create vast amounts of garbage means that a GC takes 0.1ms. Now if I could see within Haskell the amount of heap that has been recently mutated and some other GC statistics when it was running I could even decide to schedule that more effectively. We use this to create synthetic network traffic sources and other timing/performance related activities in the wide area context - it serves our needs. Neil On 25 Apr 2009, at 03:48, Christopher Lane Hinson wrote: Is there any interest or movement in developing thread priority or any other realtime support in Haskell? Right now, if I have tasks that need to be responsive in real time, even if the realtime needs are very soft, it seems that the only option is to try to ensure that at least one hardware thread is kept clear of any other activity. To be very useful to me, thread priority would not need to come with very strict guarantees, but there would need to be a way to make sure that `par` sparks and DPH inherit the priority of the sparking thread. In part I ask because I'm working on a small library to support a degree of cooperative task prioritization. Friendly, --Lane ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Cute Hack - Hyena handler + Bamboo Blog Engine :)
What kind of port is this? Direct translation from ruby source? I see that you are using the (.) for OO-style reversed function application. Which feels a bit weird at first sight. Snippet from your Hack.Handler.Kibro: handle app = do env - get_env response - app env .liftIO -- set response response.headers.mapM_ (splash setHeader) response.status.show.setHeader Status response.body.output On Apr 25, 2009, at 7:58 AM, Jinjing Wang wrote: Hia, A few interesting progress on Hack: * many middleware ported from Rack, including a lambda! ( just like a pony for wsgi, and a lobster for rack ) * 2 handlers, one for Kibro on fcgi / lighttpd, one for Hyena web server * apps are portable, Bamboo is a port of Panda that runs on Hack, works fine with both handlers * Hyena handler is still experimental A lambda app looks like this -- Main.hs source module Main where import Hack import Hack.Utils import Hack.Handler.Hyena import Hack.Contrib.Lambda main = run $ lambda dummy_app -- compile ghc --make -O2 Main.hs -- run ./Main now go to http://localhost:3000/lambda Cheers, Links: * [Hack] (http://github.com/nfjinjing/hack/tree/master) * [Bamboo] (http://github.com/nfjinjing/bamboo/tree/master) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Cute Hack - Hyena handler + Bamboo Blog Engine :)
Yes, the spec is almost a direct translation from Rack. For middleware, I translated some from Rack, but it does not have to be a port. I'm just lazy. Rack borrowed some basic middleware from WSGI too, like Lint. About the style, it's a bit weird, yes. But only in module scope ;) On Sat, Apr 25, 2009 at 7:00 PM, Sebastiaan Visser sfvis...@cs.uu.nl wrote: What kind of port is this? Direct translation from ruby source? I see that you are using the (.) for OO-style reversed function application. Which feels a bit weird at first sight. Snippet from your Hack.Handler.Kibro: handle app = do env - get_env response - app env .liftIO -- set response response.headers.mapM_ (splash setHeader) response.status.show.setHeader Status response.body.output On Apr 25, 2009, at 7:58 AM, Jinjing Wang wrote: Hia, A few interesting progress on Hack: * many middleware ported from Rack, including a lambda! ( just like a pony for wsgi, and a lobster for rack ) * 2 handlers, one for Kibro on fcgi / lighttpd, one for Hyena web server * apps are portable, Bamboo is a port of Panda that runs on Hack, works fine with both handlers * Hyena handler is still experimental A lambda app looks like this -- Main.hs source module Main where import Hack import Hack.Utils import Hack.Handler.Hyena import Hack.Contrib.Lambda main = run $ lambda dummy_app -- compile ghc --make -O2 Main.hs -- run ./Main now go to http://localhost:3000/lambda Cheers, Links: * [Hack] (http://github.com/nfjinjing/hack/tree/master) * [Bamboo] (http://github.com/nfjinjing/bamboo/tree/master) -- jinjing ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Takusen, postgres and boolean fields
Sasha Shipka xao...@gmail.com writes: Let say one has to do something similar to this: execDML $ cmdbind (sql update some_table set some_boolean_field = ? where ...) [bindP True, ...] When I do it, I have an error: DBError (42,804) 7 ERROR: 42804: column \some_boolean_field\ is of type boolean but expression is of type text ... I've noticed that when I read boolean fields from postgres it reads them as string t or f. So I also tried bindP t and had same error. Indeed, I also have such problems in my application [1] in SELECT boolean_field from TABLE. My workaround is: I defined a plpgsql function CREATE OR REPLACE FUNCTION HBoolean(v IN BOOLEAN) RETURNS TEXT AS $$ BEGIN IF v THEN RETURN 'True'; ELSE RETURN 'False'; END IF; END; $$ LANGUAGE plpgsql; and rewrite my query as SELECT HBoolean(boolean_field) from TABLE and takusen converts it to Bool. For performance reason you may convert from text to boolean (but keep bindP True). If there is a better solution, I'm also glad to know it. Christoph Bauer [1] http://www.communitystory.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] breaking too long lines
* with practically every modern IDE (say, Eclipse for Java), indentation is a non-issue. part of this discussion here is just because we are missing proper tools. (Or not using.) * indentation should be by fixed amounts (e.g. 4 spaces for each level) and not depend on lengths of identifiers (because you might later change them) (well, actually you won't because we don't have Refactor-Rename that would be aware of namespaces, modules etc.) * A lot of my code is written for teaching, in fact I try to write all code in such a way that it could be shown to students, and so I try to use less than 40 chars per line because more won't fit on a slide. And, the slide holds at most 10 lines, so this gives a pretty clear bound on the size of a function. If it's larger, then it needs to be refactored. (Well, probably it won't, see above remark on tools.) J.W. -- View this message in context: http://www.nabble.com/breaking-too-long-lines-tp23136175p23232160.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] breaking too long lines
On 25 Apr 2009, at 17:32, j.waldmann wrote: * with practically every modern IDE You mean, with Emacs? * indentation should be by fixed amounts (e.g. 4 spaces for each level) and not depend on lengths of identifiers (because you might later change them) Agreed. I always write code that way (well, actually you won't because we don't have Refactor-Rename that would be aware of namespaces, modules etc.) Incorrect. Renaming local variables is quite common (and doesn't require anything like Refactor-Rename). By the way, if we did have Refactor-Rename, it should be able to change indentation as well. * A lot of my code is written for teaching, in fact I try to write all code in such a way that it could be shown to students, and so I try to use less than 40 chars per line because more won't fit on a slide. For teaching, or for other forms of presentations - yes, that's an upper bound. And, the slide holds at most 10 lines, so this gives a pretty clear bound on the size of a function. If it's larger, then it needs to be refactored. Well, somebody said once that a function shouldn't be large than a human's head, literally. But I wonder, how a Haskell function can be more than 10 lines long (if it is not Main.main). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 25 Apr 2009, at 10:51, Daniel Fischer wrote: Am Samstag 25 April 2009 08:48:16 schrieb Thomas Davie: On 24 Apr 2009, at 14:37, Loup Vaillant wrote: 2009/4/23 Miguel Mitrofanov miguelim...@yandex.ru: On 23 Apr 2009, at 12:17, Thomas Davie wrote: Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. 200 sounds awfully long. Do you have any example? Sure... arrow :: forall (~) b c d e. ( Arrow (~), Show (d ~ e), Show (c ~ d), Show (b ~ c), Show b, Show c, Show d, Show e, Arbitrary (d ~ e), Arbitrary (c ~ d), Arbitrary (b ~ c), Arbitrary b, Arbitrary c, Arbitrary d, Arbitrary e, EqProp (b ~ e), EqProp (b ~ d), EqProp ((b,d) ~ c), EqProp ((b,d) ~ (c,d)), EqProp ((b,e) ~ (d,e)), EqProp ((b,d) ~ (c,e)), EqProp b, EqProp c, EqProp d, EqProp e) = b ~ (c,d,e) - TestBatch . In all seriousness though, that one got broken, but I do find that I occasionally have lines around 100 characters that just look silly if I break them, this is a good example: filterNonRoots (GCase e bs) = filter ((/= e) ^()^ (not . (`elem` bs))) Not that I'd deny that it can sometimes be more readable to have longer lines*, but in this example, would filterNonRoots (GCase e bs) = filter ((/= e) ^()^ (not . (`elem` bs))) be any less readable in your opinion? Yes – this particular line is mixed in with several other pattern matches, each of which has a similar form, laying it out on one line lets you see the similarities and differences, laying it out on two lines creates visual noise. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] breaking too long lines
* with practically every modern IDE (say, Eclipse for Java), indentation is a non-issue. How so? In future IDEs, source code might just be a view on an internal representation, but we've have that kind of IDE in the past, and some users developed a definite dislike to tools that wouldn't let them adjust layout to whatever they thought best suited to the task at hand. Unless you mean semantics-based editing, where the IDE should be able to compensate for unwanted side-effects of, say, renaming, or adding/ removing parameters, without resorting to just pretty-printing everything. But as long as programmers need to resort to text editing, IDEs can at best guess their intentions, and some layout styles will be less prone than other to needing adjustments after typical editing tasks. * indentation should be by fixed amounts (e.g. 4 spaces for each level) and not depend on lengths of identifiers (because you might later change them) (well, actually you won't because we don't have Refactor-Rename that would be aware of namespaces, modules etc.) I hasn't been maintained for quite a while, and was only Haskell'98, but Renaming was the first refactoring implemented in HaRe, and HaRe was module-aware from about version 0.2: http://haskell.org/pipermail/haskell/2004-January/013508.html HaRe also adjusted indentation if Rename changed identifier lengths. According to its homepage, support for hierarchical modules was added in version 0.3 (the language concept, not the hierarchical libraries code tended to depend on even then, let alone the cabal/hackage of today) Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Miguel Mitrofanov miguelim...@yandex.ru writes: On 24 Apr 2009, at 16:37, Loup Vaillant wrote: 2009/4/23 Miguel Mitrofanov miguelim...@yandex.ru: On 23 Apr 2009, at 12:17, Thomas Davie wrote: Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. 200 sounds awfully long. Do you have any example? Something like newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) Nobody would be really interested in deriving clause, because it basically says derive everything possible. Therefore, it seems pointless to move it to another line. You don't write lisp, do you? Or probably it is just me. But I would prefer to write the line as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) It is just so much clearer than a one liner. I'd like to hear what people think about it, comparing to newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) (Yes, I rewrote it so it actually is in one line. You email editor clearly fooled you.) P.S. I moved your reply down below the citation to make this email easier to understand. -- c/*__o/* \ * (__ */\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 25 Apr 2009, at 18:34, Xiao-Yong Jin wrote: Miguel Mitrofanov miguelim...@yandex.ru writes: On 24 Apr 2009, at 16:37, Loup Vaillant wrote: 2009/4/23 Miguel Mitrofanov miguelim...@yandex.ru: On 23 Apr 2009, at 12:17, Thomas Davie wrote: Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. 200 sounds awfully long. Do you have any example? Something like newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) Nobody would be really interested in deriving clause, because it basically says derive everything possible. Therefore, it seems pointless to move it to another line. You don't write lisp, do you? Or probably it is just me. But I would prefer to write the line as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) Well, first impression I've got from this was that FirstTransformer, SecondTransformer and the rest are on the same level: newtype MyCool Monad = MyCoolMonad (FirstTransformer) (SecondTransformer) (ThirdTransformer Whatever) which is very confusing. deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) A lot of unnecessary information distracting the reader. It's better kept somewhere else, where it doesn't attract too much attention - like in the end of the line. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OT: Good Linux distro for netbook + Haskell?
On Fri, 24 Apr 2009 16:53:49 -0400 Adam Turoff adam.tur...@gmail.com wrote: I got an Eee PC this winter and I started playing with Arch Linux on it. Seems nice in theory, but the hardware is weird enough that you'll need to spend a lot of time fiddling to get the right modules installed properly to get things like wifi working. Quickly turned into an exercise in yak shaving instead of haskell hacking. Recent kernels (from ~2.6.28 onwards) have removed the need for any special configuration on an Eee 900. All necessary modules are now standard, and pm-utils supports suspend/resume perfectly. Things should run pretty much out of the box now (at least, I don't think I'm using any special packages or configs on my Eee anymore). Also, graphic performance has become OK again with the latest X server. Having an up-to-date GHC in the repos is nice, but I'm not sure about the cabal2arch stuff. The lack of support for multiple versions of packages in pacman hurts pretty bad with hackage, because the APIs of some common packages seem to change quickly and you often end up with dependencies on different versions. Using cabal-install instead is an easy solution to this though, and with up-to-date ghc, cabal and cabal-install packages in the Arch repos you don't have much trouble bootstrapping it. So Arch can probably be considered pretty Haskell-friendly. Haskell aside, Arch also gives me a pretty nice general experience on my Eee 900. Being a DIY distro of course helps since full solutions these days seem to expect a lot from my system capabilities and screen resolution. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Am Samstag 25 April 2009 16:44:45 schrieb Miguel Mitrofanov: On 25 Apr 2009, at 18:34, Xiao-Yong Jin wrote: Miguel Mitrofanov miguelim...@yandex.ru writes: On 24 Apr 2009, at 16:37, Loup Vaillant wrote: 2009/4/23 Miguel Mitrofanov miguelim...@yandex.ru: On 23 Apr 2009, at 12:17, Thomas Davie wrote: Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. 200 sounds awfully long. Do you have any example? Something like newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) Nobody would be really interested in deriving clause, because it basically says derive everything possible. Therefore, it seems pointless to move it to another line. You don't write lisp, do you? Or probably it is just me. But I would prefer to write the line as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) Well, first impression I've got from this was that FirstTransformer, SecondTransformer and the rest are on the same level: newtype MyCool Monad = MyCoolMonad (FirstTransformer) (SecondTransformer) (ThirdTransformer Whatever) which is very confusing. You have a point there. If split over several lines, I'd recommend each line indented further than the previous to indicate nesting: newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) But I wouldn't really prefer that over having it on one line. deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) A lot of unnecessary information distracting the reader. It's better kept somewhere else, where it doesn't attract too much attention - like in the end of the line. There I have to disagree. IMO, having the deriving clause on the same line (unless it's a very short one) obscures the code and makes it *much* harder to read. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On Sat, Apr 25, 2009 at 10:34:05AM -0400, Xiao-Yong Jin wrote: You don't write lisp, do you? Or probably it is just me. But I would prefer to write the line as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) Doubtlessly, this is better than a one-liner, and I don't write lisp :). However I'd change the deriving clause and write it as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) I don't think deriving clauses are unimportant and I like to see them. Also, I don't mistake the transformers as different parameters because of the parenthesis and because they're transformers, reading their names gives you a clue of how they may be used. Whoever knows transformers expect to see this kind of nesting. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] leksah on window - problems with installation.
Hello, I want to install leksah haskell IDE on my windows(xp) system. I download leksah's source (leksah-0.4.4.1). I also have gtk2hs (0.10.0) in my path. I am having ghc-6.10.2. As suggested on leksah's website.. I used runhaskell setup configure command But it is failing with this error Configuring leksah-0.4.4.1... Setup: At least the following dependencies are missing: glib =0.10, gtk =0.10, gtksourceview2 =0.10.0 I tried to do cabal install glib but not able to do so. Can you give me clues on how to go forward. with thanks regards, raja koduru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 25 Apr 2009, at 19:08, Felipe Lessa wrote: On Sat, Apr 25, 2009 at 10:34:05AM -0400, Xiao-Yong Jin wrote: You don't write lisp, do you? Or probably it is just me. But I would prefer to write the line as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) Doubtlessly, this is better than a one-liner, and I don't write lisp :). Doubtfully, after reading a message from Daniel Fischer. Also, I don't mistake the transformers as different parameters because of the parenthesis You should really try Lisp. In my opinion, parenthesis are a kind of noise - too small, too many. and because they're transformers, reading their names gives you a clue of how they may be used. So... you really think transformers CAN'T be parameters? You're going to be surprised. Whoever knows transformers expect to see this kind of nesting. Whoever knows Haskell - no offense - expects to see both. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Binary I/O options
On Fri, Apr 24, 2009 at 08:40, Edward Kmett ekm...@gmail.com wrote: The only caveat I would mention about using Data.Binary is that it traverses lists twice to encode them. Once to determine the length and once to output the list. As a result you may see space-leak-like behavior when encoding very long lists with Data.Binary. The same holds for reading back a very long list. It forces the list spine before you can get at any elements. Denis ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On Sat, Apr 25, 2009 at 07:38:59PM +0400, Miguel Mitrofanov wrote:
Also, I don't mistake the transformers as different
parameters because of the parenthesis
You should really try Lisp. In my opinion, parenthesis are a kind of
noise - too small, too many.
I don't try lisp because I don't like a lot of parenthesis as
well. However the problem isn't with parenthesis, it is with
their excessive usage. In this case they're helpful, IMO.
and because they're transformers, reading their names gives
you a clue of how they may be used.
So... you really think transformers CAN'T be parameters? You're going to
be surprised.
[...]
Whoever knows Haskell - no offense - expects to see both.
Haha :), so giving a clue of how they may be used means
meaning that they will always be fully applied now? Sorry, but
don't go hostile on me putting words on my mouth.
How do you *usually* see transformers being used? Questions of
how you read something in a glance have to touch the question of
how much you *expect* to see something. So, if I expect to see
data D = Constructor Something
Other
Here
or
data D = Constructor {field1 :: Something
,field2 :: Other
,field3 :: Here}
then I can misread
data D = Constructor (Something
(Other
Here))
This is Daniel's point: you misread it because you expected
something else. So, was Daniel trying to say that you can't have
one field on multiple lines? Not at all. When I see two or more
transformers, I expect to see them nested, and probably most
other people have the same expectations.
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 25 Apr 2009, at 19:59, Felipe Lessa wrote: On Sat, Apr 25, 2009 at 07:38:59PM +0400, Miguel Mitrofanov wrote: Also, I don't mistake the transformers as different parameters because of the parenthesis You should really try Lisp. In my opinion, parenthesis are a kind of noise - too small, too many. I don't try lisp because I don't like a lot of parenthesis as well. However the problem isn't with parenthesis, it is with their excessive usage. In this case they're helpful, IMO. Of course they are. My point was not that everything should be clear without parenthesis, but that the user shouldn't have false impressions - the notation should either give a true impression (like Daniel suggested, with every other line indented more than the previous one - though I don't like it), or not to give any impression at all, so that the reader would be forced to read the noise. and because they're transformers, reading their names gives you a clue of how they may be used. So... you really think transformers CAN'T be parameters? You're going to be surprised. [...] Whoever knows Haskell - no offense - expects to see both. Haha :), so giving a clue of how they may be used means meaning that they will always be fully applied now? Well, then, is that ALWAYS so obvious that this particular name denotes a transformer? Of course, if it's not a standard transformer like StateT or WriterT, but something written by the same guy who invented this MyCoolMonad type? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] parse error on input `'
Hi, I've defined the following datatype with haskell data Graph a b = Empty | Context a b Graph a b But I am having the error message: parse error on input `' . I am wondering what it is wrong with my definition. How can I fix this? Thanks in advance. Kind regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] parse error on input `'
Am Samstag 25 April 2009 19:29:30 schrieb siso dagbovie: Hi, I've defined the following datatype with haskell data Graph a b = Empty | Context a b Graph a b But I am having the error message: parse error on input `' . I am wondering what it is wrong with my definition. How can I fix this? Thanks in advance. A constructor symbol has to start with a colon, so make it data Graph a b = Empty | Context a b : Graph a b (or :: if you prefer it more symmetric) Kind regards Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] parse error on input `'
siso dagbovie wrote: I've defined the following datatype with haskell data Graph a b = Empty | Context a b Graph a b But I am having the error message: parse error on input `' . I am wondering what it is wrong with my definition. How can I fix this? Constructors have to start with a capital or a : (colon). So changing your definition into data Graph a b = Empty | Context a b : Graph a b will work. If you want you can define () = (:) and use the symbol for constructing graphs (not in pattern matches though). HTH, -- Jochem Berndsen | joc...@functor.nl GPG: 0xE6FABFAB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell/JS -- better through typeclasses?
I'd like to be able to translate Haskell to JavaScript. Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. For example, I'd like to write a nice parser in Haskell and then reuse it on the client side. No need to handle all the DOM events or implement multi-threading. Of course, the place to start is by reading the commentary. A little bit of browsing suggests some questions of strategy: . Maybe a new backend is not the right thing? All the backends seem to be for real computers with real instruction sets. . Is it better to just work on transforming Core into JS directly? It seems that External Core is still in limbo. . Some translations strike me as baffling in principle. For example, a value like `ones`: ones = 1 : ones We'd want to avoid most native JavaScript containers, it seems; however, we are then unable to leverage the speed of native containers. It's entirely possible that translating Haskell to JavaScript may turn out not to be the best idea; maybe it is better to have a type class for types (for example, `Parser Char`) to provide their own translators? The it would be straightforward to prevent translation of programs that use concurrency libs, native ops or `IO`. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
On 25 Apr 2009, at 21:53, Jason Dusek wrote: Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. Many books explain how to grow a baby hippo; some of them even include instructions for treating it when it's sick. However, my goals are more limited -- I'd like to be able to take an elephant and turn it into a grown-up hippo. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
I tried using the jhc javascript compiler back end a year or so ago. It was too rough to use in production, but it did output javascript from haskell. thomas. 2009/4/25 Miguel Mitrofanov miguelim...@yandex.ru: On 25 Apr 2009, at 21:53, Jason Dusek wrote: Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. Many books explain how to grow a baby hippo; some of them even include instructions for treating it when it's sick. However, my goals are more limited -- I'd like to be able to take an elephant and turn it into a grown-up hippo. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
On second thought, it was yhc, not jhc: http://lambda-the-ultimate.org/node/1836 2009/4/25 Thomas Hartman tphya...@gmail.com: I tried using the jhc javascript compiler back end a year or so ago. It was too rough to use in production, but it did output javascript from haskell. thomas. 2009/4/25 Miguel Mitrofanov miguelim...@yandex.ru: On 25 Apr 2009, at 21:53, Jason Dusek wrote: Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. Many books explain how to grow a baby hippo; some of them even include instructions for treating it when it's sick. However, my goals are more limited -- I'd like to be able to take an elephant and turn it into a grown-up hippo. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
On Apr 25, 2009, at 13:53 , Jason Dusek wrote: I'd like to be able to translate Haskell to JavaScript. http://haskell.org/haskellwiki/Yhc/Javascript ? Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. For example, I'd like to write a nice parser in That's not exactly limited; building a self-contained program is easier than producing something that seamlessly adapts between different runtimes with very different notions of how the world works. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
There will always be some people who prefer longer lines. The real issue is, how do we deal with the fundamental disagreement here? It's not like we can have both. Also those people who like long lines -- will they all agree to a long line length? -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
2009/04/25 Brandon S. Allbery KF8NH allb...@ece.cmu.edu: 2009/04/25 Jason Dusek: I'd like to be able to translate Haskell to JavaScript. http://haskell.org/haskellwiki/Yhc/Javascript ? Dead. Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. For example, I'd like to write a nice parser in That's not exactly limited; building a self-contained program is easier than producing something that seamlessly adapts between different runtimes with very different notions of how the world works. What I mean is a bucket of JavaScript functions. It would be fine to hide all the data constructors and type definitions. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
2009/04/25 Miguel Mitrofanov miguelim...@yandex.ru: 2009/04/25 Jason Dusek wrote: Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. Many books explain how to grow a baby hippo; some of them even include instructions for treating it when it's sick. However, my goals are more limited -- I'd like to be able to take an elephant and turn it into a grown-up hippo. Many persons use images in the form of analogy or metaphor to communicate a message. However, my goals are more limited -- I'd like to use images without analogy or metaphor. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
2009/04/25 Thomas Hartman tphya...@gmail.com: 2009/04/25 Thomas Hartman tphya...@gmail.com: I tried using the jhc javascript compiler back end a year or so ago. On second thought, it was yhc, not jhc: http://lambda-the-ultimate.org/node/1836 Yeah, I think that thing has been dead for awhile. Also it does a lot more than I want -- I don't want to write my UI logic in Haskell at present. The AJAX toolkits are pretty good and it would be a waste to try to translate them into Haskell and keep them updated. I would like to be able to write a lot of supporting code in Haskell, though -- like parsers. Actually, parsers are really all I care about at present. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] compilation to C, not via-C
Hi Ryan, Nice to hear from another games industry coder on the Haskell lists :) Thanks, this is exactly the kind of detail I was after. I had heard rumours of the Evil Mangler but hadn't found a concrete reference to it before. This makes a lot of sense. Given this and the other helpful comments I tend to agree with Wren that a different compiler might be a better starting point. I'll follow up JHC and YHC in more depth and have a nose at Timber and Gambit-C as well. I'm pretty much undecided on whether haskell and games are going to play well at the moment. For me, it's very difficult to call, but I think it still looks interesting enough to pursue. I note there is at least a precedent set for functional languages in games by Naughty Dog's GOAL (http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp). As it happens, I tried to stir up the coders on the gd-algorithms mailing list recently to see how much interest there was in Haskell for games. There was a fair amount of cyber-tumbleweed :). Please feel free to chip in :) I agree the runtime is definitely where a big chunk of the problem is - particular garbage collection - but incidentally this is the bit I'm least worried about. It's all work, but I think there are ways of managing this predictably and efficiently. The 'clump and dump' approach the Eaton guys have used (and maybe region marking in JHC?) was one idea that had sprung to mind already - assuming it's the same one :). The monad-code approach sounds interesting as way of implementing small DSLs, but it sounds like it wouldn't scale up particular far? If this is true, I'm not sure how well approach would compete with existing scripting languages used in games. I'm not especially excited about using Haskell as a game scripting language. I want to find something to eat into the vast swath of C++ written for games that lua/python/unrealscript/homebrew scripting can't touch. Say, for instance, writing a procedural LOD generator. Cheers, Sam Martin ps. As a disclaimer - I'm emailing from my work address, but this is all just my own stuff and not necessarily representative of the views of Geomerics! We are definitely not about to ship Haskell-generated C to anyone ;). I'll reply off-list about Geomerics. -Original Message- From: Ryan Ingram [mailto:ryani.s...@gmail.com] Sent: 24 April 2009 18:14 To: Sam Martin Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] compilation to C, not via-C Sam, I work on graphics engine/pipeline for Spore at Electronic Arts, and I've had some similar thoughts as you. But I don't think this is the right path for games right now. The via C compiler does generate C code that it puts through GCC. There is a post-process step after the code is converted to assembly by GCC (see http://hackage.haskell.org/trac/ghc/wiki/Commentary/EvilMangler); a perl script rewrites the calling convention of all the functions to optimize for the code that GHC generates. From what I understand, performance is significantly worse without the mangler. So interoperability of the generated C-from-Haskell code directly with your C code is tricky at best. However, the generated code is only half the story. The other half is that you need the Haskell runtime to go with your program. This manages the garbage collector, multithreading-support, etc. As a middleware developer, I'm sure you're aware that it would be quite difficult to sell you need this big runtime with unpredictable memory requirements to your potential customers. That said, don't lose hope. Lots of Haskell development is being done for embedded systems, and other things at a similar level as to what you want. But what these systems generally do is write a custom monad that *outputs* code. You can look at some of the CUFP2008 talks about this topic (http://cufp.galois.com/2008/schedule.html); I recommend Controlling Hybrid Vehicles with Haskell. There was another talk about compiling Haskell into Excel spreadsheets for finance, but I can't seem to locate it right now. The basic strategy is to encapsulate all your operations in a monad, then write code generation that converts the results into C code which you can then compile and ship. Unless you're willing to make the jump to Haskell as a host language with FFI outcalls to native code, I think this is the right strategy right now. Good luck, and keep us informed how it goes. I expect to hear from you at CUFP next year :) -- ryan P.S. I saw some demos of Geomerics products; it looks pretty cool. What are you guys up to now? On Fri, Apr 24, 2009 at 9:36 AM, Sam Martin sam.mar...@geomerics.com wrote: Hi Everyone, It appears the GHC compiler (and other) compile Haskell *via-C* but not *to C*. I've never really understood why there isn't a C generation option, or why GDC ships with its own compulsory copy of gcc. I work in Games middleware, and am very interested in looking at how Haskell could help us. We
Re[2]: [Haskell-cafe] compilation to C, not via-C
Hello Sam, Saturday, April 25, 2009, 11:40:05 PM, you wrote: btw, are you seen MetaLua? it's pretty piece of software that makes Lua very FPish Hi Ryan, Nice to hear from another games industry coder on the Haskell lists :) Thanks, this is exactly the kind of detail I was after. I had heard rumours of the Evil Mangler but hadn't found a concrete reference to it before. This makes a lot of sense. Given this and the other helpful comments I tend to agree with Wren that a different compiler might be a better starting point. I'll follow up JHC and YHC in more depth and have a nose at Timber and Gambit-C as well. I'm pretty much undecided on whether haskell and games are going to play well at the moment. For me, it's very difficult to call, but I think it still looks interesting enough to pursue. I note there is at least a precedent set for functional languages in games by Naughty Dog's GOAL (http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp). As it happens, I tried to stir up the coders on the gd-algorithms mailing list recently to see how much interest there was in Haskell for games. There was a fair amount of cyber-tumbleweed :). Please feel free to chip in :) I agree the runtime is definitely where a big chunk of the problem is - particular garbage collection - but incidentally this is the bit I'm least worried about. It's all work, but I think there are ways of managing this predictably and efficiently. The 'clump and dump' approach the Eaton guys have used (and maybe region marking in JHC?) was one idea that had sprung to mind already - assuming it's the same one :). The monad-code approach sounds interesting as way of implementing small DSLs, but it sounds like it wouldn't scale up particular far? If this is true, I'm not sure how well approach would compete with existing scripting languages used in games. I'm not especially excited about using Haskell as a game scripting language. I want to find something to eat into the vast swath of C++ written for games that lua/python/unrealscript/homebrew scripting can't touch. Say, for instance, writing a procedural LOD generator. Cheers, Sam Martin ps. As a disclaimer - I'm emailing from my work address, but this is all just my own stuff and not necessarily representative of the views of Geomerics! We are definitely not about to ship Haskell-generated C to anyone ;). I'll reply off-list about Geomerics. -Original Message- From: Ryan Ingram [mailto:ryani.s...@gmail.com] Sent: 24 April 2009 18:14 To: Sam Martin Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] compilation to C, not via-C Sam, I work on graphics engine/pipeline for Spore at Electronic Arts, and I've had some similar thoughts as you. But I don't think this is the right path for games right now. The via C compiler does generate C code that it puts through GCC. There is a post-process step after the code is converted to assembly by GCC (see http://hackage.haskell.org/trac/ghc/wiki/Commentary/EvilMangler); a perl script rewrites the calling convention of all the functions to optimize for the code that GHC generates. From what I understand, performance is significantly worse without the mangler. So interoperability of the generated C-from-Haskell code directly with your C code is tricky at best. However, the generated code is only half the story. The other half is that you need the Haskell runtime to go with your program. This manages the garbage collector, multithreading-support, etc. As a middleware developer, I'm sure you're aware that it would be quite difficult to sell you need this big runtime with unpredictable memory requirements to your potential customers. That said, don't lose hope. Lots of Haskell development is being done for embedded systems, and other things at a similar level as to what you want. But what these systems generally do is write a custom monad that *outputs* code. You can look at some of the CUFP2008 talks about this topic (http://cufp.galois.com/2008/schedule.html); I recommend Controlling Hybrid Vehicles with Haskell. There was another talk about compiling Haskell into Excel spreadsheets for finance, but I can't seem to locate it right now. The basic strategy is to encapsulate all your operations in a monad, then write code generation that converts the results into C code which you can then compile and ship. Unless you're willing to make the jump to Haskell as a host language with FFI outcalls to native code, I think this is the right strategy right now. Good luck, and keep us informed how it goes. I expect to hear from you at CUFP next year :) -- ryan P.S. I saw some demos of Geomerics products; it looks pretty cool. What are you guys up to now? On Fri, Apr 24, 2009 at 9:36 AM, Sam Martin sam.mar...@geomerics.com wrote: Hi Everyone,
[Haskell-cafe] Re: Thread priority?
Christopher Lane Hinson wrote: Is there any interest or movement in developing thread priority or any other realtime support in Haskell? Right now, if I have tasks that need to be responsive in real time, even if the realtime needs are very soft, it seems that the only option is to try to ensure that at least one hardware thread is kept clear of any other activity. To be very useful to me, thread priority would not need to come with very strict guarantees, but there would need to be a way to make sure that `par` sparks and DPH inherit the priority of the sparking thread. In part I ask because I'm working on a small library to support a degree of cooperative task prioritization. Friendly, --Lane Yea, Thread priorities would be great. ATM you can multiplex IO at different OS-thread levels with IO completion ports etc, but it kinda sucks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Not in scope
Hi, I've defined the datatype: data Graph a b = Empty | Context a b : Graph a b and the function isEmpty :: Graph a b - Bool isEmpty Empty = True isEmpty _ = False and when I do a test run with the graph, ( [ ],2,'c',[(down,3)]) : Empty Haskell is bringing the message Not in scope: data constructor `:' Why is that so? Kind regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
I'd like this functionality, as well, but it doesn't exist, at least for Haskell. If you don't need a 100% pure functional language, and don't need the bells and whistles of the Haskell type system, you might be interested in SML -- a purer relative of the more widely-known Ocaml. There's a tool for converting SML to JavaScript: http://www.itu.dk/people/mael/smltojs/ It allows you to export SML functions so they can be called by JavaScript. Moreover, it has a reactive library built in, does pretty decent optimization, lets you manipulate the DOM, and is up to version 4.3.5. Haskell doesn't have anything close! Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Apr 25, 2009, at 11:53 AM, Jason Dusek wrote: I'd like to be able to translate Haskell to JavaScript. Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. For example, I'd like to write a nice parser in Haskell and then reuse it on the client side. No need to handle all the DOM events or implement multi-threading. Of course, the place to start is by reading the commentary. A little bit of browsing suggests some questions of strategy: . Maybe a new backend is not the right thing? All the backends seem to be for real computers with real instruction sets. . Is it better to just work on transforming Core into JS directly? It seems that External Core is still in limbo. . Some translations strike me as baffling in principle. For example, a value like `ones`: ones = 1 : ones We'd want to avoid most native JavaScript containers, it seems; however, we are then unable to leverage the speed of native containers. It's entirely possible that translating Haskell to JavaScript may turn out not to be the best idea; maybe it is better to have a type class for types (for example, `Parser Char`) to provide their own translators? The it would be straightforward to prevent translation of programs that use concurrency libs, native ops or `IO`. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Not in scope
siso dagbovie wrote: Hi, I've defined the datatype: data Graph a b = Empty | Context a b : Graph a b and the function isEmpty :: Graph a b - Bool isEmpty Empty = True isEmpty _ = False and when I do a test run with the graph, ( [ ],2,'c',[(down,3)]) : Empty Haskell is bringing the message Not in scope: data constructor `:' Why is that so? This works for me. Are the definitions in the same file? Otherwise, you will need to import your definition. All the best, -- Jochem Berndsen | joc...@functor.nl GPG: 0xE6FABFAB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
For parsers, there is also a LALR(1) generator - http://jscc.jmksf.com/ - though I have not had personal experience with it. --A ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Takusen, postgres and boolean fields
When I did SELECT statement I handled boolean field as String, and convert it to Bool. However when I did update or insert, I must bind those values, then takusen calls foreign postgres library and function with ? and values of proper type. So I cannot use neither Bool neither String in bindP. Instead of binding, I've used ugly hack : update some_table set some_boolean_field = ? ... [bindP True, ...] is replaced with (printf update some_table set some_boolean_field = '%s' ... t) [...] I really hate it and I hope there is better way to do it. On Sat, Apr 25, 2009 at 2:06 PM, Christoph Bauer c-bauer-olsbruec...@t-online.de wrote: Sasha Shipka xao...@gmail.com writes: Let say one has to do something similar to this: execDML $ cmdbind (sql update some_table set some_boolean_field = ? where ...) [bindP True, ...] When I do it, I have an error: DBError (42,804) 7 ERROR: 42804: column \some_boolean_field\ is of type boolean but expression is of type text ... I've noticed that when I read boolean fields from postgres it reads them as string t or f. So I also tried bindP t and had same error. Indeed, I also have such problems in my application [1] in SELECT boolean_field from TABLE. My workaround is: I defined a plpgsql function CREATE OR REPLACE FUNCTION HBoolean(v IN BOOLEAN) RETURNS TEXT AS $$ BEGIN IF v THEN RETURN 'True'; ELSE RETURN 'False'; END IF; END; $$ LANGUAGE plpgsql; and rewrite my query as SELECT HBoolean(boolean_field) from TABLE and takusen converts it to Bool. For performance reason you may convert from text to boolean (but keep bindP True). If there is a better solution, I'm also glad to know it. Christoph Bauer [1] http://www.communitystory.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Takusen, postgres and boolean fields
2009/4/25 Sasha Shipka xao...@gmail.com: When I did SELECT statement I handled boolean field as String, and convert it to Bool. However when I did update or insert, I must bind those values, then takusen calls foreign postgres library and function with ? and values of proper type. So I cannot use neither Bool neither String in bindP. Instead of binding, I've used ugly hack : update some_table set some_boolean_field = ? ... [bindP True, ...] is replaced with (printf update some_table set some_boolean_field = '%s' ... t) [...] I really hate it and I hope there is better way to do it. It should be pretty simple to add Bool instances to the class that handles bind variable marshalling. I'll look into it on Monday. As a workaround for now, can you use the CAST sql function to convert text to bool values in Postgres? Alistair ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
Interesting, thank you. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 115 - April 25, 2009
--- Haskell Weekly News http://sequence.complete.org/hwn/20090425 Issue 115 - April 25, 2009 --- Welcome to issue 115 of HWN, a newsletter covering developments in the [1]Haskell community. By all reports, the [2]5th Haskell Hackathon was a resounding success, with over 50 hackers present and many interesting Haskell projects worked on! Announcements darcs hacking sprint 2 and hac5 report. Eric Kow [3]sent out a link to a [4]report on the second darcs hacking sprint, held as part of the Haskell Hackathon. HPong-0.1.2: A simple OpenGL Pong game based on GLFW. R.A. Niemeijer [5]announced the release of [6]HPong, a simple Pong game implemented using OpenGL and GLFW. Hac5 roundup. Martijn van Steenbergen [7]reported on the 5th Haskell Hackathon. See the [8]wiki page for details, pictures, and links to blog posts. HTTP-4000.0.6. Sigbjorn Finne [9]announced a new release of the [10]HTTP package, which adds more robust handling of ill-formed cookies, and fixes a bug in normalization of certain proxy-bound requests. dataenc 0.12.1.0. Magnus Therning [11]announced version 0.12.1.0 of the [12]dataenc package. This version adds a bunch of new encodings, including xxencode, hexadecimal, quoted-printable, python escaping, and url encoding; and also fixed some bugs. list-tries-0.0 - first release. Matti Niemenmaa [13]announced the first public release of [14]list-tries, a library providing implementations of finite sets and maps for list keys using tries, both simple and of the Patricia kind. The data types are parametrized over the map type they use internally to store the child nodes: this allows extending them to support different kinds of key types or increasing efficiency. curl-1.3.5. Sigbjorn Finne [15]announced a new release of the [16]curl package, which provides Haskell bindings to libcurl. It works with ghc 6.10.2, taking into account the updated story on how to register Haskell-based finalizers. Runge-Kutta library -- solve ODEs. Uwe Hollerbach [17]announced a [18]Runge-Kutta library for numerically solving ordinary differential equations. funsat-0.6. Denis Bueno [19]announced version 0.6 of [20]funsat, a modern, DPLL-style SAT solver written in Haskell. Funsat solves formulas in conjunctive normal form and produces a total variable assignment for satisfiable problems. Version 0.6 adds a representation for logical circuits (and, or, not, onlyif, iff, if-then-else) supporting efficient conversion to CNF, and now uses the BSD3 license. control-monad-exception-0.1: Explicitly typed exceptions. Pepe Iborra [21]announced the [22]control-monad-exception package, which provides explicitly typed exceptions for Haskell. The type of a computation in the EM monad carries a list of the exceptions that the computation may throw. A exception is raised with 'throw', which in addition adds it to the type, and captured with 'catch', which correspondingly removes it from the type. Only safe computations (all exceptions handled) can escape from the monad. Haskell Implementers' Workshop 2009 (co-located with ICFP). Simon Marlow [23]issued a call for talks to be given at the ACM SIGPLAN [24]Haskell Implementers' Workshop, to be held on September 3 in Edinburgh, Scotland, in conjunction with [25]ICFP 2009. The proposal deadline in 15 June. The Haskell Implementers Workshop is a new workshop to be held alongside ICFP 2009 this year in Edinburgh, Scotland. There will be no proceedings; it is an informal gathering of people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure. persistent-map-0.0.0. Peter Robinson [26]announced the [27]persistent-map package, which provides a thread-safe (STM) frontend for finite map types together with a backend interface for persistent storage. A pragmatic Haskell .NET interop layer, 0.4.0. Sigbjorn Finne [28]announced a new release of [29]hs-dotnet, a Haskell .NET interop layer. It lets you access .NET functionality from Haskell and vice versa. The new version includes development done since the start of the year. Apart from rewriting the internals completely to put it all on a sounder footing, this release includes proper support for .NET generic types (classes and interfaces), mapping them naturally on to Haskell parameterized types. Utrecht Haskell Compiler (UHC) -- first release. atze [30]announced the first public release of the [31]Utrecht Haskell Compiler (UHC). UHC supports almost all Haskell98 features plus many experimental extensions. The compiler runs on MacOSX, Windows (cygwin), and various Unix flavors. Features include multiple backends
Re: [Haskell-cafe] Typing efficient folds
On Fri, Apr 24, 2009 at 06:52:09PM +, Keith Battocchi wrote: I'm trying to write some code to do folds on nested datatypes as in http://web.comlab.ox.ac.uk/people/Jeremy.Gibbons/publications/efolds.pdf but running into trouble getting things to typecheck. Given the types data Nest a = Nil | Cons(a, (Nest (Pair a))) type Pair a = (a,a) and the following function to map over pairs: pair f (a,b) = (f a, f b) the paper indicates that an efficient fold over a nest is defined as follows efold :: forall n m b. (forall a. n a) - (forall a . (m a, n (Pair a)) - n a) - (forall a. Pair (m a) - m (Pair a)) - (forall l z. (l b - m (z b)) - Nest (l b) - n (z b)) efold e f g h Nil = e efold e f g h (Cons(x, xs)) = f(h x, efold e f g (g . pair h) xs) However, when I try to compile this, I get the error Couldn't match expected type `l' against inferred type `z'. I'm new to Haskell so I'm probably missing something obvious, but this code looks to me like it ought to work. Any thoughts on what I'm doing wrong? Well, I'm pretty sure you're not 'missing something obvious'! I stared at this code for fifteen minutes and can't really figure out what's going on. If you change the 'z's in the type signature to 'l's, it type checks, but that may make the function slightly less general than intended. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 25 Apr 2009, at 21:09, Jason Dusek wrote: There will always be some people who prefer longer lines. The real issue is, how do we deal with the fundamental disagreement here? It's not like we can have both. Also those people who like long lines -- will they all agree to a long line length? Is there a fundamental disagreement here? There are those who are driven by an archaic standard from the width of the terminal screen, and there are those who are driven by the aesthetics of their code. As always, opinions on aesthetics differ slightly, but overall, everyone seems to mostly agree that we should try to keep lines short where possible, but lengthen then when needed. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Bamse-0.9.4, a Windows Installer generator
Hi, a new version of Bamse has been uploaded to hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bamse Bamse is a package and application for letting you quickly put together Windows Installers for your software projects/products from within the comforts of Haskell. New in this release is the support for generating MSIs from your Cabal projects, having them either be built from source or just have them be installed and registered at install-time. i.e., one-click installation of Cabal packages. See examples/Cabal.hs for a worked example of how to bundle up Cabal packages. I've found this functionality a bit useful, hope others do too. The new version also adds support for handling .NET assemblies. enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
It's surely more than enough to Haskell, Python, Perl, C++ and other very concise and expressive languages. But for Java and the likes it may well be just barely enough for a single *identifier* alone!! :P 2009/4/21 Dusan Kolar ko...@fit.vutbr.cz: Dear all, reading that according the several style guides, lines shouldn't be too long (longer than 78 characters). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
2009/4/21 Edward Kmett ekm...@gmail.com: I find a hard 80 character line length limit to be somewhat ridiculous in this day and age. I've long since revised my personal rule of thumb upwards towards 132, if only because I can still show two windows of that side by side with no worries, along with all the IDE browsing baggage, even on a fairly crippled laptop, and I've been able to have 132 columns since I picked up my first vt220 terminal in 1984 or so. Good catch. But here's another: modern day IDEs like Eclipse or Netbeans offer so friggin' many features all in-you-face at the same time that the puny window reserved for code may be very well in the 80-chars limit anyway. ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On Tue, Apr 21, 2009 at 9:52 AM, Neil Mitchell ndmitch...@gmail.com wrote: P.S. We really need such a well written style guide for haskell. Python has this nice PEP (Python Enhancement Proposals). Should we start making our own HEP? We have one: urchin.earth.li/~ian/style/haskell.html It should be called the Haskell Enhacement Language Proposals to get any attention. ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
2009/04/25 Thomas Davie tom.da...@gmail.com: 2009/04/25 Jason Dusek: There will always be some people who prefer longer lines. The real issue is, how do we deal with the fundamental disagreement here? It's not like we can have both. Also those people who like long lines -- will they all agree to a long line length? There are those who are driven by an archaic standard from the width of the terminal screen, and there are those who are driven by the aesthetics of their code. False dichotomy :) I am appalled on an aesthetic as well as practical level by lines that reach outside my terminal. It's not important, though -- that's something I've gotten used to; naturally if the standard had been 100 I would have gotten used to that. It's about following clear standards, not ignorance of the width of my screen. As always, opinions on aesthetics differ slightly, but overall, everyone seems to mostly agree... Eh? Since when did they mostly agree? The 200 column example we've seen brought out a lot of disagreement. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
