[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