two easy questions
Question 1: Is there an easier, more elegant way to write this code? output a b c d e = println "Hello, this is " ++ show a ++ " a really hard " "to write function that " ++ show b ++ " would be easier to write with " "a printf " ++ show c ++ show d ++ show e Question 2: Is there a way to express the following relationship? I want to have a set of symbols with ordering and another set that is part of that ordering but with a different parent. For exammple, data Player = Detective | Fugitive deriving (Enum) data Detective = Red | Green | Blue deriving (Enum) data Fugitive = MrX deriving (Enum) I want (succ Blue) == MrX and (pred MrX) == Blue. I could do this by putting them all in the same enumeration but I want to be able to test that the symbol is a Detective or Fugitive. By the way, how do I test that it's a detective? Do I pattern match it? foo Detective(x) = if x == Purple then ... else ... -- ? Thanks for the help. -mike ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Interesting Read (fwd)
G'day. On Wed, Feb 19, 2003 at 09:46:02AM -0600, Rex Page wrote: > Here are two things I found interesting: > 1. The author comments that programs are not theorems. No, he argues that programming _languages_ are not theorems. All that is required of a theorem is that it is correct. A tool, on the other hand, not only has to work (i.e. it has to correctly accomplish some task), it also has to be safe to use, its controls must be meaningful to the intended user, it should be in some way better than the tool which it replaces and so on. Cheers, Andrew Bromage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
H98 errata
The definition of getLine given in 8.3:
getLine:: IO String
getLine= do c <- getChar
if c == '\n' then return "" else
do s <- getLine
return (c:s)
is incorrect in view of
7.1: The getLine operation raises an exception under the same
circumstances as hGetLine, defined [in] the IO library.
("in" is missing from the published Report.)
21.9.2: The hGetLine computation fails with isEOFError if the end of file
is encountered when reading the first character of the line. If hGetLine
encounters end-of-file at any other point while reading in a line,
it is treated as a line terminator and the (partial) line is returned.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Interesting Read (fwd)
Iavor S. Diatchki wrote: my programs always prove IO(). this must be the best proven theorem in Haskell. and people just keep on proving it :-) I believe that I have proven more often that undef = undef and my students prove usually that GHC typechecker is a nasty, unforgiving beast. Jerzy Karczmarczuk (of course this posting belongs rather to the list haskell-beer ...) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Interesting Read (fwd)
hi, Rex Page wrote: ... 1. The author comments that programs are not theorems. He is correct. They are, instead, proofs of theorems. The problem is, programmers almost never know what theorems their programs prove. > ... my programs always prove IO(). this must be the best proven theorem in Haskell. and people just keep on proving it :-) bye iavor -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Q. about XML support (WAS: Re: Interesting Read)
Graham Klyne wrote: > > Which leads me to a question: starting from the haskell.org web page, I > have identified three XML parsers in Haskell (HaXml, hXML, Haskell XML > Toolbox), none of which seem to support XML namespaces and only one of > which claims to be tested on both HUGS and GHC. > > Can anyone offer any recommendations, or maybe pointers to other work? What are you looking for in an XML toolkit? As far as HXML goes, I have a rough sketch of an implementation of XML namespace support, not yet finished or released. (This is a somewhat thorny problem; implementing XMLNS is not hard, but implementing it in a sane way requires some ingenuity.) --Joe English [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Interesting Read (fwd)
Here are two things I found interesting: 1. The author comments that programs are not theorems. He is correct. They are, instead, proofs of theorems. The problem is, programmers almost never know what theorems their programs prove. 2. All of the criteria the authors gives for "good languages" apply, in spades, to Haskell, except the point on libraries. On that one, we're pedaling as fast as we can, but there aren't enough of us. Rex Page -- Forwarded message -- Date: Tue, 18 Feb 2003 20:22:46 -0800 (PST) From: David Sankel <[EMAIL PROTECTED]> To: Haskell Mailing List <[EMAIL PROTECTED]> Subject: Interesting Read An interesting read: http://www.paulgraham.com/popular.html Any thoughts? David J. Sankel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: effect of order of function arguments
Aaron Denney <[EMAIL PROTECTED]> writes: > With a recursive function of more than one argument, does it make sense > to keep the arguments that tend to remain constant closer to the front? > > i.e. > > Will any implementations notice interp y x:xs calls interp y, and keep > some sort of interp y partial application around? Systems which perform lambda-lifting will usually be tuned this way, as the same optimization also speeds up tail recursion. For example: interp y xs = interpaux xs where interpaux [] = ... interpaux (x:xs) = ... interpaux xs ... Will be lambda-lifted to the original interp definition, with an extra call: interp y xs = interpaux y xs interpaux y [] = ... interpaux y (x:xs) = ... interpaux y xs ... This one of the reasons nhc does this optimization, I'm sure. I know the Eager Haskell compiler avoids pushing and popping the invariant arguments from the stack during a tail call; I recall that hbc does so as well. -Jan-Willem Maessen Eager Haskell Project [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Interesting Read (and Q. about XML support)
At 08:22 PM 2/18/03 -0800, David Sankel wrote: An interesting read: http://www.paulgraham.com/popular.html Any thoughts? "To become popular, a programming language has to be the scripting language of a popular system." Interesting thought... I'm learning Haskell with a view to using it as a "scripting language for semantic web inference". ... Which leads me to a question: starting from the haskell.org web page, I have identified three XML parsers in Haskell (HaXml, hXML, Haskell XML Toolbox), none of which seem to support XML namespaces and only one of which claims to be tested on both HUGS and GHC. Can anyone offer any recommendations, or maybe pointers to other work? #g --- Graham Klyne <[EMAIL PROTECTED]> ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: effect of order of function arguments
| GHC used to have an optimisation for static argument like this. It would | turn both of the above programs into a similar form using a local | recursive function: | | interp y xs = interpaux xs | where interpaux [] = [] | interpaux (x:[]) = x:[] | interpaux (x:xs) = x:y:interpaux xs | | GHC doesn't do this anymore. The reason for this is unknown to me. It turned out to be a very minor effect (1-2% of execution time) and hard to tune; with lots of parameters, it's best to make a local function, with just a few it's best to pass the parameters round. S ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: effect of order of function arguments
On Tue, 18 Feb 2003, Aaron Denney wrote: > With a recursive function of more than one argument, does it make sense > to keep the arguments that tend to remain constant closer to the front? > > I.e. is this: > > > interp :: a -> [a] -> [a] > > interp y [] = [] > > interp y (x:[]) = x:[] > > interp y (x:xs) = x:y:interp y xs > > any better than this: > > > interp :: [a] -> a -> [a] > > interp [] y = [] > > interp (x:[]) y = x:[] > > interp (x:xs) y = x:y:interp xs y > > Will any implementations notice interp y x:xs calls interp y, and keep > some sort of interp y partial application around? > > (I don't really expect any effect like this, but even if there were one, > I would expect consideration like the fact that "interp constant" is a > useful function, while "\x -> interp x const-list" is not so useful to > outweigh any such effect. Happily, they don't conflict here. If there > is no effect like this, would it make any sense to try to get something > similar by hand, and can this actually be done?) > GHC used to have an optimisation for static argument like this. It would turn both of the above programs into a similar form using a local recursive function: interp y xs = interpaux xs where interpaux [] = [] interpaux (x:[]) = x:[] interpaux (x:xs) = x:y:interpaux xs GHC doesn't do this anymore. The reason for this is unknown to me. /Josef ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: effect of order of function arguments
On Tue, 18 Feb 2003 21:59:36 -0800 Aaron Denney <[EMAIL PROTECTED]> wrote: > > With a recursive function of more than one argument, does it make > sense to keep the arguments that tend to remain constant closer to > the front? At least it is easier to use: if the list argument in foldr was the first, you ought to write f (\ x -> foldr x (+) 0) instead of f (foldr (+) 0) Choosing the argument that is "less variable" as the first argument of a function saves typing and cleans up code. Vincenzo -- Teatri vuoti e inutili potrebbero affollarsi se tu ti proponessi di recitare te [CCCP] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: effect of order of function arguments
Aaron Denney <[EMAIL PROTECTED]> writes: > With a recursive function of more than one argument, does it make sense > to keep the arguments that tend to remain constant closer to the front? i.e. > Will any implementations notice interp y x:xs calls interp y, and keep > some sort of interp y partial application around? Hugs (and before it, Gofer) implements this optimisation. It saves a small amount of memory by re-using the "root" portion of the original call in the recursive call. As far as I know, no other implementation makes use of this possibility, mainly because every system except Hugs uses vector heap cells instead of chained binary cells. I.e. in ghc, hbc, or nhc98, the function application is represented internally as ( interp y xs ) whereas in Hugs it is represented as ( ( interp y ) xs ) and the latter enables the re-use of the leading portion, whilst the former does not. Regards, Malcolm ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
effect of order of function arguments
With a recursive function of more than one argument, does it make sense to keep the arguments that tend to remain constant closer to the front? I.e. is this: > interp :: a -> [a] -> [a] > interp y [] = [] > interp y (x:[]) = x:[] > interp y (x:xs) = x:y:interp y xs any better than this: > interp :: [a] -> a -> [a] > interp [] y = [] > interp (x:[]) y = x:[] > interp (x:xs) y = x:y:interp xs y Will any implementations notice interp y x:xs calls interp y, and keep some sort of interp y partial application around? (I don't really expect any effect like this, but even if there were one, I would expect consideration like the fact that "interp constant" is a useful function, while "\x -> interp x const-list" is not so useful to outweigh any such effect. Happily, they don't conflict here. If there is no effect like this, would it make any sense to try to get something similar by hand, and can this actually be done?) -- Aaron Denney -><- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
