- Haskell-Cafe - Haskell.org

Parse text difficulty
by Douglas Bromley 15 Dec '04

15 Dec '04

Hi Everyone My first post to the mailing list is a cry for help. Apologies for that. I've seen an example of how this is done in the archives but I'm afraid I'm a bit more behind than the person who seemed to understand the answer so if someone could help me?? The problem is this: I've show(n) a particular data type and it shows up as: [([2,6],"British"),([1],"Charles"),([1,8],"Clarke"),([2,6],"Council"),([2],"Edinburgh"),([1],"Education"),([4],"Increasingly")] What I want to do is format that nicely into a table. The best way of doing (I thought) was to: Remove the first "[(" and final ")]" Then replace "),(" with a newline(\n) Which would give: [2,6],"British" [1],"Charles" [1,8],"Clarke" [2,6],"Council" ......etc I get the impression I may find it easier adding newlines earlier on in my program but I thought this may be the easiest way. I'll include all the code for the whole program in case it helps to see where I'm coming from. It takes an input file of text and outputs an index to an output file. My soul question and drive is to lay out the index in a nicely formatted fashion. Any help would be very much appreciated. module TextProc where -- import Prelude hiding (Word) import IO import List type Word = String -- define types type Line = String type Doc = String start :: IO () start = do putStrLn "******** Enter Choice *********" putStrLn "1. Enter Input and Output files" putStrLn "2. Exit" putStrLn "*******************************" choice <- getLine if (choice == "1") then ( do putStrLn "Type input file name:" fileNameI <- getLine text <- readFile fileNameI putStrLn "Type output file name:" fileNameO <- getLine writeFile fileNameO (makeIndex text) ) else ( do return() ) makeIndex :: Doc -> Doc -- changed so output can be written to file makeIndex = show . shorten . -- [([Int], Word)] -> [([Int], Word)] amalgamate . -- [([Int], Word)] -> [([Int], Word)] makeLists . -- [(Int, Word)] -> [([Int], Word)] sortLs . -- [(Int, Word)] -> [(Int, Word)] allNumWords . -- [(Int, Line)] -> [(Int, Word)] numLines . -- [Line] -> [(Int, Line)] splitUp -- Doc -> [Line] splitUp :: Doc -> [Line] splitUp [] = [] splitUp ls = takeWhile (/='\n') ls : -- first line (splitUp . -- split up other line dropWhile (=='\n') . -- delete 1st newLine(s) dropWhile (/='\n')) ls -- other lines numLines :: [Line] -> [(Int, Line)] numLines lines -- list of pairs of = zip [1 .. length lines] lines -- line no. & line splitWords :: Line -> [Word] -- split up lines into words splitWords [] = [] splitWords line = takeWhile isLetter line : -- first word in line (splitWords . -- split other words dropWhile (not.isLetter) . -- delete separators dropWhile isLetter) line -- other words where isLetter ch = ('a' <= ch) && (ch <= 'z') || ('A' <= ch) && (ch <= 'Z') || ('-' == ch) numWords :: (Int, Line) -> [(Int, Word)] -- attach line no. to each word numWords (number, line) = map addLineNum (splitWords line) -- all line pairs where addLineNum word = (number, word) -- a pair allNumWords :: [(Int, Line)] -> [(Int, Word)] allNumWords = concat . map numWords -- doc pairs sortLs :: [(Int, Word)] -> [(Int, Word)] sortLs [ ] = [ ] sortLs (a:x) = sortLs [b | b <- x, compare b a] -- sort 1st half ++ [a] ++ -- 1st in middle sortLs [b | b <- x, compare a b] -- sort 2nd half where compare (n1, w1) (n2, w2) = (w1 < w2) -- 1st word less || (w1 == w2 && n1 < n2) -- check no. makeLists :: [(Int, Word)] -> [([Int], Word)] makeLists = map mk -- all pairs where mk (num, word) = ([num], word) -- list of single no. amalgamate :: [([Int], Word)] -> [([Int], Word)] amalgamate [ ] = [ ] amalgamate [a] = [a] amalgamate ((n1, w1) : (n2, w2) : rest) -- pairs of pairs | w1 /= w2 = (n1, w1) : amalgamate ((n2, w2) : rest) | otherwise = amalgamate ((n1 ++ n2, w1) : rest) -- if words are same grow list of numbers shorten :: [([Int], Word)] -> [([Int], Word)] shorten = filter long -- keep pairs >4 where long (num, word) = length word > 4 -- check word >4

17 25

convergence of functions of Complex variables
by William Lee Irwin III 15 Dec '04

15 Dec '04

This does not work as expected on Complex numbers due to some odd typechecking hassles apparently associated with abs. How do I get this to typecheck for both real (e.g. Double) and Complex arguments? \begin{code} module Jacobi (sn, cn, dn, sd, cd, nd, cs, ds, ns, sc, dc, nc) where scd x k | abs k < 1e-14 = (sin x, cos x, 1) | otherwise = ((1+m)*s/(1+m*s^2), c*d/(1+m*s^2), (1 - m*s^2)/(1+m*s^2)) where k' = cos $ asin k m = -tanh(log(k')/2) (s, c, d) = scd (x/(1+m)) m sn x k = let (s,_,_) = scd x k in s cn x k = let (_,c,_) = scd x k in c dn x k = let (_,_,d) = scd x k in d sd x k = (sn x k)/(dn x k) cd x k = (cn x k)/(dn x k) nd x k = 1/(dn x k) cs x k = (cn x k)/(sn x k) ds x k = (dn x k)/(sn x k) ns x k = 1/(sn x k) sc x k = (sn x k)/(cn x k) dc x k = (dn x k)/(cn x k) nc x k = 1/(cn x k) \end{code}

4 4

Re: [Haskell-cafe] The difference between ($) and application
by Jon Cast 15 Dec '04

15 Dec '04

Derek Elkins <ddarius(a)hotpop.com> wrote: > Personally, I would mind ($) being magical. One of the nice things > about Haskell is there is practically no magic. The last thing I want > is Haskerl (http://www.dcs.gla.ac.uk/~partain/haskerl.html) runST > simply had a rank-2 type that is not expressible in Haskell 98, it > seems getting ($) to "work" would be qualitatively different. No. All that is needed for ($) to work is impredicativity (or, more precisely, for the foralls in ($)'s type to be impredicative). That is something that could easily be implemented in a compiler. I'm not clear on why it hasn't been, but the type system, in relation to an arbitrary-rank predicative system, is no more of a jump that higher-rank types were. Jonathan Cast

2 1

Monads vs. qualified types
by William Lee Irwin III 15 Dec '04

15 Dec '04

To my chagrin, I discovered that the following code was not accepted while attempting to monadify a small interpreter for a language used for calculations in permutation representations of groups. One of the critical notions here is of closure under composition, e.g. a transcript of a command to generate a set via distinguished elements is: 20> <(1 2),(1 2 3)> {(), (1 2), (1 2 3), (1 3), (1 3 2), (2 3)} and augmenting the semantics with group-theoretic joins and intersections and the like look verbose and redundant, with monadic properties to exploit for brevity readily apparent. \begin{code} data Eq t => Set t = Set [t] deriving (Ord, Read, Show) instance Eq t => Eq (Set t) where (Set xs) == (Set ys) = all (`elem` ys) xs && all (`elem` xs) ys instance Functor Set where fmap f (Set xs) = Set . nub $ map f xs instance Monad Set where return = Set . (:[]) (Set xs) >>= f = Set $ foldr union [] [ys | Set ys <- map f xs] \end{code} This, of course, presents me immediately with some nightmare where transitive closure semantics and the like are unimplementable as direct data structure properties within any monad, as constraints on the argument types of the monadic constructor are (for the moment) verboten. Is anyone looking into dealing with this so that I can do this? If not, where (which files) do I hack it into ghc? Are there already patches? -- wli

1 0

The difference between ($) and application
by Derek Elkins 15 Dec '04

15 Dec '04

> On Mon, Dec 13, 2004 at 07:49:00PM -0800, oleg at pobox.com wrote: > > The operator ($) is often considered an application operator of a > > lower precedence. Modulo precedence, there seem to be no difference > > between ($) and `the white space', and so one can quickly get used > > to treat these operators as being semantically the same. However, > > they are not the same in all circumstances. I'd like to observe an > > important case where replacing the application with ($) in a > > fully-parenthesized expression can lead to a type error. > > I think this post should go under the heading "($) considered > harmful". I've been bitten by this, and I never use ($) anymore in > place of parentheses because it's too tempting to think of it as > syntax. (Of course, it's still useful, by itself or in a slice, as a > higher-order operator.) > > Andrew I find this position ridiculous. I don't recall anyone ever posting a message about this (though I'd be far from surprised if someone did). It seems that the people who decide they need higher-rank types are capable of handling type errors involving them, and they certainly don't confuse ($) for syntax. Unless there's a realistic scenario where one suddenly decides one needs some higher-rank types and has to remove a bunch of uses of ($) but otherwise make no changes, I don't see any reason not to use ($) when you can (if you like) and not when you can't. If you ever make a mistake one way the type checker will tell you.

3 2

Re: [Haskell-cafe] local loops
by Jon Cast 14 Dec '04

14 Dec '04

Per Larsson <per(a)L4i.se> wrote: > I often use local loops in monadic code, e.g. > > main = do > ... > let loop = do > ... > if cond then loop else return () > loop > > It seems that I can encode this idiom slightly more concise with the 'fix' > operator (from Control.Monad.Fix), i.e. > > main = do > ... > fix (\loop -> do > ... > if ...) > > But is it really semantically equivalent? Is it as efficient? > > Per It is semantically equivalent. I don't know if it is as efficient; looking at the source code, I would expect GHC to inline fix anywhere it occurs, which yields your original version. Jonathan Cast

1 0

The difference between ($) and application
by Derek Elkins 14 Dec '04

14 Dec '04

> Derek Elkins wrote: > >Andrew Pimlott wrote: > >>I think this post should go under the heading "($) considered > >>harmful". I've been bitten by this, and I never use ($) anymore in > >>place of parentheses because it's too tempting to think of it as > >>syntax. > > > >I find this position ridiculous. [...] If you ever make a mistake > >one way the type checker will tell you. > > For what it's worth, this is not true in the presence of implicit > parameters: > > f :: ((?p :: Int) => Int) -> Int > f g = let ?p = 1 in g > > x,y :: Int > x = let ?p = 2 in (f ?p) ==> 1 > y = let ?p = 2 in (f $ ?p) ==> 2 > > I wouldn't mind ($) being magical, along the lines of the magical > runST in a rank-1 type system. It would be nice to be able to use it > in patterns too. > > -- Ben Moral of the story, and if I'm not mistaken, in your opinion, is not to use implicit parameters (as currently formulated). I.e. the consensus seems to be that this is implicit parameters' fault not ($)'s. Personally, I would mind ($) being magical. One of the nice things about Haskell is there is practically no magic. The last thing I want is Haskerl (http://www.dcs.gla.ac.uk/~partain/haskerl.html) runST simply had a rank-2 type that is not expressible in Haskell 98, it seems getting ($) to "work" would be qualitatively different.

1 0

Sound library?
by Jason Bailey 14 Dec '04

14 Dec '04

Would anyone know of packages out there for Haskell that support mp3's or ogg files? thanks Jason

6 9

special term describing f :: (Monad m) => (a -> m b)?
by Derek Elkins 14 Dec '04

14 Dec '04

> What is a function of the followning type called: > > f :: (Monad m) => (a -> m b) > > Is there a special term describing such a function (a function into a > monad)? > > For f in > a >>= f > is en example. > > Need it for an article/report. > > Regards/Henning Well, formally, it's called a Kleisli arrow (or morphism). A less formal term commonly used for values of type a -> m b and m b, is 'computation' or'action' (though 'action' is usually used for the specific case of IO). In "Notions of Computation and Monads" Moggi calls them 'commands'.

1 0

Named function fields vs. type classes
by Derek Elkins 14 Dec '04

14 Dec '04

> > On the other hand, it's difficult or impossible to make a list of a > > bunch of different types of things that have nothing in common save > > being members of the class. > > I've recently been playing with making, for each class C, a > "interface" datatype IC (appropriately universally and existentially > qualified so as to include a dictionary for class C), and then making > this IC an instance of class C. Then I can wrap any instance of C up > in an IC, and make a list of those. > > The casts get a bit annoying, though; the compiler can't figure out > that this IC is in some sense the maximum type in class C, and so > can't resolve things like > > f :: MyClass a => [a] -> b > f = ... > > upcast :: MyClass a => a -> IMyClass -- usually defined as an > instance of class Cast upcast x = IMyClass x > > f [upcast a, upcast b] -- yields type error > > Instead, you have to redefine f as follows: > > f' :: [IMyClass] -> b > > which is a bit annoying. > > HTH. > > --KW 8-) Not surprisingly, the wiki (http://www.haskell.org/hawiki/ExistentialTypes) has some discussion about this as well, though not too much to add to what has been said.

1 0