
Hi folks, toying a bit with splitAt and take, I have met yet another thing, I don't understand. In the Hugs Prelude, splitAt is defined splitAt n xs | n <= 0 = ( [],xs) splitAt _ [] = ([],[]) splitAt n (x:xs) = (x:xs',xs'') where (xs',xs'') = splitAt (n-1) xs whereas in the report it is described as (take n xs,drop n xs) -- I have no problem with that, since the report explicitely states that the functions need not be implemented as given there --, let's call that function bSplit (b was chosen for 'bad'). Now, as expected, splitAt takes fewer reductions than bSplit, splitAt (n+1) takes 18 reductions more than splitAt n, bSplit (n+1) takes 32 more than bSplit n (24 for take, 8 for drop). So far so good, now changing to ghci and testing that on a long list ([1 .. 1000000], [1 .. 500000]), splitting at half, then printing the two middle numbers. The first surprise was that there bSplit was faster than splitAt (roughly twice as fast). Does anybody know how that can be?? The second surprise was the variation of time needed. For the longer list, splitAt usually took 0.45 - 0.48 secs, occasionally about 0.9 secs (I think that will be due to gc), bSplit usually took 0.22 - 0.25 secs, occasionally about 0.7 secs (gc, probably). For the shorter list, splitAt took 0.22 - 0.28 secs (0.7 with gc), bSplit took 0.10 - 0.20 secs (0.6 with gc). Now, what's the explanation for that? Differences of, say, 0.03 secs or so I happily attribute to an occasional interrupt or something, but the difference between 0.10 and 0.20 I would like an explanation for. Another thing, while toying, I found out that a comparison (n <= 0) takes three reductions more than (n < 1) according to my hugs, so changing the definition of splitAt thus, we require (3*n) reductions less. But the number of reductions and speed are different things, as witnessed by the above, so would it be an improvement to replace "n <= Integerliteral"-queries by "n < Integerliteral"-queries or doesn't that make any difference at all in execution time? Finally, in several contexts I needed to cons an element to one of a pair of lists, so I defined infixr 5 &,§ (&) :: a -> ([a],[b]) -> ([a],[b]) x & (xs,ys) = (x:xs,ys) (§) :: b -> ([a],[b]) -> ([a],[b]) y § (xs,ys) = (xs,y:ys). I find them useful (though I don't like the symbols, if you have any better ideas, thx) and for splitAt, (&) saves another reduction per step. Now, I would like to have such operators supplied by the language, so is there space for them in the Prelude or in List, or does hardly anyone besides me ever need them? Have a wonderful weekend ye all, Daniel

Hi Daniel,
On Fri, 14 Jan 2005 21:57:25 +0100, Daniel Fischer
Finally, in several contexts I needed to cons an element to one of a pair of lists, so I defined
infixr 5 &,§ ^^^ Please be aware that you won't find this paragraph symbol on a uk or us keyboard. AFAIK it is just on the german one.
(&) :: a -> ([a],[b]) -> ([a],[b]) x & (xs,ys) = (x:xs,ys)
(§) :: b -> ([a],[b]) -> ([a],[b]) y § (xs,ys) = (xs,y:ys).
I find them useful (though I don't like the symbols, if you have any better ideas, thx) and for splitAt, (&) saves another reduction per step.
I think these operators should be more related to ":" like ":&" "&:" or similar. However, in my opinion this special cons operators could be just functions with a meaningful name like "consfst" and "conssnd". It would provide much more readability. Cheers, Georg -- ---- Georg Martius, Tel: (+49 34297) 89434 ---- ------- http://www.flexman.homeip.net ---------

Georg,
I think these operators should be more related to ":" like ":&" "&:" or similar. However, in my opinion this special cons operators could be just functions with a meaningful name like "consfst" and "conssnd". It would provide much more readability.
And (:&) would of course be illegal anyway. Regards, Stefan

Am Samstag, 15. Januar 2005 10:05 schrieben Sie:
Hi Daniel,
On Fri, 14 Jan 2005 21:57:25 +0100, Daniel Fischer
wrote: <snip>
Finally, in several contexts I needed to cons an element to one of a pair of lists, so I defined
infixr 5 &,§ ^^^ Please be aware that you won't find this paragraph symbol on a uk or us keyboard. AFAIK it is just on the german one.
(&) :: a -> ([a],[b]) -> ([a],[b]) x & (xs,ys) = (x:xs,ys)
(§) :: b -> ([a],[b]) -> ([a],[b]) y § (xs,ys) = (xs,y:ys).
I find them useful (though I don't like the symbols, if you have any better ideas, thx) and for splitAt, (&) saves another reduction per step.
I think these operators should be more related to ":" like ":&" "&:" or Yes, but as Stefan Holdermans already wrote, (:&) is illegal (operatornames beginning with ':' are infix Constructors). Since I use these operators mostly infix (up to now exclusively), I don't really want to type `consfst` all the time, hence I would need some stronger argument to convice me of using function names (after all, readability is to a large extent a matter of familiarity, you couldn't immediately understand ':', '+' ... either if you weren't thoroughly familiar with them).
A stronger relation to ':' is absolutely desirable, maybe something like \: and /: would be better. Cheers, Daniel

Georg Martius wrote:
infixr 5 &,§
^^^ Please be aware that you won't find this paragraph symbol on a uk or us keyboard. AFAIK it is just on the german one.
This reminds me, what symbols are valid for Haskell operators? I know that function names are: (in regex format) [A-Za-z_'][A-Za-z0-9_']*, but does that Haskell report define a definitive list of symbols that can be used in Haskell source... and how does that relate to the character set... can any symbol be used?

Keaan,
This reminds me, what symbols are valid for Haskell operators?
See Chapter 9 of the Report [1].
symbol -> ascSymbol | uniSymbol

Stefan Holdermans wrote:
symbol -> ascSymbol | uniSymbol
ascSymbol -> ! | # | $ | % | & | * | + | . | / | < | = | > | ? | @ | \ | ^ | | | - | ~ uniSymbol -> any Unicode symbol or punctuation varsym -> ( symbol {symbol | :})
So, does GHC accept more symbols than the report allows? Or would the example with the sub-section symbol cause an error? In which case what symbols are allowed in GHC, or Hugs? Keean
participants (4)
-
Daniel Fischer
-
Georg Martius
-
Keean Schupke
-
Stefan Holdermans