Re: [Haskell-cafe] Re: Why purely in haskell?
On Thu, 10 Jan 2008 19:38:07 +0200, Tillmann Rendel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. Prelude sum [1..100] *** Exception: stack overflow Not true in Hugs. Prelude Data.List.foldl' (+) 0 [1..100] 5050 Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [IETF Apps meeting] A Theory of Templating Languages
The IETF (http://www.ietf.org/) holds a meeting of its Application Area and is looking for papers. In a position paper, Joe Gregorio asked for information about the theory of templating languages. Giving the interest here in DSLs and conceptualization, he may find on this list the help he wants and the references he searches: From: Joe Gregorio [EMAIL PROTECTED] Date: December 14, 2007 8:20:17 AM PST Subject: Re: Position papers due Dec 14 Here is my brief position paper: Working on the URI Templating specification has made me realize that there is a pretty substantial hole in computer science theory: a lack of a theory of templating languages. For example, the current version of URI Templates is not Turing-complete, which excludes a whole bunch of possible attacks. In the specification I state: On the balance, the template processing is not Turing complete, thus avoiding a number of security issues, ala the billion-laughs attack of XML DTDs. I was rightly called out on this on the W3C URI mailing list: This reads a little odd, as not being Turing-complete is not sufficient to avoid the attack. (And DTDs are not Turing-complete either.) The criticism is correct. The problem is that I don't know of any finer grained levels of classifications of templating languages than Turing/non-Turing, and not only for security reasons, but for general capabilities. For example, if there were classes of templating languages, I could say that URI Templates fell into 'class X', and if that class had a known set of limitations and capabilities then I could say that URI Templates thus had those limitations and capabilities. The weakness to the billion laughs attack comes from two facets of DTD usage, the first being that templates can be defined in terms of other templates, and the second is that the depth of template definition, in terms of other templates, isn't limited. But the converse isn't true, that is, I don't have a general theory of templating to lean on that says since URI Template expansions are never defined in terms of other expansions then URI Templates are immune to such resource exhaustion attacks. I did find one paper that makes a start at such work, Enforcing Strict Model-View Separation in Template Engines, but the theory is a little weak and it focuses on the nebulous idea of separation of model and view, as opposed to a classification of capabilities and limitations. In addition there seems to not be a lot of work on sub-turing languages, and most interestingly the contemporary work that is being done is on Membrane Computing Systems, which is in turn motivated by studying cell evolutions and chemical reactions. I am bringing this topic forward in the hopes of learning of other pointers into the literature, and also learning if this problem applies to others in the Apps area, of if I'm all alone with this problem in URI Templates. - End forwarded message - ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-mode 2.4
Emacs is completely frozen until I press C-g and then it goes back to normal (without loading the file). Here's the back trace: Debugger entered--Lisp error: (quit) accept-process-output(#process haskell) (and (not (re-search-forward comint-prompt-regexp nil t)) (accept-process-output proc)) So it seems to be waiting for the prompt but can't find it. If you look at the buffer containing the interactive process, is there a prompt there? If not, can you try and figure out why not? If yes, can you try and figure out why it is not recognized by the comint-prompt-regexp? I had the following in my .ghci to make GHCi's prompt less verbose: :set prompt Removing that solves the problem. Thanks! -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Fri, 11 Jan 2008 09:16:12 +0200, Lennart Augustsson [EMAIL PROTECTED] wrote: Thank you Duncan, you took the words out of my mouth. :) On Jan 10, 2008 5:42 PM, Duncan Coutts [EMAIL PROTECTED] wrote: So let's imagine: ones = 1 : ones ones' = repeat 1 where repeat n = n : repeat n So you're suggesting that: ones == ones = True but ones' == ones' = _|_ Well if that were the case then it is distinguishing two equal values and hence breaking referential transparency. We can fairly trivially prove that ones and ones' are equal so == is not allowed to distinguish them. Fortunately it is impossible to write == above, at least using primitives within the language. If one can prove ones == ones = True with some method, why that method cannot be made to work on ones' ? Are you thinking about repeat (f x) by any chance ? Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Am Freitag, 11. Januar 2008 08:11 schrieb Lennart Augustsson: Some people seem to think that == is an equality predicate. This is a big source of confusion for them; until they realize that == is just another function returning Bool they will make claims like [1..]==[1..] having an unnatural result. The == function is only vaguely related to the equality predicate in that it is meant to be a computable approximation of semantic equality (but since it's overloaded it can be anything, of course). -- Lennart But class methods are expected to fulfill some axioms. I’d suppose that (==) should be an equivalence relation. Of course, this is not implementable because of infininte data structures. But one could relax the axioms such that it’s allowed for (==) to return _|_ instead of the expected value. Differentiating between data and codata would of course be the better solution. However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn’t adhere to any meaningful axiom set for Eq. So I think that this behavior should be changed. Think of a set implementation which uses (==) to compare set elements for equality. The NaN behavior would break this implementation since it would allow for sets which contain NaN multiple times. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Fri, 11 Jan 2008 09:11:52 +0200, Lennart Augustsson [EMAIL PROTECTED] wrote: Some people seem to think that == is an equality predicate. This is a big source of confusion for them; until they realize that == is just another function returning Bool they will make claims like [1..]==[1..] having an unnatural result. The == function is only vaguely related to the equality predicate in that it is meant to be a computable approximation of semantic equality (but since it's overloaded it can be anything, of course). I think that confusion came from the fact that the type of == is called (Eq a)= a - a - Bool and not (Bla a) = a - a - Binary and not realizing it's just an overloaded polimorphic function. Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Subtypes and Co/Contra-variance
Consider this: type Super = forall a. [a] type Sub = forall b. b cast0 :: Sub - Super cast0 s = s cast1a :: forall p. (Super - p) - (Sub - p) cast1a sp x = sp x cast1b :: forall p. (Super - p) - (Sub - p) cast1b sp = sp This compiles except for cast1b (ghc -c -fglasgow-exts): Occurs check: cannot construct the infinite type: a = [a] When generalising the type(s) for `cast1b' I get a similar result when I try a different Super and Sub: type Super = (?x :: Bool) = Int type Sub = Int Couldn't match expected type `Sub' against inferred type `Super' When matching `(?x::Bool) = Int' and `Int' Expected type: Sub - p Inferred type: Super - p In the expression: sp In either case, if cast1a compiles, shouldn't cast1b compile? -- Ashley Yakeley ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 0/0 1 == False
Achim Schneider [EMAIL PROTECTED] writes: You need to use the / operator, if you want to do floating-point division. Yes, exactly, integers don't have +-0 and +-infinity... only (obviously) a kind of nan. No, failure (exception, bottom) is different from NaN, which is just another value in the domain - admittedly one which behaves rather strangely. Said differently: I don't know a thing about floats or numerics. Perhaps it helps to think of floating point values as intervals? If +0 means some number between 0 and the next possible representable number (and similar for -0), it may make more sense to have 1/+0 and 1/-0 behave differently. -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: [Haskell-cafe] Re: Why purely in haskell?
However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. In my opinion it is the better than yielding True. 0/0 doesn't make sense. So it can't be compared to anything else which doesn't make sense. Whether == should yield False at all is another matter. It may be better to yield some kind of bottom (undefined?), but then compatibility with IEEE 754 might be an issue, hence using external libraries like BLAS, gmp, ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
On Thu, 10 Jan 2008, David Roundy wrote: On Thu, Jan 10, 2008 at 08:10:57PM +, Sebastian Sylvan wrote: On Jan 10, 2008 8:06 PM, Ketil Malde [EMAIL PROTECTED] wrote: David Roundy [EMAIL PROTECTED] writes: I just want to point out that unsafePerformIO is at the core of the (safe) bytestring library. As SPJ et al pointed out, this is crucial functionality, and is only unsafe if unsafely used. In Modula-3 modules using hacks must be explicitly marked as UNSAFE. See http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html Maybe this is also an option for Haskell? I don't think this is a good idea. I think the point is (should be) to mark functions unsafe when they may be unsafe to /use/, I think using the IO monad for this works well... Would you suggest moving head and tail into the IO monad? I'm afraid we are talking about different notions of 'safe'. Modula-3's 'safe' means no segmentation fault, but program abortion due to ASSERT is still allowed. Ported to Haskell this means: 'head' and 'tail' are safe, but not total. I've seen function definitions like 'safeHead', that I would have named 'maybeHead'. For running untrusted code this means: I think it is ok that the program aborts with an error or runs into an infinite loop and must be terminated after a time-out, but it is not ok, that it overwrites some memory area or deletes some files, because unsafePerformIO was invoked. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Fri, 11 Jan 2008 09:11:52 +0200, Lennart Augustsson [EMAIL PROTECTED] wrote: Some people seem to think that == is an equality predicate. This is a big source of confusion for them; until they realize that == is just another function returning Bool they will make claims like [1..]==[1..] having an unnatural result. The == function is only vaguely related to the equality predicate in that it is meant to be a computable approximation of semantic equality (but since it's overloaded it can be anything, of course). So let's imagine: ones = 1 : ones ones' = repeat 1 where repeat n = n : repeat n (==) :: Eq a = a - a - Bool -- what is (y (y) ) by the way ? -- how about ( y id ) ? y f = f (y f). ones :: Num a = [a] ones = y (1 :) repeat :: a - [a] repeat = \n - y (n:) ones' :: Num a = [a] ones' = repeat 1 = (\n-y(n:)) 1 = y (1 : ) To be able to test them for equality, we must have Eq a. So, the reason we cannot test them for equality is that we cannot test y (a : ) == y (a : ) where a == a is testable. Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Displaying steps in my interpreter
On Jan 10, 2008 8:39 PM, apfelmus [EMAIL PROTECTED] wrote: Victor Nazarov wrote: Yes, there is: you can use a zipper http://en.wikibooks.org/wiki/Haskell/Zippers Here's how: data Branch v = AppL (Term v) | AppR (Term v) | Lamb v type Context v = [Branch v] type Zipper v = (Context v, Term v) unwind :: Zipper v - Term v unwind ([], t) = t unwind (AppL e:cxt, f) = unwind (cxt, App f e) unwind (AppR f:cxt, e) = unwind (cxt, App f e) unwind (Lamb x:cxt, e) = unwind (cxt, Lam x e) Thanks. Zippers seemed very cool when I first encountered them in some text about xmonad. But I've never used them in my own code. Concerning the problem of printing intermediate steps, I don't quite understand your approach. I'd simply use a Writer monad to keep track of intermediate terms My version just return when the state in State monad is not Nothing, so we can print result and start over again. import Control.Monad.Writer -- use a difference list or something for better performance type Trace v = [Zipper v] whnf :: Term v - Writer (Trace v) (Term v) whnf t = whnf' ([],t) where whnf' (AppL e':cxt, Lam x e) = tell (cxt, App (Lam x e) e') whnf' (cxt , subst x e' e) whnf' (cxt, App f e) = whnf' (AppL e:cxt, f) whnf' z = return $ unwind z The definition of whnf is basically left unchanged, except that a redex is recorded via tell whenever a beta-reduction is about to be performed. The recorded terms can be printed afterwards printTrace :: Writer (Trace v) (Term v) - IO () printTrace w = let (t, ts) = runWriter t ts putStrLn . unlines . map show $ ts Is this function lazy? Can I run this code on term without nf and print n-first steps: printTraceN :: Int - Writer (Trace v) (Term v) - IO () printTraceN n w = let (t, ts) = runWriter t ts in putStrLn . unlines . map show $ take n ts Will this work: printTraceN 5 (read (\x. x x x) (\x. x x x)) ? Last but not least, there is a nice introductory paper about the many possible reduction strategies for lambda calculus http://www.itu.dk/people/sestoft/papers/sestoft-lamreduce.pdf Thank you. -- vir http://vir.comtv.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
Wolfgang Jeltsch [EMAIL PROTECTED] schrieb: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn?t adhere to any meaningful axiom set for Eq. So I think that this behavior should be changed. Think of a set implementation which uses (==) to compare set elements for equality. The NaN behavior would break this implementation since it would allow for sets which contain NaN multiple times. You forget, that the intention of NaN is denial of membership of any set of numbers. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Jan 11, 2008 7:47 AM, Miguel Mitrofanov [EMAIL PROTECTED] wrote: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. Just for the record: the following is from Firebug (JavaScript debugger for Firefox) session: a = 0/0 NaN a == a false a === a false Another thing for the record: Goldberg says The introduction of NaNs can be confusing, because a NaN is never equal to any other number (including another NaN), so x = x is no longer always true. In fact, the expression x /= x is the simplest way to test for a NaN if the IEEE recommended function Isnan is not provided. Furthermore, NaNs are unordered with respect to all other numbers, so x = y cannot be defined as not x y. Since the introduction of NaNs causes floating-point numbers to become partially ordered, a compare function that returns one of , =, , or unordered can make it easier for the programmer to deal with comparisons. Goldberg, David. What Every Computer Scientist Should Know About Floating-Point Arithmetic. http://docs.sun.com/source/806-3568/ncg_goldberg.html . As GNU is not Unix, NaN is not a number, so what is standard about numbers doesn't work for them. I don't think there's a compeling reason about changing this behavior, specially because it's what's specified in the IEEE 754. However you can always define something like newtype NotADouble = N Double ... instance Eq NotADouble where N x == N y = (isNaN x isNaN y) || (x == y) ... -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. Just for the record: the following is from Firebug (JavaScript debugger for Firefox) session: a = 0/0 NaN a == a false a === a false ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
As GNU is not Unix, NaN is not a number, Since NaN /= NaN, I think, we should decipher NaN as Not a NaN instead. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Wolfgang Jeltsch [EMAIL PROTECTED] writes: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn’t adhere to any meaningful axiom set for Eq. Tough luck, but that's how floating point works, and what the numericalists know, and possibly even love (although I have my doubts). Sanitizing this behavior would make Haskell less usable for real-world numerical problems. As a compromise, what about an option to make NaN (and presumably the infinities) cause an immediate exception? (And, cetero censeo, exceptions for Int overflow as well.) -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: [Haskell-cafe] Re: Why purely in haskell?
Achim Schneider wrote: The list instance for Eq might eg. know something about the structure of the lists and be smart enough not to get caught in the recursion of x = 1:1:x and y = 1:1:1:y so it could successfully compare x == y to True in six compares. This would not be something about the structure of lists This would be somethign about the structure of thunks. Thunks are not supposed to be observable. If you augment the language to make thunks observable and comparable, you will break referential transparency. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Fri, 11 Jan 2008 13:29:35 +0200, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Freitag, 11. Januar 2008 10:54 schrieb Wilhelm B. Kloke: Wolfgang Jeltsch [EMAIL PROTECTED] schrieb: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn?t adhere to any meaningful axiom set for Eq. So I think that this behavior should be changed. Think of a set implementation which uses (==) to compare set elements for equality. The NaN behavior would break this implementation since it would allow for sets which contain NaN multiple times. You forget, that the intention of NaN is denial of membership of any set of numbers. This doesn’t matter. The Set data type I’m talking about would not know about NaN and would therefore allow multiple NaNs in a set. This is a good thing because one can define natural numbers with such sets :-) Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Am Freitag, 11. Januar 2008 11:33 schrieben Sie: Wolfgang Jeltsch [EMAIL PROTECTED] writes: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn’t adhere to any meaningful axiom set for Eq. Tough luck, but that's how floating point works, and what the numericalists know, and possibly even love (although I have my doubts). Sanitizing this behavior would make Haskell less usable for real-world numerical problems. The IEEE floating point equivalence test has to yield false when comparing NaN with NaN. Haskell’s (==) has to yield True or undefined when comparing a value with itself. So Haskell’s (==) just has to be different from the IEEE floating point equivalence test. What about providing a separate function for the latter? As a compromise, what about an option to make NaN (and presumably the infinities) cause an immediate exception? (And, cetero censeo, exceptions for Int overflow as well.) This would be far better (and far more Haskell-like). -k Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The Monad.Reader (10) - Second call for copy
Call for Copy The Monad.Reader - Issue 10 It is not too late to consider writing something for the next issue of The Monad.Reader. The deadline for Issue 10 is ** January 25, 2007 ** It doesn't matter if you're an established academic or if you have only just started learning Haskell, if you have something to say, please write article for The Monad.Reader. The Monad.Reader is a electronic magazine about all things Haskell. It is less-formal than journal, but somehow more enduring than a wiki- page. There have been a wide variety of articles, including: exciting code fragments, intriguing puzzles, book reviews, tutorials, and even half-baked research ideas. * Submission Details * Get in touch with me if you intend to submit something -- the sooner you let me know what you're up to, the better. Please submit articles for the next issue to me by e-mail (wss at cs.nott.ac.uk). Articles should be written according to the guidelines available from http://www.haskell.org/haskellwiki/The_Monad.Reader Please submit your article in PDF, together with any source files you used. The sources will be released together with the magazine under a BSD license. If you would like to submit an article, but have trouble with LaTeX please let me know and we'll sort something out. All the best, Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Am Freitag, 11. Januar 2008 10:54 schrieb Wilhelm B. Kloke: Wolfgang Jeltsch [EMAIL PROTECTED] schrieb: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn?t adhere to any meaningful axiom set for Eq. So I think that this behavior should be changed. Think of a set implementation which uses (==) to compare set elements for equality. The NaN behavior would break this implementation since it would allow for sets which contain NaN multiple times. You forget, that the intention of NaN is denial of membership of any set of numbers. This doesn’t matter. The Set data type I’m talking about would not know about NaN and would therefore allow multiple NaNs in a set. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Displaying steps in my interpreter
Victor Nazarov wrote: import Control.Monad.Writer -- use a difference list or something for better performance type Trace v = [Zipper v] whnf :: Term v - Writer (Trace v) (Term v) whnf t = whnf' ([],t) where whnf' (AppL e':cxt, Lam x e) = tell (cxt, App (Lam x e) e') whnf' (cxt , subst x e' e) whnf' (cxt, App f e) = whnf' (AppL e:cxt, f) whnf' z = return $ unwind z The definition of whnf is basically left unchanged, except that a redex is recorded via tell whenever a beta-reduction is about to be performed. The recorded terms can be printed afterwards printTrace :: Writer (Trace v) (Term v) - IO () printTrace w = let (t, ts) = runWriter t ts putStrLn . unlines . map show $ ts Is this function lazy? Can I run this code on term without nf and print n-first steps: printTraceN :: Int - Writer (Trace v) (Term v) - IO () printTraceN n w = let (t, ts) = runWriter t ts in putStrLn . unlines . map show $ take n ts Will this work: printTraceN 5 (read (\x. x x x) (\x. x x x)) Yes, it should (you can just try, right? :). That's because tell w something is basically let (w', x) = something in (w ++ w', x) Now, something may loop forever, but w ++ w' doesn't care, it prepends w no matter what w' is. Of course, asking for x (the normal form in our case) instead of w ++ w' won't succeed when something loops forever. (Cave: this is only true for the writer monad in Control.Monad.Writer.Lazy which is imported by default. The writer monad in Control.Monad.Writer.Strict intentionally behaves differently.) Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
Ketil Malde: Wolfgang Jeltsch: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn’t adhere to any meaningful axiom set for Eq. Tough luck, but that's how floating point works, and what the numericalists know, and possibly even love (although I have my doubts). Sanitizing this behavior would make Haskell less usable for real-world numerical problems. As a compromise, what about an option to make NaN (and presumably the infinities) cause an immediate exception? (And, cetero censeo, exceptions for Int overflow as well.) People, you are monsters. First, despite the *common, well known* truth that Haskell is not Mathematics, this illusion seems to be extremely persistent! Haskell is a victim - no, some users are victims of its success as a formal language, not just as a coding tool... They *want* to have Eq as they imagine the equality, including the comparison between incomparable. This is BTW a long standing philosophical problem. For centuries some speculative guys tried to analyse such assertions as God == God, or death==death. Or myself==myself. Of course, even if they produced some cute conclusions, they had no whatsoever sense for the others. Now we have the modern variants of it: NaN == NaN, bottom == bottom ... Of course, there are differences, since NaN is, no - ARE well defined *objects*. In IEEE there may be several NaNs, if the exponent is e_max+1, then *any* significand (mantissa for the dinosaurs) is good for a NaN. ++ Then, I see here, and on some other lists some tendency to speculate on the numerics by people who really don't need it, and don't use it. The bombing of NaN *might* be a profound compilation option, but for people who really do numerical work, this is a blessing NOT to have it. - Zero (or minimum, etc.) finders don't explode on your face when the automaton gets out of the range because of the instabilities. - Vectorized computations which produce plenty of good numbers and sometimes diverge, do not invalidate all work. - Ignoring Int overflow is a cheap way of having `mod` (MAXINT+1). Useful for many purposes. - In such vector/matrix packages as Matlab, where arrays may represent geometric objects, NaNs mean: no coordinates here, empty. Simple and useful. etc. So, don't sanitize anything, unless you know what you are really doing! I would suggest to Wolfgang Jeltsch a little more of reserve before making sharp categorical proposals concerning the fl. point computations (and also acknowledge that NaN is not a unique entity). It is easy to propose - in the name of purity to massacre existing structures; several religious sects and political doctrines were born in such a way. The result was usually horrible... The Num hierarchy in Haskell is bad, we know it, especially for people who do some more formal mathematics. There are more interesting problems to solve than organising a crusade against IEEE, illegalizing the Ord instance for numbers, etc. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Ketil Malde [EMAIL PROTECTED] writes: The bombing of NaN *might* be a profound compilation option, but for people who really do numerical work, this is a blessing NOT to have it. I'll expand a bit of this, after I've checked with Wikipedia. Please correct me (and it) if I'm wrong, but: 1) Intel CPUs generate exceptions, not NaNs (unless a NaN is already involved), so NaNs are introduced by choice in the run-time system. 2) IEE754 supports both 'signaling' and 'quiet' NaNs, so it seems the standard is not blessed in this regard. And, in Haskell, I'd consider using NaNs for missing values slightly abusive of the system, this is just a poor man's way of spelling Maybe Double. -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: [Haskell-cafe] Re: Why purely in haskell?
On Fri, 11 Jan 2008 14:21:45 +0200, [EMAIL PROTECTED] wrote: Ketil Malde: Wolfgang Jeltsch: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn’t adhere to any meaningful axiom set for Eq. Tough luck, but that's how floating point works, and what the numericalists know, and possibly even love (although I have my doubts). Sanitizing this behavior would make Haskell less usable for real-world numerical problems. As a compromise, what about an option to make NaN (and presumably the infinities) cause an immediate exception? (And, cetero censeo, exceptions for Int overflow as well.) People, you are monsters. First, despite the *common, well known* truth that Haskell is not Mathematics, this illusion seems to be extremely persistent! Haskell is a victim - no, some users are victims of its success as a formal language, not just as a coding tool... They *want* to have Eq as they imagine the equality, including the comparison between incomparable. This is BTW a long standing philosophical problem. For centuries some speculative guys tried to analyse such assertions as God == God, or death==death. Or myself==myself. Of course, even if they produced some cute conclusions, they had no whatsoever sense for the others. Now we have the modern variants of it: NaN == NaN, bottom == bottom ... Well, Haskell has this referential transparency thing which say that a function is a function and you will never be able to build anything else :-) Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Wolfgang Jeltsch wrote: Am Freitag, 11. Januar 2008 11:33 schrieben Sie: Wolfgang Jeltsch [EMAIL PROTECTED] writes: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn’t adhere to any meaningful axiom set for Eq. Tough luck, but that's how floating point works, and what the numericalists know, and possibly even love (although I have my doubts). Sanitizing this behavior would make Haskell less usable for real-world numerical problems. The IEEE floating point equivalence test has to yield false when comparing NaN with NaN. Haskell’s (==) has to yield True or undefined when comparing a value with itself. So Haskell’s (==) just has to be different from the IEEE floating point equivalence test. What about providing a separate function for the latter? I wonder where the requirement on (==) you mention above is specified. I can't find it in the report but maybe I just overlooked it. OTOH, the report does say: The Ord class is used for totally ordered datatypes. IEEE comparisons are not a total ordering so in principle, they can't be used in the Ord methods. Also, comparing IEEE-like numbers for equality is practically always a mistake (the cases where it isn't are exceedingly rare) so the Eq instance for Float and Double doesn't actually provide any meaningful functionality. Anyway, having correct but inefficient implementations of Eq and Ord method for floating-point numbers sounds like a good idea to me, provided that the fast comparisons are still available. Personally, I'd be fine with not having those instances at all but that's just me, I guess. As a compromise, what about an option to make NaN (and presumably the infinities) cause an immediate exception? (And, cetero censeo, exceptions for Int overflow as well.) This would be far better (and far more Haskell-like). No, it would be far more Haskell-like not to use Float and Double (nor Int, for that matter) for things they shouldn't be used for. If all you want are fractions use Rational. Float and Double are (or should be) only for high-performance computations and people implementing those ought to know what they are doing. If they don't, they'll have much bigger problems than NaNs not being equal to themselves. BTW, some algorithms depend on silent NaNs and many depend on infinity. As an aside, I'd recommend http://citeseer.ist.psu.edu/goldberg91what.html as an introduction to some of the problems with floating point. The paper also talks about some uses for silent NaNs. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
That would give you a language with a semantics I don't want to touch. Sometimes useful, yes, but far to intensional for my taste. -- Lennart On Jan 11, 2008 5:59 AM, Achim Schneider [EMAIL PROTECTED] wrote: Yes, thanks. I actually do think that many things would be easier if every recursion would be translated to its fixpoint, making the term tree completely finite and defining y internal, as it's arcane, black magic. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ 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 purely in haskell?
[EMAIL PROTECTED] writes: The difference between you (and/or Wolfgang J.) and myself is that I enjoy more my freedom, even if I have to pay with a little more work. You want to enforce rigid reactions of the system. You should be free to do it on *your* machine, not on mine. You are putting words in my mouth! I do not want to enforce rigid reactions on the system, I want the option to enforce them on my programs. As I said, the exceptional treatment of exceptional values might be a compilation option, as it was in some Fortrans I used long time ago. *I* proposed a compile-time option, *you* responded that it is a blessing NOT to have it. You want your programs to react histerically to all difficulties in math, since you are afraid of propagating NaNs, etc. If you consider halting execution to be a hysterical reaction, arithmetic errors to be all difficulties in math, and wishing for accurate error messages to be afraid, I guess the answer is 'yes'. And *then* you will have to sit down and correct your code. If there is no exception, your program may run happily, and produce rubbish, yes? Yes. I am more conservative. If you are afraid of rubbish, protect your code by appropriate checks *before* the errors occur. I've written a bit of checking code in my time. The problem is that you quickly end up with more checking code than 'real' code, that the checking code paths are rarely used, and thus even more bug prone than the rest of the code, and that usually, there is little you can sensibly do other than halt execution anyway. The nice thing about checking for integer overflow and arithmetic exception is that they can be added with no cost in code size or complexity, and (at least on some architectures) no cost in performance - perhaps even improvements, for signaling NaNs. My Haskell programs tend to be rather Spartan, and I think this makes them more readable, and thus more likely to actually be correct. What you call a sabotage I.e. the insistence on wrap-around Ints (a minority use case!) and quiet NaNs as the One True Way, disallowing all other approaches. I call the programmers negligence. I'll pleade guilty to the charge of being negiligent and not checking intermediate results for errors and overflows. But the only reason for using Int (and not Integer) and arguably floating point, is performance. Wrapping everything in checks will be laborious, and I am fairly certain that performance will suffer by magnitudes. So yes, I am lazy, I use Int and cross my fingers. (I'm not alone; I've read a fair bit of Haskell code (starting with the Prelude), I must just have been unfortunate to miss all the code written by the industrious and serious people who actually check their Int operations...) -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: [Haskell-cafe] Re: Why purely in haskell?
On Jan 11, 2008 9:27 AM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn't adhere to any meaningful axiom set for Eq. So I think that this behavior should be changed. Think of a set implementation which uses (==) to compare set elements for equality. The NaN behavior would break this implementation since it would allow for sets which contain NaN multiple times. Here's another thing that makes me want to throw up. Prelude let nan :: Double = 0/0 Prelude compare nan nan GT Prelude nan nan False Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments and suggestions on code
On Thu, 2008-01-10 at 20:37 -0800, Jonathan Cast wrote: It might be faster; laziness usually has higher constants than direct implementations. But I doubt the difference is critical in this case, and I would definitely time a re-writing and throw it away unless it was significantly faster. But I don't think this is a case where laziness actually alters either the time or the space asymptotics of the algorithm (you end up creating an ~ O(n) tree anyway, so I'd figure O(n) space was OK for the loop, too). I was wondering if laziness would make it run as if it was a single O(n) operation (get one directory entry on demand, pass it to filter and then to insertInTree), because only one entry is used at a time, so that only the current entry needs to be evaluated. I still find it hard to evaluate the effects of laziness on the complexity of programs... Andre ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
If you talk to anyone who uses floating point numbers for real they would find (0/0)==(0/0) perfectly natural. It disobeys some axioms that Eq instances don't fulfill anyway, but changing it would make a lot of people surprised too. In general, the floating point instances break almost all axioms that you might think exist for numbers. -- Lennart On Jan 11, 2008 1:27 AM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Freitag, 11. Januar 2008 08:11 schrieb Lennart Augustsson: Some people seem to think that == is an equality predicate. This is a big source of confusion for them; until they realize that == is just another function returning Bool they will make claims like [1..]==[1..] having an unnatural result. The == function is only vaguely related to the equality predicate in that it is meant to be a computable approximation of semantic equality (but since it's overloaded it can be anything, of course). -- Lennart But class methods are expected to fulfill some axioms. I'd suppose that (==) should be an equivalence relation. Of course, this is not implementable because of infininte data structures. But one could relax the axioms such that it's allowed for (==) to return _|_ instead of the expected value. Differentiating between data and codata would of course be the better solution. However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn't adhere to any meaningful axiom set for Eq. So I think that this behavior should be changed. Think of a set implementation which uses (==) to compare set elements for equality. The NaN behavior would break this implementation since it would allow for sets which contain NaN multiple times. Best wishes, Wolfgang ___ 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-mode 2.4
Johan == Johan Tibell [EMAIL PROTECTED] writes: Emacs is completely frozen until I press C-g and then it goes back to normal (without loading the file). Here's the back trace: Debugger entered--Lisp error: (quit) accept-process-output(#process haskell) (and (not (re-search-forward comint-prompt-regexp nil t)) (accept-process-output proc)) So it seems to be waiting for the prompt but can't find it. If you look at the buffer containing the interactive process, is there a prompt there? If not, can you try and figure out why not? If yes, can you try and figure out why it is not recognized by the comint-prompt-regexp? I had the following in my .ghci to make GHCi's prompt less verbose: :set prompt Removing that solves the problem. You can also add the following to your .emacs: (add-hook 'inferior-haskell-mode-hook (lambda () (set (make-local-variable 'comint-prompt-regexp) ^ ))) Or some fancier regexp (the default is ^\\*?[A-Z][\\._a-zA-Z0-9]*\\( \\*?[A-Z][\\._a-zA-Z0-9]*\\)* ). Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Am Freitag, 11. Januar 2008 13:21 schrieb [EMAIL PROTECTED]: Ketil Malde: Wolfgang Jeltsch: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn’t adhere to any meaningful axiom set for Eq. Tough luck, but that's how floating point works, and what the numericalists know, and possibly even love (although I have my doubts). Sanitizing this behavior would make Haskell less usable for real-world numerical problems. As a compromise, what about an option to make NaN (and presumably the infinities) cause an immediate exception? (And, cetero censeo, exceptions for Int overflow as well.) People, you are monsters. First, despite the *common, well known* truth that Haskell is not Mathematics, this illusion seems to be extremely persistent! Haskell is a victim - I was arguing from a software technology point of view: if (==) yields false when comparing a value with itself, this can break code (like a set implementation) which relies on certain guarantees. The fact that Haskell allows to define (==) rather arbitrarily doesn’t mean that the use of arbitrary definitions of (==) is what we want. It’s just that the language is to weak to express axioms. My impression is that staying close to math is good from a software technology point of view. And it has the advantage of less confusion for the user. […] Then, I see here, and on some other lists some tendency to speculate on the numerics by people who really don't need it, and don't use it. Even if I don’t use numerics, I do care about the Haskell language as a whole. […] I would suggest to Wolfgang Jeltsch a little more of reserve before making sharp categorical proposals concerning the fl. point computations (and also acknowledge that NaN is not a unique entity). It is easy to propose - in the name of purity to massacre existing structures; several religious sects and political doctrines were born in such a way. The result was usually horrible... I don’t see what’s so extreme about suggesting that IEEE floating point comparison should maybe be a seperate operator. And I think, it is really inappropriate to compare this to horrible sects and doctrines. Do you really want to argue that someone who insists on a rather clean language is dangerous? Than more or less everyone on this list would be dangerous—from a C programmer’s point of view. The Num hierarchy in Haskell is bad, we know it, especially for people who do some more formal mathematics. There are more interesting problems to solve than organising a crusade against IEEE, illegalizing the Ord instance for numbers, etc. Please don’t suggest that “illegalizing” some Ord instance is similar to killing people out of religious motives. Jerzy Karczmarczuk Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
[EMAIL PROTECTED] writes: People, you are monsters. Well, bring on the torches and the pitchforks (although the image in my mind is more like a mob carrying lenses and bananas). no, some users are victims of its success as a formal language, not just as a coding tool I think Haskell's theoretical basis is part of its success as a coding tool. ... They *want* to have Eq as they imagine the equality, including the comparison between incomparable. In an ideal world, yes, but I think the monster to which you respond was fairly clear on being 'practical' here? The bombing of NaN *might* be a profound compilation option, but for people who really do numerical work, this is a blessing NOT to have it. I don't understand this. Are you worried users will edit the language pragmas in your code, and complain about NaN errors? Back when I *was* using the abbreviation FP for 'Floatin Point', I often got NaNs due to programming errors. Given the NaN's nature of contaminating subsequent results, getting an exception at the first occurrence would aid in tracking it down. - Ignoring Int overflow is a cheap way of having `mod` (MAXINT+1). Useful for many purposes. ...and ditto for this. The usefulness of one case in no way justifies sabotagin all other cases. I'd wager Ints see wider use in settings where the silent 'mod' is harmful, than where this effect is desired. Again, the current behavior causes errors that are very hard to track down. IMHO, these are two very different types, and I'm sligtly baffled that the fact is not reflected in Haskell. -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: [Haskell-cafe] Re: Why purely in haskell?
The thing is that y already is a *builtin* function in Haskell. On Fri, 11 Jan 2008 15:59:50 +0200, Achim Schneider [EMAIL PROTECTED] wrote: Cristian Baboi [EMAIL PROTECTED] wrote: So let's imagine: ones = 1 : ones ones' = repeat 1 where repeat n = n : repeat n (==) :: Eq a = a - a - Bool -- what is (y (y) ) by the way ? -- how about ( y id ) ? y f = f (y f). ones :: Num a = [a] ones = y (1 :) repeat :: a - [a] repeat = \n - y (n:) ones' :: Num a = [a] ones' = repeat 1 = (\n-y(n:)) 1 = y (1 : ) To be able to test them for equality, we must have Eq a. So, the reason we cannot test them for equality is that we cannot test y (a : ) == y (a : ) where a == a is testable. Yes, thanks. I actually do think that many things would be easier if every recursion would be translated to its fixpoint, making the term tree completely finite and defining y internal, as it's arcane, black magic. Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
Jonathan Cast [EMAIL PROTECTED] wrote: On 10 Jan 2008, at 7:55 AM, Achim Schneider wrote: Daniel Yokomizo [EMAIL PROTECTED] wrote: On Jan 10, 2008 3:36 PM, Achim Schneider [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Niko Korhonen writes: ... Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. [1..] == [1..] , for assumed operational semantics of ones own axiomatic semantics. Bugs are only a misunderstanding away. It has nothing to do with laziness, but with using an algebraic function (==) with a codata structure (stream). If Haskell kept laziness but enforced separation of data and codata such code wouldn't compile. Lazy lists or streams never are a problem, but you can't (generically) fold codata. Exactly. Denotationally it hasn't, but axiomatically it has. Because it looks like mathematical terms one can easily get lost in believing it reduces like mathematics, too. What kind of mathematics? I don't know of any mathematics where algebraic simplifications are employed without proof of the underlying equations (in some denotational model). Mathematics as, as my professor put it, Solving by staring. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
If you can't stomach the weirdness of floating point then perhaps you should try to define your own type that obeys all the expected laws? :) On Jan 11, 2008 3:36 AM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Freitag, 11. Januar 2008 11:03 schrieb Felipe Lessa: Another thing for the record: Goldberg says The introduction of NaNs can be confusing, because a NaN is never equal to any other number (including another NaN), so x = x is no longer always true. In fact, the expression x /= x is the simplest way to test for a NaN if the IEEE recommended function Isnan is not provided. Furthermore, NaNs are unordered with respect to all other numbers, so x = y cannot be defined as not x y. Since the introduction of NaNs causes floating-point numbers to become partially ordered, a compare function that returns one of , =, , or unordered can make it easier for the programmer to deal with comparisons. Goldberg, David. What Every Computer Scientist Should Know About Floating-Point Arithmetic. http://docs.sun.com/source/806-3568/ncg_goldberg.html . As GNU is not Unix, NaN is not a number, so what is standard about numbers doesn't work for them. I don't think there's a compeling reason about changing this behavior, specially because it's what's specified in the IEEE 754. There is a really compelling reason: If the order on floating point numbers is partial then there is no meaningful Ord instance for them. And what do Hugs and GHCi say? Their answers are plain horror: Hugs, version 20050308: compare (0 / 0) (0 / 0) = EQ 0 / 0 == 0 / 0 = False GHCi 6.8.2: compare (0 / 0) (0 / 0) = GT 0 / 0 0 / 0 = False Anyone interested in filing bug reports? […] Best wishes, Wolfgang ___ 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: Why purely in haskell?
Wolfgang Jeltsch protests (all this is about pathologies of the floating point computations in Haskell, of course...): Please don’t suggest that “illegalizing” some Ord instance is similar to killing people out of religious motives. Did I? Where?? This is silly... I admit that I have over-reacted to Ketil, I didn't notice that he proposed the bombing reaction as an *option*, not as the Only True way of dealing with NaNs. I am sorry, although then Ketil seems saying that raising the exception *is* the correct approach, while I think it is not, being too brutal. OK, probably the best for people who learn the language. No good for professionals, and impossible for some library procedures. But *you* seem to have decided that all weakness in treating exceptional values is absolutely wrong and sinful. The analogy with religious issues is weak, there is simply a thought pattern of purists who want to break the existing imperfections in name of their visions. You demonstrate this kind of absolute thinking through the usage of the clause as a whole: Even if I don’t use numerics, I do care about the Haskell language as a whole. Your name is Legion... But I think that Lennart is right. *DO* something positive. In other terms, instead of destroying an existing church, gather some followers, and make your own. Seriously. No type Double, but something possessing variants: * Float2 (regular) * UnderF (non-normalizable, underflow fl.p.) * PositiveInfinity | NegativeInfinity * NaN Mantissa [where Mantissa is a restricted numerical thingie, their number is the no. of floats between 0.5 and 1] etc. With appropriate arithmetic operators. And if you are unhappy with: blahblah = False, but: compare blah blah giving GT, please tell what do you think SHOULD be the answer. I say that those operators are being used outside their allowed domain. Any answer is bad. Exception? Maybe... Better: leave it... But anyway, I don't buy this: if (==) yields false when comparing a value with itself, this can break code (like a set implementation) which relies on certain guarantees. In pathological cases you are not allowed really to use the word itself as casually as you would like to. I agree that The fact that Haskell allows to define (==) rather arbitrarily doesn’t mean that the use of arbitrary definitions of (==) is what we want. The problem of equality/identity of things relies partially in the fact that it is a human construction. The Nature does not compare things for equality. So, the arbitrariness is unavoidable. My impression is that staying close to math is good from a software technology point of view. And it has the advantage of less confusion for the user. What does it mean close to math? How close? Does math raise exceptions upon the division by zero? Does *MATH* answer the question what is: (0/0)==(0/0) ? Nope! David Roundy says ... Prelude x/x NaN The true answer here is that x/x == 1.0 (not 0 or +Infinity), but there's no way for the computer to know this, so it's NaN. His comment uses not very legally the word true, even in quotes. Who is to say what the truth mean here? We cannot oblige the computer to interpret the division operator as we think, in math terms! Wherever you look, you will see some red lines not to neglect. If the physical processes which implement real arithmetics are far from true real math, trying to purify a programming language to make it more math- oriented serves nobody. Or the Devil... We are discussing simple things, but I have seen already a guy who claimed that all computer logic is inherently wrong because of the Gödel's theorem... This is a neverending discussion. I don’t see what’s so extreme about suggesting that IEEE floating point comparison should maybe be a seperate operator. You were more picky than that. Here, I would only repeat that this - for me - is not just a question of operators, but of the *type* of numbers. And I think, it is really inappropriate to compare this to horrible sects and doctrines. Ugh... Again. Sorry if you took it personally. But a doctrine is just that, a system which is meant to be autoritative, and if applied, then without discussion. Usually based on personal visions of one or a few people. It doesn't need to be negative nor horrible, although often is. http://en.wikipedia.org/wiki/Doctrine I mentioned a particular variant of doctrinal thinking: the *purification* of existing. It doesn't need to be dangerous, but often is... An anecdote. At the time of Konrad Duden (Vater der deutschen Rechtschreibung, 1829–1911 as you probably know much better than I...) there was a tendency to purify the German language, full of foreign words, roots, forms, etc. There is a story of one of such words, the shortwriting: stenography. Stenografie. Who needs Greek? And a good Germanic word has been proposed: Kurzschrift. Yes! Please - (if you are not German, they don't need to do that) - repeat a few
Re: [Haskell-cafe] type questions again....
2008/1/11 Nicholls, Mark [EMAIL PROTECTED]: Can someone explain (in simple terms) what is meant by existential and universal types. Preferably illustrating it in terms of logic rather than lambda calculus. Well, I don't know about logic. While they are certainly related to existential and universal types in logic, I don't really see a way to explain them in terms of that. Universal types are easy, you use them every day in Haskell. Take for example id: id :: a - a Or better illustrated (using ghc extension): id :: forall a. a - a That means that for any type a I pick, I can get a value of type a - a from id. If you wrap an existential type up in a constructor, not much changes: newtype ID = ID (forall a. a - a) ID can hold any value of type forall a. a - a; i.e. it can hold any value which exhibits the property that it can give me a value of type a - a for any type a I choose. In this case the only things ID can hold are id and _|_, because id is the only function that has that type. Here's how I might use it: applyID :: ID - (Int,String) - (Int,String) applyID (ID f) (i,s) = (f i, f s) Note how I can use f, which is a universal type, on both an Int and a String in the same place. You can also put typeclass constraints on universals. Take the universal type forall a. Num a = a - a. Among functions that have this type are: add1 :: forall a. Num a = a - a add1 x = x + 1 id' :: forall a. Num a = a - a id' = id -- it doesn't have to use the constraint if it doesn't want to Wrapping this up in a constructor: newtype NUM = NUM (forall a. Num a = a - a) We can create values: NUM add1 :: NUM NUM id :: NUM And use them: applyNUM :: NUM - (Int, Double) - (Int, Double) applyNUM (NUM f) (i,d) = (f i, f d) Existential types are dual, but you need to use constructors to use them. I'll write them using GADTs, because I think they're a lot clearer that way: data NUM' where NUM' :: Num a = a - NUM' Look at the type of the constructor NUM'. It has a universal type, meaning whatever type a you pick (as long as it is a Num), you can create a NUM' value with it. So the type contained inside the NUM' constructor is called existential (note that NUM' itself is just a regular ADT; NUM' is not existential). So when you have: negNUM' :: NUM' - NUM' negNUM' (NUM' n) = NUM' (negate n) Here the argument could have been constructed using any numeric type n, so we know very little about it. The only thing we know is that it is of some type a, and that type has a Num instance. So we can perform operations to it which work for any Num type, such as negate, but not things that only work for particular Num types, such as div. doubleNUM' :: NUM' - NUM' doubleNUM' (NUM' n) = NUleM' (n + n) We can add it to itself, but note: addNUM' :: NUM' - NUM' - NUM' addNUM' (NUM' a) (NUM' b) = NUM (a + b) -- Illegal! We can't add them to each other, because the first argument could have been constructed with, say, a Double and the other with a Rational. But do you see why we're allowed to add it to itself? How about this: data Variant where Variant :: a - Variant This is a type that can be constructed with any value whatsoever. Looks pretty powerful... but it isn't. Why not? Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 0/0 1 == False
On Fri, Jan 11, 2008 at 02:54:20PM +0100, Achim Schneider wrote: +-0 / +-0 is always NaN 'cos you can't tell which one is bigger and thus can't decide between positive and negative Infinity, and it isn't both, either. But then there's +0/0 and -0/0, which would be +Infinity and -Infinity, and +0 0 -0. AFAIK there are no floats with three zero values, though. No, +0/0 might be 0 or finite instead of +Infinity, so it's a NaN. e.g. consider Prelude let x=1e-300/1e300 Prelude x 0.0 Prelude x/x NaN The true answer here is that x/x == 1.0 (not 0 or +Infinity), but there's no way for the computer to know this, so it's NaN. -- 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: Why purely in haskell?
Cristian Baboi writes after my long political speech on numerics: Well, Haskell has this referential transparency thing which say that a function is a function and you will never be able to build anything else :-) What do you want to say/claim/suggest/propose/deny?? All these speculations about NaN==NaN, and other disgraceful exceptions don't convey anything which would really break the referential transparency, unless you outlaw yourself. Travesting a US military saying: If 'em things are not comparable, don't! We can formalize this attitude, e.g. by extending/modifying the Num (and the Eq and Ord) classes to take into account the specificity of the non-standard arithmetic, but in general this contains plenty of traps. It will be eventually done, but perhaps not tomorrow... Ketil Malde reacts to: The bombing of NaN *might* be a profound compilation option, but for people who really do numerical work, this is a blessing NOT to have it. I don't understand this. Are you worried users will edit the language pragmas in your code, and complain about NaN errors? I do not worry about anything. I signal that the philosophy of crashing the program as soon as an exceptional number is created (or even used), is not the only one possible. Back when I *was* using the abbreviation FP for 'Floatin Point', I often got NaNs due to programming errors. Given the NaN's nature of contaminating subsequent results, getting an exception at the first occurrence would aid in tracking it down. - Ignoring Int overflow is a cheap way of having `mod` (MAXINT+1). Useful for many purposes. ...and ditto for this. The usefulness of one case in no way justifies sabotagin all other cases. As I said, the exceptional treatment of exceptional values might be a compilation option, as it was in some Fortrans I used long time ago. You want your programs to react histerically to all difficulties in math, since you are afraid of propagating NaNs, etc. And *then* you will have to sit down and correct your code. If there is no exception, your program may run happily, and produce rubbish, yes? I am more conservative. If you are afraid of rubbish, protect your code by appropriate checks *before* the errors occur. What you call a sabotage I call the programmers negligence. You say that the usage of NaN as empty is a poor man's way of spelling Maybe Double. I presume you want to say Nothing. In a sense yes, but not poor man. It is a way of admitting that we have a hidden extended type, Nums, and other stuff, such as NaNs and infinities. Floating-point numbers seem not to be a *one* pure, primitive type, but a variant one. The problem is that this new type values may come out of computations on normal values, so the static type system of Haskell *in its actual shape* seems to be a bit too weak. Instead of making a mess with the existing structures, please, propose a non-standard Num class, and the appropriate instancing, which distinguish between normal, and anormal numbers. Be free to bomb, or to react silently to exceptional values. The difference between you (and/or Wolfgang J.) and myself is that I enjoy more my freedom, even if I have to pay with a little more work. You want to enforce rigid reactions of the system. You should be free to do it on *your* machine, not on mine. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Not to load Prelude
Maurício wrote: Is it possible not to load Prelude (...) (...) NoImplicitPrelude is more aggressive than 'import Prelude()'. You will have to look elsewhere for a better explanation of the difference. I tried google and ghc homepage, but could not find “elsewhere” :) Can you give me a link or somewhere to start from? I often find it easier, rather than doing a full Google search, to start with a Search haskell.org on the front page here http://haskell.org/ This is a Google site search of *.haskell.org/* But ignore the type-in search box and button at the top of the front page - they don't work properly. Richard. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] type questions again....
Can someone explain (in simple terms) what is meant by existential and universal types. Preferably illustrating it in terms of logic rather than lambda calculus. There's plenty of stuff out there on itbut most of it seems double dutch (no offense to the dutch intended). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: 0/0 1 == False
Ketil Malde [EMAIL PROTECTED] wrote: Achim Schneider [EMAIL PROTECTED] writes: You need to use the / operator, if you want to do floating-point division. Yes, exactly, integers don't have +-0 and +-infinity... only (obviously) a kind of nan. No, failure (exception, bottom) is different from NaN, which is just another value in the domain - admittedly one which behaves rather strangely. s/a kind of/not entirely unlike a/ Said differently: I don't know a thing about floats or numerics. Perhaps it helps to think of floating point values as intervals? If +0 means some number between 0 and the next possible representable number (and similar for -0), it may make more sense to have 1/+0 and 1/-0 behave differently. Hmmm... ah. +-0 / +-0 is always NaN 'cos you can't tell which one is bigger and thus can't decide between positive and negative Infinity, and it isn't both, either. But then there's +0/0 and -0/0, which would be +Infinity and -Infinity, and +0 0 -0. AFAIK there are no floats with three zero values, though. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
Actually, here's a better example: Prelude foldl (+) 0 [1..100] *** Exception: stack overflow Prelude Data.List foldl' (+) 0 [1..100] 5050 The explanation to what happens here is trivial to Haskell gurus but completely baffling to newbies. It is difficult to explain to someone why the first example doesn't work, although at a glance it should. The virtue of laziness is that allows constructs like [1..100], but the downside is that it can bite you on the backside when you least expect it. Niko ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Next PDXFunc Meeting (Portland/Oregon FP Group): Monday, January 14, 7pm, CubeSpace
Join us at the next meeting of pdxfunc, the Portland Functional Programming Study Group, on Monday, 14th January, at CubeSpace. We'll have presentations, demos and discussions. We welcome programmers interested in all functional languages and our meetings have content for coders of all skill levels. If interested, please also subscribe to our mailing list at http://groups.google.com/group/pdxfunc PRESENTATIONS (1) Justin Bailey: Exploring Haskell's space and time profiling tools A presentation on the space and time profiling tools available for GHC Haskell, featuring slides and interactive demos. Heap profiling tools and methods will be discussed, along with a demonstration of how to use them to detect a space leak. Time profiling tactics will be covered using cost-centre annotations to help select candidates for optimization. Recommendations will be given on how to read the Core language with an eye for optimization. Justin Bailey ([EMAIL PROTECTED]) has been programming professionally for 12 years, and is currently a Computer Science master's student at Portland State University. Until 2006, he coded exclusively with object-oriented languages like Java and C#, but then discovered Haskell and hasn't looked back. He's released a Haskell library for building command-line applications called HCL, made contributions to several other Haskell libraries, and continues to hack Haskell every day he can. (2) Iavor Diatchki: Writing parsing combinators with Haskell A presentation on parsing combinators, given as a hands-on demonstration for developing a small library to parse JSON data using Haskell. The entire process will be shown from scratch, starting with defining the concept of JSON values, using pretty-printer combinators to turn values into strings, and finally using parser combinators to turn strings into values. Iavor S. Diatchki is an engineer at Galois Inc., where he uses functional programming for the development of high assurance software. Iavor obtained his PhD degree in 2007. His research focused on various aspect of using functional languages for the development of low-level systems software such as OS kernels. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type questions again....
On 11/01/2008, Nicholls, Mark [EMAIL PROTECTED] wrote: Preferably illustrating it in terms of logic rather than lambda calculus. There's plenty of stuff out there on it….but most of it seems double dutch (no offense to the dutch intended). I think the preferred idiom, considering the notation, is that it's all Greek to me ;-) D -- Dougal Stanton [EMAIL PROTECTED] // http://www.dougalstanton.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: 0/0 1 == False
David Roundy [EMAIL PROTECTED] wrote: Prelude let x=1e-300/1e300 Prelude x 0.0 Prelude x/x NaN The true answer here is that x/x == 1.0 (not 0 or +Infinity), but there's no way for the computer to know this, so it's NaN. Wl.. math philosophy, Ok. You can't divide something in a way that uses no slices. You just don't cut, if you cut zero times. Which is what you do when you divide by one, mind you, not when you divide by zero. Division by [1..0] equals multiplication by [1..]. You can't get to the end of either spectrum, just axiomatically dodge around the singularities to axiomatically connect the loose ends. There is no true answer here, the question is wrong. And you're using floats where only rationals can tackle the problem. I was wrong in claiming that But then there's +0/0 and -0/0, which would be +Infinity and -Infinity, and +0 0 -0. AFAIK there are no floats with three zero values, though. , both are NaN. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type questions again....
On Jan 11, 2008 5:47 PM, Nicholls, Mark [EMAIL PROTECTED] wrote: If you wrap an existential type up in a constructor, not much changes: If you wrap a what?should this read existential or universal? Whoops, right, universal. newtype ID = ID (forall a. a - a) ID can hold any value of type forall a. a - a; i.e. it can hold any value which exhibits the property that it can give me a value of type a - a for any type a I choose. In this case the only things ID can hold are id and _|_, because id is the only function that has that type. Here's how I might use it: It's the only function you've defined the type of Id2 :: forall a. a - a Now it can hold id2? Well, that's not what I meant, but yes it can hold id2. What I meant was that, in this case, id2 = _|_ or id2 = id, there are no other possibilities. id' :: forall a. Num a = a - a id' = id -- it doesn't have to use the constraint if it doesn't want to it doesn't have to use the constraint if it doesn't want to ? If id was of type.. Id::forall a. Ord a = a - a Then I assume it would complain? Yes. but you need to use constructors to use them. I'll write them using GADTs, because I think they're a lot clearer that way: data NUM' where NUM' :: Num a = a - NUM' Look at the type of the constructor NUM'. It has a universal type, meaning whatever type a you pick (as long as it is a Num), you can create a NUM' value with it. yes and then it goes wrong... So the type contained inside the NUM' constructor ? is called existential (note that NUM' itself is just a regular ADT; NUM' is not existential). Why existentialsee below...I have a guess Okay, I was being handwavy here. Explaining this will allow me to clear this up. If you take the non-GADT usage of an existential type: data Foo = forall a. Num a = Foo a That is isomorphic to a type: data Foo = Foo (exists a. Num a = a) Except GHC doesn't support a keyword 'exists', and if it did, it would only be able to be used inside constructors like this (in order for inference to be decidable), so why bother? That's what I meant by the type inside the constructor, Foo is not existential, (exists a. Num a = a) is. So when you have: negNUM' :: NUM' - NUM' negNUM' (NUM' n) = NUM' (negate n) Here n has an existential type, specifically (exists a. Num a = a). Here the argument could have been constructed using any numeric type n, so we know very little about it. The only thing we know is that it is of some type a, and that type has a Num instance. I think one of the harrowing things about Haskell is the practice of overloading data constructors with type namesit confuses the hell out of me Yeah that took a little getting used to for me too. But how am I supposed to come up with enough names if I want to name them differently!? That would require too much creativity... :-) OK so this declaration says that forall x constructed using NUM' n...there *exists* a type T s.t. T is a member of type class NUM... (you probably meant type class Num here) which in term implies that that there exists the function negate... yes? Huh, I had never thought of it like that, but yes. I just realized that I think of programming in a way quite different than I think of logic. Maybe I should try to have my brain unify them. doubleNUM' :: NUM' - NUM' doubleNUM' (NUM' n) = NUleM' (n + n) We can add it to itself, but note: addNUM' :: NUM' - NUM' - NUM' addNUM' (NUM' a) (NUM' b) = NUM (a + b) -- Illegal! We can't add them to each other, because the first argument could have been constructed with, say, a Double and the other with a Rational. But do you see why we're allowed to add it to itself? We can add it to itself because + is of type a-a-a... Yep, so whatever type a n happens to have, it matches both arguments. How about this: data Variant where Variant :: a - Variant This is a type that can be constructed with any value whatsoever. Looks pretty powerful... but it isn't. Why not? Eeek. Because a could be of any type whatsover?...so how I actually do anything with it? Right. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
Cristian Baboi [EMAIL PROTECTED] wrote: On Fri, 11 Jan 2008 09:11:52 +0200, Lennart Augustsson [EMAIL PROTECTED] wrote: Some people seem to think that == is an equality predicate. This is a big source of confusion for them; until they realize that == is just another function returning Bool they will make claims like [1..]==[1..] having an unnatural result. The == function is only vaguely related to the equality predicate in that it is meant to be a computable approximation of semantic equality (but since it's overloaded it can be anything, of course). So let's imagine: ones = 1 : ones ones' = repeat 1 where repeat n = n : repeat n (==) :: Eq a = a - a - Bool -- what is (y (y) ) by the way ? -- how about ( y id ) ? y f = f (y f). ones :: Num a = [a] ones = y (1 :) repeat :: a - [a] repeat = \n - y (n:) ones' :: Num a = [a] ones' = repeat 1 = (\n-y(n:)) 1 = y (1 : ) To be able to test them for equality, we must have Eq a. So, the reason we cannot test them for equality is that we cannot test y (a : ) == y (a : ) where a == a is testable. Yes, thanks. I actually do think that many things would be easier if every recursion would be translated to its fixpoint, making the term tree completely finite and defining y internal, as it's arcane, black magic. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Gtk2HS and GHC 6.8.2
It seems GHC 6.8.2 fixes a couple of bugs in GHC 6.8.1, so I'm using that one. Gtk2HS does not yet detect my GHC 6.8.2 installation, but I guess it is 100% compatible. Is it possible to get the Gtk2HS installer detect GHC 6.8.2? I’m on Windows. Thanks again, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] type questions again....
-Original Message- From: Luke Palmer [mailto:[EMAIL PROTECTED] Sent: 11 January 2008 17:11 To: Nicholls, Mark Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] type questions again 2008/1/11 Nicholls, Mark [EMAIL PROTECTED]: Can someone explain (in simple terms) what is meant by existential and universal types. Preferably illustrating it in terms of logic rather than lambda calculus. Well, I don't know about logic. While they are certainly related to existential and universal types in logic, I don't really see a way to explain them in terms of that. Universal types are easy, you use them every day in Haskell. Take for example id: id :: a - a Or better illustrated (using ghc extension): id :: forall a. a - a That means that for any type a I pick, I can get a value of type a - a from id. Yepit's universal because forall types a. If you wrap an existential type up in a constructor, not much changes: If you wrap a what?should this read existential or universal? newtype ID = ID (forall a. a - a) ID can hold any value of type forall a. a - a; i.e. it can hold any value which exhibits the property that it can give me a value of type a - a for any type a I choose. In this case the only things ID can hold are id and _|_, because id is the only function that has that type. Here's how I might use it: It's the only function you've defined the type of Id2 :: forall a. a - a Now it can hold id2? applyID :: ID - (Int,String) - (Int,String) applyID (ID f) (i,s) = (f i, f s) Note how I can use f, which is a universal type, on both an Int and a String in the same place. Yep. You can also put typeclass constraints on universals. Take the universal type forall a. Num a = a - a. Among functions that have this type are: add1 :: forall a. Num a = a - a add1 x = x + 1 id' :: forall a. Num a = a - a id' = id -- it doesn't have to use the constraint if it doesn't want to it doesn't have to use the constraint if it doesn't want to ? If id was of type.. Id::forall a. Ord a = a - a Then I assume it would complain? Wrapping this up in a constructor: newtype NUM = NUM (forall a. Num a = a - a) We can create values: NUM add1 :: NUM NUM id :: NUM And use them: applyNUM :: NUM - (Int, Double) - (Int, Double) applyNUM (NUM f) (i,d) = (f i, f d) Yep. Existential types are dual, Dual? (like a dual basis rather than double?) but you need to use constructors to use them. I'll write them using GADTs, because I think they're a lot clearer that way: data NUM' where NUM' :: Num a = a - NUM' Look at the type of the constructor NUM'. It has a universal type, meaning whatever type a you pick (as long as it is a Num), you can create a NUM' value with it. yes and then it goes wrong... So the type contained inside the NUM' constructor ? is called existential (note that NUM' itself is just a regular ADT; NUM' is not existential). Why existentialsee below...I have a guess So when you have: negNUM' :: NUM' - NUM' negNUM' (NUM' n) = NUM' (negate n) Here the argument could have been constructed using any numeric type n, so we know very little about it. The only thing we know is that it is of some type a, and that type has a Num instance. I think one of the harrowing things about Haskell is the practice of overloading data constructors with type namesit confuses the hell out of me OK so this declaration says that forall x constructed using NUM' n...there *exists* a type T s.t. T is a member of type class NUM... which in term implies that that there exists the function negate... yes? It's existential...because the word exists occurred in the above translation. So we can perform operations to it which work for any Num type, such as negate, but not things that only work for particular Num types, such as div. Because the existence of the value implies the existence of a type in the typeclass? doubleNUM' :: NUM' - NUM' doubleNUM' (NUM' n) = NUleM' (n + n) We can add it to itself, but note: addNUM' :: NUM' - NUM' - NUM' addNUM' (NUM' a) (NUM' b) = NUM (a + b) -- Illegal! We can't add them to each other, because the first argument could have been constructed with, say, a Double and the other with a Rational. But do you see why we're allowed to add it to itself? We can add it to itself because + is of type a-a-a... I think How about this: data Variant where Variant :: a - Variant This is a type that can be constructed with any value whatsoever. Looks pretty powerful... but it isn't. Why not? Eeek. Because a could be of any type whatsover?...so how I actually do anything with it? Don't know complete guess really. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org
Re: [Haskell-cafe] Field updates in a state monad
On Thu, 10 Jan 2008, Michael Roth wrote:
Hello list,
still playing with monads and states, I have the following question:
Given:
import Control.Monad.State.Lazy
data MyData = MyData { content :: String }
foobar :: State MyData String
foobar = do
gets content
Ok, that looks nice and tidy. But:
foobar2 :: State MyData ()
foobar2 = do
modify $ \x - x { content = hello haskell}
...looks not so nice.
Exists there a way to write this cleaner without writing countless
set_xyz helper functions?
http://www.haskell.org/haskellwiki/Record_access
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Not to load Prelude
On Jan 11, 2008 8:13 PM, Jeremy Shaw [EMAIL PROTECTED] wrote: At Thu, 10 Jan 2008 22:16:27 -0200, Maurício wrote: I tried google and ghc homepage, but could not find elsewhere :) Can you give me a link or somewhere to start from? No. What I meant to say was, I'm not really sure myself, I just know there is a difference and -fno-implicit-prelude is more aggressive. I you do find a clear explaination, I would love to see it. So, when you write the number 3 in Haskell, GHC converts this to essentially (Prelude.fromInteger (3::Integer)) in its internal format. So it doesn't matter if you import Prelude (), Prelude's version of fromInteger still gets called. If you give -fno-implicit-prelude, then this is converted to simply (fromInteger (3::Integer)), without the hard-coded prelude reference. That means you could write your own version of fromInteger that does something different. A common usage for -fno-implicit-prelude (insofar as it is used at all, which is seldom) is to replace the standard Num hierarchy with a saner one, with numeric literals resolving to that one instead. There are a few other hard-coded references to Prelude in the internal format, but I don't remember what they are offhand. -fno-implicit-prelude gets rid of those, too. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments and suggestions on code
On Fri, 2008-01-11 at 20:20 -0200, Andre Nathan wrote:
Both versions which use getDirectoryContents also use much more memory
than the one which uses readDirStream (about 8M vs about 2M). Maybe I'm
not exploting getDirectoryContents' laziness correctly? I expected the
second and third versions to run in about the same time.
Forgot to paste the code...
foo :: IO ()
foo = do
entries - getDirectoryContents .
let procs = filter (=~ ^[0-9]+$) entries
mapM_ putStrLn procs
processEntry :: DirStream - IO ()
processEntry ds = do
entry - readDirStream ds
if entry =~ ^[0-9]+$
then do
putStrLn entry
processEntry ds
else
if entry == then return () else processEntry ds
bar :: IO ()
bar = do
ds - openDirStream .
processEntry ds
closeDirStream ds
processEntry' :: FilePath - IO ()
processEntry' entry = do
if entry =~ ^[0-9]+$
then putStrLn entry
else return ()
baz :: IO ()
baz = do
entries - getDirectoryContents .
mapM_ processEntry' entries
main = forM_ [1..1000] $ \_ - foo {- bar -} {- baz -}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Not to load Prelude
On Fri, 11 Jan 2008, Luke Palmer wrote: So, when you write the number 3 in Haskell, GHC converts this to essentially (Prelude.fromInteger (3::Integer)) in its internal format. So it doesn't matter if you import Prelude (), Prelude's version of fromInteger still gets called. If you give -fno-implicit-prelude, then this is converted to simply (fromInteger (3::Integer)), without the hard-coded prelude reference. That means you could write your own version of fromInteger that does something different. A common usage for -fno-implicit-prelude (insofar as it is used at all, which is seldom) is to replace the standard Num hierarchy with a saner one, with numeric literals resolving to that one instead. There are a few other hard-coded references to Prelude in the internal format, but I don't remember what they are offhand. -fno-implicit-prelude gets rid of those, too. For details, see: http://www.haskell.org/ghc/docs/latest/html/users_guide/ghc-language-features.html I have summarized the answers so far: http://www.haskell.org/haskellwiki/No_import_of_Prelude ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 0/0 1 == False
Also, there are only two zeros, +0 and -0 and they compare equal. On Jan 11, 2008 10:12 AM, Achim Schneider [EMAIL PROTECTED] wrote: I was wrong in claiming that But then there's +0/0 and -0/0, which would be +Infinity and -Infinity, and +0 0 -0. AFAIK there are no floats with three zero values, though. , both are NaN. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ 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] where is the FFI glue code for STM?
Hello, I see where the top level code (written in Haskell)for STM. I have found STM.c;however, I can't seem to find the FFI glue code.? Thanks, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] where is the FFI glue code for STM?
On Fri, Jan 11, 2008 at 06:15:52PM -0600, Galchin Vasili wrote: Hello, I see where the top level code (written in Haskell)for STM. I have found STM.c;however, I can't seem to find the FFI glue code.? Thanks, Vasili There isn't any. readTVar# etc are primops. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On 11 Jan 2008, at 5:13 AM, Achim Schneider wrote: Jonathan Cast [EMAIL PROTECTED] wrote: What kind of mathematics? I don't know of any mathematics where algebraic simplifications are employed without proof of the underlying equations (in some denotational model). Mathematics as, as my professor put it, Solving by staring. Professor of what? I would have been flunked for such an approach. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 0/0 1 == False
On 11 Jan 2008, at 10:12 AM, Achim Schneider wrote: David Roundy [EMAIL PROTECTED] wrote: Prelude let x=1e-300/1e300 Prelude x 0.0 Prelude x/x NaN The true answer here is that x/x == 1.0 (not 0 or +Infinity), but there's no way for the computer to know this, so it's NaN. Didn't catch this the first time around, but: only to a physicist. (I mean no disrespect to the author of darcs, but nevertheless the point stands). Back in the real world, 0 / 0 may be defined arbitrarily, or left undefined. (Defining it breaks the wonderful property that, if lim (xn) = x, lim (yn) = y, and x/y = z, then lim (xn / yn) = z. This is considered a Bad Thing by real mathematicians). In fact, in integration theory 0 * inf = 0 for certain 'multiplications', which gives the lie to 0 / 0. Wl.. math philosophy, Ok. You can't divide something in a way that uses no slices. You just don't cut, if you cut zero times. Which is what you do when you divide by one, mind you, not when you divide by zero. Division by [1..0] equals multiplication by [1..]. Right. (Although 0 * inf is defined by fiat, as noted above). You can't get to the end of either spectrum, just axiomatically dodge around the singularities to axiomatically connect the loose ends. `Axiomatically' --- you mean by re-defining standard notation like * and / to mean what you need in this case. I think this is a different thing than setting up ZFC so everyone agrees on what a `set' is from henceforth. There is no true answer here, the question is wrong. Exactly. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments and suggestions on code
On 11 Jan 2008, at 7:27 AM, Andre Nathan wrote: On Thu, 2008-01-10 at 20:37 -0800, Jonathan Cast wrote: It might be faster; laziness usually has higher constants than direct implementations. But I doubt the difference is critical in this case, and I would definitely time a re-writing and throw it away unless it was significantly faster. But I don't think this is a case where laziness actually alters either the time or the space asymptotics of the algorithm (you end up creating an ~ O(n) tree anyway, so I'd figure O(n) space was OK for the loop, too). I was wondering if laziness would make it run as if it was a single O(n) operation (get one directory entry on demand, pass it to filter and then to insertInTree), That should be the evaluation order, yes. I think big-O notation is the wrong notation for this; you get a single loop with three sequenced operations, rather than three sequenced loops, but both are O(n). because only one entry is used at a time, so that only the current entry needs to be evaluated. I still find it hard to evaluate the effects of laziness on the complexity of programs... jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments and suggestions on code
On 11 Jan 2008, at 2:20 PM, Andre Nathan wrote: On Fri, 2008-01-11 at 13:27 -0200, Andre Nathan wrote: I was wondering if laziness would make it run as if it was a single O(n) operation (get one directory entry on demand, pass it to filter and then to insertInTree), because only one entry is used at a time, so that only the current entry needs to be evaluated. I did some experiments. This for 1000 reads of the entries of a directory with 1 entries, checking if they match ^[0-9]+$ and printing those which do (half of them). getDirectoryEntries, filter, mapM_: 65.52s user 6.01s system 87% cpu 1:22.21 total openDirStream, readDirStream: 39.68s user 5.69s system 95% cpu 47.746 total getDirectoryContents, mapM_: 63.40s user 5.96s system 95% cpu 1:12.70 total These are all known and expected. As I said, you can expect lazy versions to normally be slower than explicit loops. The question is whether 50% more time and 300% more memory has a higher cost in your case than the extra complexity and reduced modularity of the lazy code. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments and suggestions on code
On 11 Jan 2008, at 2:24 PM, Andre Nathan wrote: processEntry :: DirStream - IO () processEntry ds = do entry - readDirStream ds if entry =~ ^[0-9]+$ then do putStrLn entry processEntry ds else if entry == then return () else processEntry ds bar :: IO () bar = do ds - openDirStream . processEntry ds closeDirStream ds This is a 200% increase in code size for a 75% decrease in execution time. (And, in general, the complexity can be much higher). That's an engineering tradeoff, and one you'll have to decide yourself; there's not much that can be done to make it go away. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
Jonathan Cast [EMAIL PROTECTED] wrote: On 11 Jan 2008, at 5:13 AM, Achim Schneider wrote: Jonathan Cast [EMAIL PROTECTED] wrote: What kind of mathematics? I don't know of any mathematics where algebraic simplifications are employed without proof of the underlying equations (in some denotational model). Mathematics as, as my professor put it, Solving by staring. Professor of what? I would have been flunked for such an approach. Professor as in gives lectures, he's a Dipl. Ing... and also also as in got a Job for life, although not formally. I think his main point in telling it is to stop people from blindly expanding and reducing around. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: 0/0 1 == False
Jonathan Cast [EMAIL PROTECTED] wrote: On 11 Jan 2008, at 10:12 AM, Achim Schneider wrote: David Roundy [EMAIL PROTECTED] wrote: Prelude let x=1e-300/1e300 Prelude x 0.0 Prelude x/x NaN The true answer here is that x/x == 1.0 (not 0 or +Infinity), but there's no way for the computer to know this, so it's NaN. Didn't catch this the first time around, but: only to a physicist. (I mean no disrespect to the author of darcs, but nevertheless the point stands). Back in the real world, 0 / 0 may be defined arbitrarily, or left undefined. (Defining it breaks the wonderful property that, if lim (xn) = x, lim (yn) = y, and x/y = z, then lim (xn / yn) = z. This is considered a Bad Thing by real mathematicians). In fact, in integration theory 0 * inf = 0 for certain 'multiplications', which gives the lie to 0 / 0. whereas lim( 0 ) * lim( inf ) is anything you want, or, more precisely, the area of the thing you started with. It's like taking seven balls, assembling them into a hexagon and claiming it's a circle. Such things just happen if you are working with pure abstractions. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
