Re: [Haskell-cafe] Re: Why can't Haskell be faster?
Don Stewart [EMAIL PROTECTED] writes: goalieca: So in a few years time when GHC has matured we can expect performance to be on par with current Clean? So Clean is a good approximation to peak performance? If I remember the numbers, Clean is pretty close to C for most benchmarks, so I guess it is fair to say it is a good approximation to practical peak performance. Which proves that it is possible to write efficient low-level code in Clean. And remember usually Haskell is competing against 'high level' languages like python for adoption, where we're 5-500x faster anyway... Unfortunately, they replaced line counts with bytes of gzip'ed code -- while the former certainly has its problems, I simply cannot imagine what relevance the latter has (beyond hiding extreme amounts of repetitive boilerplate in certain languages). When we compete against Python and its ilk, we do so for programmer productivity first, and performance second. LOC was a nice measure, and encouraged terser and more idiomatic programs than the current crop of performance-tweaked low-level stuff. BTW, Python isn't so bad, performance wise. Much of what I do consists of reading some files, building up some hashes (associative arrays or finite maps, depending on where you come from :-), and generating some output. Python used to do pretty well here compared to Haskell, with rather efficient hashes and text parsing, although I suspect ByteString IO and other optimizations may have changed that now. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Why can't Haskell be faster?
Hello Lennart, Thursday, November 1, 2007, 2:45:49 AM, you wrote: But yeah, a code generator at run time is a very cool idea, and one that has been studied, but not enough. vm-based languages (java, c#) has runtimes that compile bytecode to the native code at runtime -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Why can't Haskell be faster?
Yes, that's right. We'll be doing a lot more work on the code generator in the rest of this year and 2008. Here we includes Norman Ramsey and John Dias, as well as past interns Michael Adams and Ben Lippmeier, so we have real muscle! Simon | I don't think the register allocater is being rewritten so much as it is | being written: | | From talking to Ben, who rewrote the register allocator over the | summer, he said that the new graph based register allocator is pretty | good. The thing that is holding it back is the CPS conversion bit, | which was also being rewritten over the summer, but didn't get | finished. I think these are both things which are likely to be done | for 6.10. | | Thanks | | Neil | ___ | 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] Re: Why can't Haskell be faster?
I assume the reason the switched away from LOC is to prevent programmers artificially reducing their LOC count, e.g. by using a = 5; b = 6; rather than a = 5; b = 6; in languages where newlines aren't syntactically significant. When gzipped, I guess that the ;\n string will be represented about as efficiently as just the single semi-colon. On 01/11/2007, Ketil Malde [EMAIL PROTECTED] wrote: Don Stewart [EMAIL PROTECTED] writes: goalieca: So in a few years time when GHC has matured we can expect performance to be on par with current Clean? So Clean is a good approximation to peak performance? If I remember the numbers, Clean is pretty close to C for most benchmarks, so I guess it is fair to say it is a good approximation to practical peak performance. Which proves that it is possible to write efficient low-level code in Clean. And remember usually Haskell is competing against 'high level' languages like python for adoption, where we're 5-500x faster anyway... Unfortunately, they replaced line counts with bytes of gzip'ed code -- while the former certainly has its problems, I simply cannot imagine what relevance the latter has (beyond hiding extreme amounts of repetitive boilerplate in certain languages). When we compete against Python and its ilk, we do so for programmer productivity first, and performance second. LOC was a nice measure, and encouraged terser and more idiomatic programs than the current crop of performance-tweaked low-level stuff. BTW, Python isn't so bad, performance wise. Much of what I do consists of reading some files, building up some hashes (associative arrays or finite maps, depending on where you come from :-), and generating some output. Python used to do pretty well here compared to Haskell, with rather efficient hashes and text parsing, although I suspect ByteString IO and other optimizations may have changed that now. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ 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 libraries for computer vision
I have included in the web page a reference to this earlier work, in which all the key ideas were already present. For example, using ordinary Haskell functions to process an infinite list containing the whole image sequence taken by the camera... We can write extremely concise and powerful camera combinators. Haskell is amazing. Thanks! Alberto On Tuesday 16 October 2007 16:11, Paul Hudak wrote: Henning Thielemann wrote: On Mon, 15 Oct 2007, Don Stewart wrote: http://alberrto.googlepages.com/easyvision An experimental Haskell system for fast prototyping of computer vision and image processing applications. Looks ridiculously cool. Image processing with Haskell - really interesting. I know of an older approach: Prototyping Real-Time Vision Systems: An Experiment in DSL Design by Alastair Reid et.al. Yes, see: http://haskell.org/yale/papers/padl01-vision/index.html http://haskell.org/yale/papers/icse99/index.html -Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] virtual lambda
Hi, I think that you may like the following demo of a simple computer vision application powered by Haskell: http://covector.blogspot.com/2007/10/functional-augmented-reality.html Alberto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
Bernie wrote: I discussed this with Rinus Plasmeijer (chief designer of Clean) a couple of years ago, and if I remember correctly, he said that the native code generator in Clean was very good, and a significant reason why Clean produces (relatively) fast executables. I think he said that they had an assembly programming guru on their team. (Apologies to Rinus if I am mis-remembering the conversation). That guru would be John van Groningen... If I understood correctly, and I think I did, John is now working on a Haskell front end for the Clean compiler---which is actually quite interesting in the light of the present discussion. Cheers, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
Neil wrote: The Clean and Haskell languages both reduce to pretty much the same Core language, with pretty much the same type system, once you get down to it - so I don't think the difference between the performance is a language thing, but it is a compiler thing. The uniqueness type stuff may give Clean a slight benefit, but I'm not sure how much they use that in their analyses. From what I know from the Nijmegen team, having the uniqueness information available and actually using it for code generation does allow for an impressive speed-up. The thing is: in principle, there is, I think, no reason why we can't do the same thing for Haskell. Of course, the Clean languages exposes uniqueness types at its surface level, but that is in no way essential to the underlying analysis. Exposing uniqueness types is, in that sense, just an alternative to monadic encapsulation of side effects. So, a Haskell compiler could just implement a uniqueness analysis under the hood and use the results for generating code that does in-place updates that are guaranteed to maintain referential transparency. Interestingly---but now I'm shamelessly plugging a paper of Jurriaan Hage, Arie Middelkoop, and myself, presented at this year's ICFP [*]---such an analysis is very similar to sharing analysis, which may be used by compilers for lazy languages to avoid unnecessary thunk updates. Cheers, Stefan [*] Jurriaan Hage, Stefan Holdermans, and Arie Middelkoop. A generic usage analysis with subeffect qualifiers. In Ralf Hinze and Norman Ramsey, editors, Proceedings of the 12th ACM SIGPLAN International Conference on Functional Programming, ICFP 2007, Freiburg, Germany, October 1–-3, pages 235–-246. ACM Press, 2007. http://doi.acm.org/ 10.1145/1291151.1291189. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
On 01/11/2007, Simon Peyton-Jones [EMAIL PROTECTED] wrote: Yes, that's right. We'll be doing a lot more work on the code generator in the rest of this year and 2008. Here we includes Norman Ramsey and John Dias, as well as past interns Michael Adams and Ben Lippmeier, so we have real muscle! That's very good to know. I wonder where could I read more about current state of the art on Haskell compilation techniques and about the implementation of ghc in general? Is there a book on it or maybe some group of papers that would aid me to understand it? Cheers, Paulo Matos Simon | I don't think the register allocater is being rewritten so much as it is | being written: | | From talking to Ben, who rewrote the register allocator over the | summer, he said that the new graph based register allocator is pretty | good. The thing that is holding it back is the CPS conversion bit, | which was also being rewritten over the summer, but didn't get | finished. I think these are both things which are likely to be done | for 6.10. | | Thanks | | Neil | ___ | 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 -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Why can't Haskell be faster?
http://hackage.haskell.org/trac/ghc/wiki/Commentary | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paulo J. Matos | Sent: 01 November 2007 13:42 | To: Simon Peyton-Jones | Cc: Neil Mitchell; Stefan O'Rear; [EMAIL PROTECTED]; haskell-cafe@haskell.org | Subject: Re: [Haskell-cafe] Re: Why can't Haskell be faster? | | On 01/11/2007, Simon Peyton-Jones [EMAIL PROTECTED] wrote: | Yes, that's right. We'll be doing a lot more work on the code generator in the rest of this year and 2008. | Here we includes Norman Ramsey and John Dias, as well as past interns Michael Adams and Ben Lippmeier, so we | have real muscle! | | | That's very good to know. I wonder where could I read more about | current state of the art on Haskell compilation techniques and about | the implementation of ghc in general? | Is there a book on it or maybe some group of papers that would aid me | to understand it? | | Cheers, | | Paulo Matos | | Simon | | | I don't think the register allocater is being rewritten so much as it is | | being written: | | | | From talking to Ben, who rewrote the register allocator over the | | summer, he said that the new graph based register allocator is pretty | | good. The thing that is holding it back is the CPS conversion bit, | | which was also being rewritten over the summer, but didn't get | | finished. I think these are both things which are likely to be done | | for 6.10. | | | | Thanks | | | | Neil | | ___ | | 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 | | | | | | -- | Paulo Jorge Matos - pocm at soton.ac.uk | http://www.personal.soton.ac.uk/pocm | PhD Student @ ECS | University of Southampton, UK ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Semantics of uniqueness types for IO (Was: Why can't Haskell be faster?)
Stefan Holdermans wrote: Exposing uniqueness types is, in that sense, just an alternative to monadic encapsulation of side effects. While *World - (a, *World) seems to work in practice, I wonder what its (denotational) semantics are. I mean, the two programs loop, loop' :: *World - ((),*World) loop w = loop w loop' w = let (_,w') = print x w in loop' w' both have denotation _|_ but are clearly different in terms of side effects. (The example is from SPJs awkward-squad tutorial.) Any pointers? Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Semantics of uniqueness types for IO (Was: Why can't Haskell be faster?)
Hi there, I'm new here, so sorry if I'm stating the obvious. On Nov 1, 2007 2:46 PM, apfelmus [EMAIL PROTECTED] wrote: Stefan Holdermans wrote: Exposing uniqueness types is, in that sense, just an alternative to monadic encapsulation of side effects. While *World - (a, *World) seems to work in practice, I wonder what its (denotational) semantics are. I mean, the two programs loop, loop' :: *World - ((),*World) loop w = loop w loop' w = let (_,w') = print x w in loop' w' both have denotation _|_ but are clearly different in terms of side effects. (The example is from SPJs awkward-squad tutorial.) Any pointers? For side-effecting program one has to consider bisimilarity. It's common that semantically equivalent (under operational or denotational semantics) behave differently with regard to side-effects (i/o) - i.e. they are not bisimilar. http://en.wikipedia.org/wiki/Bisimulation Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
Ketil Malde wrote: Python used to do pretty well here compared to Haskell, with rather efficient hashes and text parsing, although I suspect ByteString IO and other optimizations may have changed that now. It still does just fine. For typical munge a file with regexps, lists, and maps tasks, Python and Perl remain on par with comparably written Haskell. This because the scripting-level code acts as a thin layer of glue around I/O, regexps, lists, and dicts, all of which are written in native code. The Haskell regexp libraries actually give us something of a leg down with respect to Python and Perl. The aggressive use of polymorphism in the return type of (=~) makes it hard to remember which of the possible return types gives me what information. Not only did I write a regexp tutorial to understand the API in the first place, I have to reread it every time I want to match a regexp. A suitable solution would be a return type of RegexpMatch a = Maybe a (to live alongside the existing types, but aiming to become the one that's easy to remember), with appropriate methods on a, but I don't have time to write up a patch. b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
On 10/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I didn't keep a copy, but if someone wants to retrieve it from the Google cache and put it on the new wiki (under the new licence, of course), please do so. Cheers, Andrew Bromage Done: http://www.haskell.org/haskellwiki/RuntimeCompilation . Please update it as needed. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] do/if/then/else confusion
Another newbie question, but I can't seem to find any answers on the web... Can someone tell me what's wrong with this? import qualified System.Posix.Directory as PD readdirAll :: PD.DirStream - IO [String] readdirAll d = do dir - PD.readDirStream d if dir == then return [] else rest - readdirAll d return (dir:rest) Compiling with GHC 6.6.1 gives me the not-very-useful message Parse error in pattern, pointing to the i of if. I've tried all kinds of alternative indentations (including indenting the else more), bracketings etc, but nothing helps. Thanks David -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do/if/then/else confusion
On Nov 1, 2007, at 13:47 , David Carter wrote: else rest - readdirAll d You need another do here to use the - syntax. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: do/if/then/else confusion
David Carter wrote: Another newbie question, but I can't seem to find any answers on the web... Just figured it out myself ... I need a do after the else, of course. (But I still think the error message is less than helpful!). Sorry for the bandwidth David Can someone tell me what's wrong with this? import qualified System.Posix.Directory as PD readdirAll :: PD.DirStream - IO [String] readdirAll d = do dir - PD.readDirStream d if dir == then return [] else rest - readdirAll d return (dir:rest) Compiling with GHC 6.6.1 gives me the not-very-useful message Parse error in pattern, pointing to the i of if. I've tried all kinds of alternative indentations (including indenting the else more), bracketings etc, but nothing helps. Thanks David -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Slightly off-topic
Hi folks Apologies for the off-topic post. If anyone knows anything about the rules of proof by deduction and quantifiers I'd be grateful for some assistance. Much obliged, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Slightly off-topic
prstanley: Hi folks Apologies for the off-topic post. If anyone knows anything about the rules of proof by deduction and quantifiers I'd be grateful for some assistance. Much obliged, http://www.cs.cmu.edu/~rwh/plbook/ Is an excellent introduction to reasoning about programming languages. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Regex API ideas
Hi Bryan, I wrote the current regex API, so your suggestions are interesting to me. The also goes for anyone else's regex API opinions, of course. Bryan O'Sullivan wrote: Ketil Malde wrote: Python used to do pretty well here compared to Haskell, with rather efficient hashes and text parsing, although I suspect ByteString IO and other optimizations may have changed that now. It still does just fine. For typical munge a file with regexps, lists, and maps tasks, Python and Perl remain on par with comparably written Haskell. This because the scripting-level code acts as a thin layer of glue around I/O, regexps, lists, and dicts, all of which are written in native code. The Haskell regexp libraries actually give us something of a leg down with respect to Python and Perl. True, the pure Haskell library is not as fast as a C library. In particular, the current regex-tdfa handles lazy bytestring in a sub-optimal manner. This may eventually be fixed. But the native code libraries have also been wrapped in the same API, and they are quite fast when combined with strict ByteStrings. The aggressive use of polymorphism in the return type of (=~) makes it hard to remember which of the possible return types gives me what information. Not only did I write a regexp tutorial to understand the API in the first place, I have to reread it every time I want to match a regexp. The (=~) operator uses many return types provided by the instances of RegexContext. These are all thin wrappers around the unpolymorphic return types of the RegexLike class. So (=~) could be avoided altogether, or another API created. A suitable solution would be a return type of RegexpMatch a = Maybe a (to live alongside the existing types, but aiming to become the one that's easy to remember), with appropriate methods on a, but I don't have time to write up a patch. b The (=~~) is the monadic wrapper for (=~) to allow for different failure behaviors. So using (=~~) with Maybe is already possible, and gives Nothing whenever there are zero matches. But more interesting to me is learning what API you would like to see. What would you like the code that uses the API to be? Could you sketch either the definition or usage of your RegexMatch class suggestion? I don't use my own regex API much, so external feedback and ideas would be wonderful. -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Disjunctive Normal Form
I am trying to rewrite sentences in a logical language into DNF, and wonder if someone would point out where I'm going wrong. My dim understanding of it is that I need to move And and Not inwards and Or out, but the function below fails, for example: dnf (Or (And A B) (Or (And C D) E)) And (Or A (And (Or C E) (Or D E))) (Or B (And (Or C E) (Or D E))) data LS = Var | Not LS | And LS LS | Or LS LS --convert sentences to DNF dnf :: LS - LS dnf (And (Or s1 s2) s3) = Or (And (dnf s1) (dnf s3)) (And (dnf s2) (dnf s3)) dnf (And s1 (Or s2 s3)) = Or (And (dnf s1) (dnf s2)) (And (dnf s1) (dnf s3)) dnf (And s1 s2) = And (dnf s1) (dnf s2) dnf (Or s1 s2) = Or (dnf s1) (dnf s2) dnf (Not (Not d)) = dnf d dnf (Not (And s1 s2)) = Or (Not (dnf s1)) (Not (dnf s2)) dnf (Not (Or s1 s2))= And (Not (dnf s1)) (Not (dnf s2)) dnf s = s Thanks, Jim -- View this message in context: http://www.nabble.com/Disjunctive-Normal-Form-tf4733248.html#a13534567 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] Regex API ideas
ChrisK wrote: The Haskell regexp libraries actually give us something of a leg down with respect to Python and Perl. True, the pure Haskell library is not as fast as a C library. Actually, I wasn't referring to the performance of the libraries, merely to the non-stick nature of the API. For my purposes, regex-pcre performs well (though I owe you some patches to make it, and other regex back ends, compile successfully out of the box). But more interesting to me is learning what API you would like to see. What would you like the code that uses the API to be? Python's regexp API is pretty easy to use, and also to remember. Here's what it does for match objects. http://docs.python.org/lib/match-objects.html b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Disjunctive Normal Form
A good way to approach this is data-structure-driven programming. You want a data structure which represents, and can _only_ represent, propositions in DNF. So: data Term = Pos Var | Neg Var type Conj = [Term] type DNF = [Conj] Then write: dnf :: LS - DNF The inductive definition of dnf is straightforward given this output type... Luke On 11/1/07, Jim Burton [EMAIL PROTECTED] wrote: I am trying to rewrite sentences in a logical language into DNF, and wonder if someone would point out where I'm going wrong. My dim understanding of it is that I need to move And and Not inwards and Or out, but the function below fails, for example: dnf (Or (And A B) (Or (And C D) E)) And (Or A (And (Or C E) (Or D E))) (Or B (And (Or C E) (Or D E))) data LS = Var | Not LS | And LS LS | Or LS LS --convert sentences to DNF dnf :: LS - LS dnf (And (Or s1 s2) s3) = Or (And (dnf s1) (dnf s3)) (And (dnf s2) (dnf s3)) dnf (And s1 (Or s2 s3)) = Or (And (dnf s1) (dnf s2)) (And (dnf s1) (dnf s3)) dnf (And s1 s2) = And (dnf s1) (dnf s2) dnf (Or s1 s2) = Or (dnf s1) (dnf s2) dnf (Not (Not d)) = dnf d dnf (Not (And s1 s2)) = Or (Not (dnf s1)) (Not (dnf s2)) dnf (Not (Or s1 s2))= And (Not (dnf s1)) (Not (dnf s2)) dnf s = s Thanks, Jim -- View this message in context: http://www.nabble.com/Disjunctive-Normal-Form-tf4733248.html#a13534567 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
Unfortunately, they replaced line counts with bytes of gzip'ed code -- while the former certainly has its problems, I simply cannot imagine what relevance the latter has (beyond hiding extreme amounts of repetitive boilerplate in certain languages). Sounds pretty fair to me. Programming is a job of compressing a solution set. Excessive boilerplate might mean that you have to type a lot, but doesn't necessarily mean that you have to think a lot. I think the previous line count was skewed in favor of very terse languages like haskell, especially languages that let you put many ideas onto a single line. At the very least there should be a constant factor applied when comparing haskell line counts to python line counts, for example. (python has very strict rules about putting multiple things on the same line). Obviously no simple measure is going to satisfy everyone, but I think the gzip measure is more even handed across a range of languages. It probably more closely aproximates the amount of mental effort and hence time it requires to construct a program (ie. I can whip out a lot of lines of code in python very quickly, but it takes a lot more of them to do the same work as a single, dense, line of haskell code). When we compete against Python and its ilk, we do so for programmer productivity first, and performance second. LOC was a nice measure, and encouraged terser and more idiomatic programs than the current crop of performance-tweaked low-level stuff. The haskell entries to the shootout are very obviously written for speed and not elegance. If you want to do better on the LoC measure, you can definitely do so (at the expense of speed). -k Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: do/if/then/else confusion
On 11/1/07, David Carter [EMAIL PROTECTED] wrote: (But I still think the error message is less than helpful!). Maybe a bug should be filled? -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
On 01/11/2007, Tim Newsham [EMAIL PROTECTED] wrote: Unfortunately, they replaced line counts with bytes of gzip'ed code -- while the former certainly has its problems, I simply cannot imagine what relevance the latter has (beyond hiding extreme amounts of repetitive boilerplate in certain languages). Sounds pretty fair to me. Programming is a job of compressing a solution set. Excessive boilerplate might mean that you have to type a lot, but doesn't necessarily mean that you have to think a lot. I think the previous line count was skewed in favor of very terse languages like haskell, especially languages that let you put many ideas onto a single line. At the very least there should be a constant factor applied when comparing haskell line counts to python line counts, for example. (python has very strict rules about putting multiple things on the same line). Obviously no simple measure is going to satisfy everyone, but I think the gzip measure is more even handed across a range of languages. It probably more closely aproximates the amount of mental effort and hence time it requires to construct a program (ie. I can whip out a lot of lines of code in python very quickly, but it takes a lot more of them to do the same work as a single, dense, line of haskell code). When we compete against Python and its ilk, we do so for programmer productivity first, and performance second. LOC was a nice measure, and encouraged terser and more idiomatic programs than the current crop of performance-tweaked low-level stuff. The haskell entries to the shootout are very obviously written for speed and not elegance. If you want to do better on the LoC measure, you can definitely do so (at the expense of speed). Personally I think syntactic noise is highly distracting, and semantic noise is even worse! Gzip'd files don't show you that one language will require you to do 90% book-keeping for 10% algorithm, while the other lets you get on with the job, it may make it look as if both languages are roughly equally good at letting the programmer focus on the important bits. I'm not sure what metric to use, but actively disgusing noisy languages using compression sure doesn't seem like anywhere close to the ideal. Token count would be good, but then we'd need a parser for each language, which is quite a bit of work to do... -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why can't Haskell be faster?
On 10/31/07, Paulo J. Matos [EMAIL PROTECTED] wrote: Hello all, I, along with some friends, have been looking to Haskell lately. I'm very happy with Haskell as a language, however, a friend sent me the link: http://shootout.alioth.debian.org/gp4/ Careful: it's worse than you think. Many of the solutions to the shootout test are using imperative Haskell. Real functional Haskell performs significantly slower. (Orders of magnitude) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Disjunctive Normal Form
Jim, Lukes suggestion is a good one, and should help focus you on the syntactic constraints of DNF. A property that your dnf function should have is that the right-hand side of each case should yield a DNF formula. Take, for example, dnf (And s1 s2) = And (dnf s1) (dnf s2) Does And'ing two DNF formulas together yield a DNF? Regards, Chris On 11/1/07, Luke Palmer [EMAIL PROTECTED] wrote: A good way to approach this is data-structure-driven programming. You want a data structure which represents, and can _only_ represent, propositions in DNF. So: data Term = Pos Var | Neg Var type Conj = [Term] type DNF = [Conj] Then write: dnf :: LS - DNF The inductive definition of dnf is straightforward given this output type... Luke On 11/1/07, Jim Burton [EMAIL PROTECTED] wrote: I am trying to rewrite sentences in a logical language into DNF, and wonder if someone would point out where I'm going wrong. My dim understanding of it is that I need to move And and Not inwards and Or out, but the function below fails, for example: dnf (Or (And A B) (Or (And C D) E)) And (Or A (And (Or C E) (Or D E))) (Or B (And (Or C E) (Or D E))) data LS = Var | Not LS | And LS LS | Or LS LS --convert sentences to DNF dnf :: LS - LS dnf (And (Or s1 s2) s3) = Or (And (dnf s1) (dnf s3)) (And (dnf s2) (dnf s3)) dnf (And s1 (Or s2 s3)) = Or (And (dnf s1) (dnf s2)) (And (dnf s1) (dnf s3)) dnf (And s1 s2) = And (dnf s1) (dnf s2) dnf (Or s1 s2) = Or (dnf s1) (dnf s2) dnf (Not (Not d)) = dnf d dnf (Not (And s1 s2)) = Or (Not (dnf s1)) (Not (dnf s2)) dnf (Not (Or s1 s2))= And (Not (dnf s1)) (Not (dnf s2)) dnf s = s Thanks, Jim -- View this message in context: http://www.nabble.com/Disjunctive-Normal-Form-tf4733248.html#a13534567 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 ___ 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: Re[2]: [Haskell-cafe] Re: Why can't Haskell be faster?
Yes, of course. But they don't do partial evaluation. On 11/1/07, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello Lennart, Thursday, November 1, 2007, 2:45:49 AM, you wrote: But yeah, a code generator at run time is a very cool idea, and one that has been studied, but not enough. vm-based languages (java, c#) has runtimes that compile bytecode to the native code at runtime -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ 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] Re: Hiding side effects in a data structure
On 10/26/07, John Meacham [EMAIL PROTECTED] wrote: Heh, the plethora of pdf papers on Haskell is part of what originally brought me to respect it. Something about that metafont painted cmr just makes me giddy as a grad student. A beautifully rendered type inference table is a masterful work of art. Did I mention I was a little odd? I am sure I did. http://xkcd.com/242/ Actually, yeah I kindof agree. It's quite interesting to see a language developed using rigorous, formal mathematical principles. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Semantics of uniqueness types for IO (Was: Why can't Haskell be faster?)
One can certainly use an operational semantics such as bisimulation, but you don't have to abandon denotational semantics. The trick is to make output part of the "final answer". For a conventional imperative language one could define, for example, a (lifted, recursive) domain: Answer = Terminate + (String x Answer) and then define a semantic function "meaning", say, such that: meaning loop = _|_ meaning loop' = "x", "x", ... In other words, loop denotes bottom, whereas loop' denotes the infinite sequence of "x"s. There would typically also be a symbol to denote proper termination, perhaps . A good read on this stuff is Reynolds book "Theories of Programming Languages", where domain constructions such as the above are called "resumptions", and can be made to include input as well. In the case of Clean, programs take as input a "World" and generate a "World" as output. One of the components of that World would presumably be "standard output", and that component's value would be _|_ in the case of loop, and "x", "x", ... in the case of loop'. Another part of the World might be a file system, a printer, a missile firing, and so on. Presumably loop and loop' would not affect those parts of the World. If returning one World is semantically problematical, one might also devise a semantics where the result is a sequence of Worlds. -Paul Arnar Birgisson wrote: Hi there, I'm new here, so sorry if I'm stating the obvious. On Nov 1, 2007 2:46 PM, apfelmus [EMAIL PROTECTED] wrote: Stefan Holdermans wrote: Exposing uniqueness types is, in that sense, just an alternative to monadic encapsulation of side effects. While *World - (a, *World) seems to work in practice, I wonder what its (denotational) semantics are. I mean, the two programs loop, loop' :: *World - ((),*World) loop w = loop w loop' w = let (_,w') = print "x" w in loop' w' both have denotation _|_ but are clearly different in terms of side effects. (The example is from SPJs awkward-squad tutorial.) Any pointers? For side-effecting program one has to consider bisimilarity. It's common that semantically equivalent (under operational or denotational semantics) behave differently with regard to side-effects (i/o) - i.e. they are not bisimilar. http://en.wikipedia.org/wiki/Bisimulation Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hiding side effects in a data structure
Hugh Perkins [EMAIL PROTECTED] writes: On 10/26/07, John Meacham [EMAIL PROTECTED] wrote: Heh, the plethora of pdf papers on Haskell is part of what originally brought me to respect it. Something about that metafont painted cmr just makes me giddy as a grad student. A beautifully rendered type inference table is a masterful work of art. Did I mention I was a little odd? I am sure I did. http://xkcd.com/242/ Actually, yeah I kindof agree. It's quite interesting to see a language developed using rigorous, formal mathematical principles. Lest anyone think otherwise, I most thoroughly approve of Haskell relying on rigorous foundations. I just want the foundations to be easy to inspect! -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do/if/then/else confusion
David Carter wrote:
readdirAll :: PD.DirStream - IO [String]
readdirAll d =
do dir - PD.readDirStream d
if dir ==
then return []
else rest - readdirAll d
return (dir:rest)
Compiling with GHC 6.6.1 gives me the not-very-useful message Parse
error in pattern, pointing to the i of if. I've tried all kinds of
You've worked out the answer, and that's fine. You also said later in
the thread that the error message isn't very good. (Which I agree with)
Perhaps it might help to understand why you do, in fact, get that
strange message. It might illuminate why it's quite so hard to get good
error messages in haskell :-( [*]
When you reach the i in if, ghc knows that you are in a do
expression. A do expression is a sequence of statements separated by
semicolons (or layout, standing in for semicolons). When we decode the
layout, everything indented further is part of the same statement. So
in particular, your code parses as
do {
dir - PD.readDirStream d ;
if dir == then return [] else rest - readdirAll d return (dir:rest);
}
The first statement in the do block is fine.
The second is the problem. Now statements are of two basic forms. They
either have binders, or not. They are either
foo - expr
or simply
expr
Since the second line contains the magic -, it must be the former. So
what you have is 'if dir == then return [] else rest' being the
'foo', i.e. the bit before the -.
Now what is *supposed* to come before - is a pattern (normally a
variable name, which is a simple case of a pattern). if is a keyword
which is not permitted to be a variable name or part of a pattern.
Hence parse error in pattern.
Not sure if that is at all edifying, but it was an interesting exercise
to write it...
Jules
* there are two reasons it's really hard to write a haskell compiler
with good error messages. (1) the layout rule. (2) the use of exotic
type system tricks like type classes to achieve elegant syntax. I don't
mean to say that the developers of haskell compilers shouldn't keep
trying though!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Disjunctive Normal Form
It's much much easier to work with n-ary than binary. It's also easier to define disjunctive normal form by mutual recursion with conjunctive normal form. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hiding side effects in a data structure
On Thu, 2007-11-01 at 21:42 +, Jon Fairbairn wrote: Hugh Perkins [EMAIL PROTECTED] writes: On 10/26/07, John Meacham [EMAIL PROTECTED] wrote: Heh, the plethora of pdf papers on Haskell is part of what originally brought me to respect it. Something about that metafont painted cmr just makes me giddy as a grad student. A beautifully rendered type inference table is a masterful work of art. Did I mention I was a little odd? I am sure I did. http://xkcd.com/242/ Actually, yeah I kindof agree. It's quite interesting to see a language developed using rigorous, formal mathematical principles. Lest anyone think otherwise, I most thoroughly approve of Haskell relying on rigorous foundations. I just want the foundations to be easy to inspect! It doesn't strike me that math in HTML is easier to inspect than PDF. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hiding side effects in a data structure
On 21/10/2007, Jon Fairbairn [EMAIL PROTECTED] wrote: No, they (or at least links to them) typically are that bad! Mind you, as far as fragment identification is concerned, so are a lot of html pages. But even if the links do have fragment ids, pdfs still impose a significant overhead: I don't want stuff swapped out just so that I can run a pdf viewer; a web browser uses up enough resources as it is. And will Hoogle link into pdfs? Swapped out!? What PDF viewer are you running on what machine? Currently, with a 552 page book open (Hatcher's algebraic topology), my PDF viewer (Evince) uses about 36MiB, which is around 3.6% of my available memory, a rather pedestrian 1 GiB. Other documents produce very similar results. The largest I was able to make it with a PDF which wasn't pathologically constructed was about 42MiB, with a PDF that had lots of diagrams. Firefox uses about twice that on an average day. If your PDF viewer uses significantly more than that, I recommend looking for a new one. ;) - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is there a module for multivariate linear regression?
I am looking for a Haskell module that will do multivariate linear regression. Does someone know which module will do it? That is, the equivalent of Perl's Statistics::Regression.pm. http://search.cpan.org/~itub/PerlMol-0.35_00.ppm/lib/Statistics/Regression.pm Thanks, Steve -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Disjunctive Normal Form
Hey folks, On Nov 1, 2007 6:41 PM, Luke Palmer [EMAIL PROTECTED] wrote: A good way to approach this is data-structure-driven programming. You want a data structure which represents, and can _only_ represent, propositions in DNF. So: data Term = Pos Var | Neg Var type Conj = [Term] type DNF = [Conj] Then write: dnf :: LS - DNF The inductive definition of dnf is straightforward given this output type... Jim, if you don't want to see an attempt at a solution, don't read further. I'm learning too and found this an interesting problem. Luke, is this similar to what you meant? data LS = Var String | Not LS | And LS LS | Or LS LS deriving Show data Term = Pos String | Neg String deriving Show type Conj = [Term] type DNF = [Conj] dnf :: LS - DNF dnf (Var s) = [[Pos s]] dnf (Or l1 l2) = (dnf l1) ++ (dnf l2) dnf (And l1 l2) = [t1 ++ t2 | t1 - dnf l1, t2 - dnf l2] dnf (Not (Not d)) = dnf d dnf (Not (And l1 l2)) = (dnf $ Not l1) ++ (dnf $ Not l2) dnf (Not (Or l1 l2)) = [t1 ++ t2 | t1 - dnf $ Not l1, t2 - dnf $ Not l2] dnf (Not (Var s)) = [[Neg s]] -- test cases x = (Or (And (Var A) (Var B)) (Or (And (Not $ Var C) (Var D)) (Var E))) y = (Not (And (Var A) (Var B))) z = (Not (And (Not y) y)) Also, is it correct? cheers, Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Disjunctive Normal Form
On 11/2/07, Luke Palmer [EMAIL PROTECTED] wrote: On 11/1/07, Arnar Birgisson [EMAIL PROTECTED] wrote: dnf :: LS - DNF dnf (Var s) = [[Pos s]] dnf (Or l1 l2) = (dnf l1) ++ (dnf l2) dnf (And l1 l2) = [t1 ++ t2 | t1 - dnf l1, t2 - dnf l2] dnf (Not (Not d)) = dnf d dnf (Not (And l1 l2)) = (dnf $ Not l1) ++ (dnf $ Not l2) dnf (Not (Or l1 l2)) = [t1 ++ t2 | t1 - dnf $ Not l1, t2 - dnf $ Not l2] These two are doing a little extra work: dnf (Not (And l1 l2)) = dnf (Or (Not l1) (Not l2)) dnf (Not (Or l1 l2)) = dnf (And (Not l1) (Not l2)) I should clarify. I meant that *you* were doing a little extra work, by re-implementing that logic for the not cases. I'm a fan of only implementing each unit of logic in one place, whatever that means. But to appease the pedantic, my versions are actually doing more computational work: they are doing one extra pattern match when these patterns are encountered. Whoopty-doo. :-) Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Disjunctive Normal Form
On 11/1/07, Arnar Birgisson [EMAIL PROTECTED] wrote: I'm learning too and found this an interesting problem. Luke, is this similar to what you meant? Heh, your program is almost identical to the one I wrote to make sure I wasn't on crack. :-) data LS = Var String | Not LS | And LS LS | Or LS LS deriving Show data Term = Pos String | Neg String deriving Show type Conj = [Term] type DNF = [Conj] dnf :: LS - DNF dnf (Var s) = [[Pos s]] dnf (Or l1 l2) = (dnf l1) ++ (dnf l2) dnf (And l1 l2) = [t1 ++ t2 | t1 - dnf l1, t2 - dnf l2] dnf (Not (Not d)) = dnf d dnf (Not (And l1 l2)) = (dnf $ Not l1) ++ (dnf $ Not l2) dnf (Not (Or l1 l2)) = [t1 ++ t2 | t1 - dnf $ Not l1, t2 - dnf $ Not l2] These two are doing a little extra work: dnf (Not (And l1 l2)) = dnf (Or (Not l1) (Not l2)) dnf (Not (Or l1 l2)) = dnf (And (Not l1) (Not l2)) dnf (Not (Var s)) = [[Neg s]] -- test cases x = (Or (And (Var A) (Var B)) (Or (And (Not $ Var C) (Var D)) (Var E))) y = (Not (And (Var A) (Var B))) z = (Not (And (Not y) y)) Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
Quoting Justin Bailey [EMAIL PROTECTED]: Done: http://www.haskell.org/haskellwiki/RuntimeCompilation . Please update it as needed. Thanks! Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Need help from a newby
My declaration is as followed:- type Address = Int data Port = C | D deriving(Eq,Show) data Payload = UP[Char] | RTDP(Address,Port) deriving(Eq,Show) data Pkgtype = RTD | U deriving(Eq,Show) type Pkg = (Pkgtype,Address,Payload) type Table = [(Address,Port)] findport::[Pkg]-[Table]-[([Pkg],[Pkg])] findport [(pt,ad,pa)] [(a,p)] | ( p == C) = ([pt,ad,a],[]) | otherwise = ([],[pt,ad,a]) Error received:- Type error in explicitly typed binding *** Term : [(a,p)] *** Type : [(a,b)] *** Does not match : [Table] Can anyone please help? -- View this message in context: http://www.nabble.com/Need-help-from-a-newby-tf4735009.html#a13540531 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
[Haskell-cafe] Re: Need help from a newby
karle wrote: My declaration is as followed:- type Address = Int data Port = C | D deriving(Eq,Show) data Payload = UP[Char] | RTDP(Address,Port) deriving(Eq,Show) data Pkgtype = RTD | U deriving(Eq,Show) type Pkg = (Pkgtype,Address,Payload) type Table = [(Address,Port)] findport::[Pkg]-[Table]-[([Pkg],[Pkg])] findport [(pt,ad,pa)] [(a,p)] | ( p == C) = ([pt,ad,a],[]) | otherwise = ([],[pt,ad,a]) Error received:- Type error in explicitly typed binding *** Term : [(a,p)] *** Type : [(a,b)] *** Does not match : [Table] Can anyone please help? There seems to be several things that look wrong. Could you explain what findport is supposed to be doing? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need help from a newby
ChrisK-3 wrote: karle wrote: My declaration is as followed:- type Address = Int data Port = C | D deriving(Eq,Show) data Payload = UP[Char] | RTDP(Address,Port) deriving(Eq,Show) data Pkgtype = RTD | U deriving(Eq,Show) type Pkg = (Pkgtype,Address,Payload) type Table = [(Address,Port)] findport::[Pkg]-[Table]-[([Pkg],[Pkg])] findport [(pt,ad,pa)] [(a,p)] | ( p == C) = ([pt,ad,a],[]) | otherwise = ([],[pt,ad,a]) Error received:- Type error in explicitly typed binding *** Term : [(a,p)] *** Type : [(a,b)] *** Does not match : [Table] Can anyone please help? There seems to be several things that look wrong. Could you explain what findport is supposed to be doing? findport is just to check if the port in the Table is equal to C then it will place the packet in the first of the list. Otherwise it will place the packet in the second of the list. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- View this message in context: http://www.nabble.com/Need-help-from-a-newby-tf4735009.html#a13541442 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] Need help from a newby
Substitute the definition of type Table into the error: Type error in explicitly typed binding *** Term : [(a,p)] *** Type : [(a,b)] *** Does not match : [Table] where [Table] = [[(Address,Port)]] Do you see why the expression [ (a,p) ] cannot have type [ [ (Address, Port) ] ] ? Regards, Chris On 11/1/07, karle [EMAIL PROTECTED] wrote: My declaration is as followed:- type Address = Int data Port = C | D deriving(Eq,Show) data Payload = UP[Char] | RTDP(Address,Port) deriving(Eq,Show) data Pkgtype = RTD | U deriving(Eq,Show) type Pkg = (Pkgtype,Address,Payload) type Table = [(Address,Port)] findport::[Pkg]-[Table]-[([Pkg],[Pkg])] findport [(pt,ad,pa)] [(a,p)] | ( p == C) = ([pt,ad,a],[]) | otherwise = ([],[pt,ad,a]) Error received:- Type error in explicitly typed binding *** Term : [(a,p)] *** Type : [(a,b)] *** Does not match : [Table] Can anyone please help? -- View this message in context: http://www.nabble.com/Need-help-from-a-newby-tf4735009.html#a13540531 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: do/if/then/else confusion
(...)
Can someone tell me what's wrong with this?
import qualified System.Posix.Directory as PD
readdirAll :: PD.DirStream - IO [String]
readdirAll d =
do dir - PD.readDirStream d
if dir ==
then return []
else rest - readdirAll d
return (dir:rest)
(...)
I don't know if this helps or disturbs, but I
wrote a few different versions of your code
as an exercise. If you want to try it, just
uncomment the versions you want to check. The
complete program below lists all files in
current directory, using 'readdirAll' to get
the full list.
Best,
Maurício
module Main (Main.main) where
import qualified System.Posix.Directory as PD
import Data.List
import Control.Monad
main :: IO ()
readdirAll :: PD.DirStream - IO [String]
readdirAll ds = liftM reverse $ read []
where
read (:t) = return t
read list = (PD.readDirStream ds) = glue
where glue f = read (f:list)
{-
readdirAll ds = read
where
read = (PD.readDirStream ds) = rest
rest = return []
rest h = liftM (h:) read
-}
{-
readdirAll ds = do
f - PD.readDirStream ds
rest f
where
rest = return []
rest h = return (h:) `ap` (readdirAll ds)
-}
main = (PD.openDirStream .) =
readdirAll = (putStrLn.show)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
