[GHC] #1182: splitAt does not implement H98 report behaviour,
it is too strict in 'n'
GHC
trac at galois.com
Tue Feb 27 10:04:29 EST 2007
#1182: splitAt does not implement H98 report behaviour, it is too strict in 'n'
------------------------------------+---------------------------------------
Reporter: duncan | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: libraries/haskell98 | Version: 6.6
Severity: normal | Keywords:
Difficulty: Easy (1 hr) | Testcase:
Architecture: Multiple | Os: Multiple
------------------------------------+---------------------------------------
The [http://haskell.org/onlinereport/standard-prelude.html H98 report]
defines {{{splitAt}}} by:
{{{
splitAt :: Int -> [a] -> ([a],[a])
splitAt n xs = (take n xs, drop n xs)
}}}
So we would expect:
{{{
splitAt _|_ xs = (take _|_ xs, drop _|_ xs)
}}}
however GHC's implementation is strict in 'n', that is:
{{{
split _|_ xs = _|_
}}}
These cases can be distinguished with the expression:
{{{
case splitAt undefined [] of (_,_) -> ()
}}}
Hugs has the same problem. It defines splitAt by:
{{{
splitAt n xs | n <= 0 = ([],xs)
splitAt _ [] = ([],[])
splitAt n (x:xs) = (x:xs',xs'') where (xs',xs'') = splitAt (n-1) xs
}}}
Perhaps for Haskell' we should make the report a little more lenient?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1182>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the Glasgow-haskell-bugs
mailing list