[Haskell-cafe] Re: Type-Marking finite/infinte lists?
David Menendez wrote: Joachim Breitner wrote: today while mowing the lawn, I thought how to statically prevent some problems with infinte lists. I was wondering if it is possible to somehow mark a list as one of finite/infinite/unknown and to mark list-processing functions as whether they can handle infinte lists. One possibility would be to have some phantom markers in the list type. For example, newtype List isEmpty isFinite a = MarkList [a] data Finite data Infinite data Empty data Nonempty data Unknown Yes, phantom types are what Joachim wants. For more about phantom types, see also http://haskell.org/haskellwiki/Phantom_type Ralf Hinze. Fun with Phantom Types. http://www.informatik.uni-bonn.de/~ralf/publications/With.pdf Another possibility for working with infinite lists would be a new data type data InfList a = a : InfList a (also called Stream but this name is quite overloaded.) cons:: a - List e f a - List Nonempty f a But unfortunately, finiteness is a special property that the type system cannot guarantee. The above type signature for cons doesn't work since the following would type check bad :: a - List Nonempty Finite a bad x = let xs = cons x xs in xs In other words, Haskell's type system doesn't detect infinite recursion. (But there are type systems like System F or that of Epigram that disallow general recursion.) As a variation, we can use rank-2 types instead of Unknown; e.g. tail :: List Nonempty f a - (forall e. List e f a - w) - w filter :: (a - Bool) - List e f a - (forall e. List e f a - w) - w That's probably best explained in terms of the existential quantor tail :: List Nonempty f a - (exists e. List e f a) filter :: (a - Bool) - List e f a - (exists e. List e f a) In other words, tail takes a nonempty list and returns one that has an emptiness e but that's all we know. Existential quantification is not first-class in Haskell, so you can either use a data type data Box100 f b c = forall a . Box100 (f a b c) tail :: List Nonempty f a - Box100 List f a or encode it via the isomorphism exists e . expr e = forall w . (forall e . expr e - w) - w Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can I stop GHCi from calling show for IO actions?
On 9/16/07, Ryan Ingram [EMAIL PROTECTED] wrote: Is there a way to make GHCi not print the result of an action but still make my variables get bound? This seems to be a common question (I myself asked it recently), so I've added an entry to the GHCi page on the wiki. Ideally, it would be nice if this were discoverable from within GHCi, but I'm not sure how this would best be done. Stuart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
Stefan O'Rear wrote: packages is only for those libraries that are shipped with GHC. It is? This is news to me. An obvious counter example seems to be the collections package which has been put here. This is not shipped with ghc and I'm not aware of any plans to do this. Perhaps if this is the intention it would be better to call it ghc-packages. But darcs.haskell.org does seem to be a real mess and I do have a hard time figuring out what's what here and how it's organised (or even if it is organised :-) Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can I stop GHCi from calling show for IO actions?
I've always wondered if ghc(i) --help should be a bit more instructive, or perhaps if there were a man page that lay somewhere between the --help message and the manual in terms of comprehensiveness. It's a pretty major jump from a short description of 4 command line options (only one of which I have ever used) to the entire manual, with a ~10 page table of contents. On 16/09/2007, Stuart Cook [EMAIL PROTECTED] wrote: On 9/16/07, Ryan Ingram [EMAIL PROTECTED] wrote: Is there a way to make GHCi not print the result of an action but still make my variables get bound? This seems to be a common question (I myself asked it recently), so I've added an entry to the GHCi page on the wiki. Ideally, it would be nice if this were discoverable from within GHCi, but I'm not sure how this would best be done. Stuart ___ 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] Israel Haskell Programmers
Hello, Are there any Haskell Hackers on this mailing list who live in Israel? I am interested in starting an Israel Haskell User Group. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-Marking finite/infinte lists?
On 9/16/07, apfelmus [EMAIL PROTECTED] wrote: But unfortunately, finiteness is a special property that the type system cannot guarantee. The above type signature for cons doesn't work since the following would type check bad :: a - List Nonempty Finite a bad x = let xs = cons x xs in xs In other words, Haskell's type system doesn't detect infinite recursion. Exactly. Haskell allows free unrestrained recursion, and this is the source of the problem. Instead we could limit ourselves to structural recursion and then we can guarantee that even if we write recursive code, the results will always be finite. For details there's Turner's paper on Total Functional Programming: http://www.cs.mdx.ac.uk/staffpages/dat/sblp1.pdf -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Parsec Scanner Question
Haskell Folks, I have an existing Parsec CharParser parser that I would like to extend to include line continuation support. When there's a backslash-newline combination anywhere in the token stream, I'd like to remove it so it's not read by the rest of the parser, even if its in the middle of a keyword. Currently I'm doing this with a separate preprocess function that weeds out all the '\\\n' strings from the input before passing it to the parser. The problem with this is it messes up the line position when there's an error below the '\\\n' point, since the newline is never seen by the parser. So I've been trying to figure out how to handle this better with Parsec. I think I need something that acts just like CharParser, except it skips over the backslash-newline tokens, It looks like section 2.11 in the Parsec manual (Advanced: separate scanners) covers this, but I'm not having much luck turning it into working code. Could someone who's written their own scanner spell out how it's done in a little more detail ? Thanks ! - jude ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Israel Haskell Programmers
On Sun, Sep 16, 2007 at 06:11:03PM +0200, B K wrote: Hello, Are there any Haskell Hackers on this mailing list who live in Israel? I am interested in starting an Israel Haskell User Group. I am here, although I probably do not really count for Haskell Hacker. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
On Sat, Sep 15, 2007 at 08:27:02AM +0100, Adrian Hey wrote: Perhaps what you really mean is, you long for a Data.Map.Strict that carries the offically blessed status of being shipped with ghc (reminds me of someone asking for a ghc approved SDL binding a while back :-). Yes, that would be what I mean. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Linear Equation Solver Using Arrays
(Replying on haskell-cafe) Let me start with a disclaimer: I haven't looked at your code extensively. That said, the feeling that I get from it is one of listening to a non-native speaker. The things in your program are obviously not completely inaccurate, or they wouldn't have type-checked. And, presumably, you've already done some testing, so it probably produces the right answers. Similarly, there are many things in English that you _could_ say, which would be entirely grammatically correct, but which native speakers would never say. For example, in your code, I noticed a pattern which I've just recently learned: code do ... tmp - readArray scaleInfo j writeArray scaleInfo imax tmp /code Now, if you were to de-sugar the last 2 lines, it would look something like this: code readArray scaleInfo j = \tmp - writeArray scaleInfo imax tmp /code ...but as soon as you see that lambda expression, you should (hopefully) say oh, that can be written more easily: code readArray scaleInfo j = writeArray scaleInfo imax /code Of course, a native speaker will probably not even think about the intermediate lambda expression, but the point is, this is an idiom. And, really, this is a very tiny example. Your entire program is written in a very imperative style. Do this, then do that, then do the other thing. And this is to be expected. After all, you said that you were directly porting the algorithm from an imperative language. However, if you're going to do this idiomatically, you really need to think very differently. I suggest reading and pondering this well-known blog entry for more ideas about the differences between the approaches of functional and imperative programming: http://blogs.nubgames.com/code/?p=22 Sorry, I don't have more specific suggestions, but I suspect this is what most people thought when they read your code: it's hard to make specific suggestions, when you're really approaching the problem in a non-idiomatic way. On 9/16/07, Xiao-Yong Jin [EMAIL PROTECTED] wrote: Dear Haskellers, My thanks to people on the irc channel, especially `int-e'. With their help, I managed to write a linear equation solver using STUArrays. It is basically a direct rewrite of a C version, which adopts Crout's LU decomposition method with implicit pivoting, in chapter 2.3 of the book Numerical Recipes. I must admit that the code is in a really bad style, somewhat ugly, because of the limit of my Haskell knowledge. The code is attached in this email for your amusement. I would be really thankful if you can give me any kind of comments, idea, improvement, criticism, because I sincerely want to make the code better. Best regards, Xiao-Yong -- c/*__o/* \ * (__ */\ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] OzHaskell?!?
There is AngloHaskell and now AmeroHaskell. Doesn't that call for OzHaskell? http://haskell.org/haskellwiki/OzHaskell Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
