October 2006 - Haskell-Cafe

Re: [Haskell] Replacing and improving pattern guards with PMC syntax
by Brandon Moore 02 Oct '06

02 Oct '06

kahl(a)cas.mcmaster.ca wrote: ... > So far I never considered it important to devise a concrete syntax for PMC, > but triggered by the current pattern guards thread on haskell-prime, > I now try to give a PMC syntax that blends well with Haskell. I think with some alterations your syntax would blend even better. In particular, it would be really nice to have a backwards-compatible syntax. I have designed a slightly different syntax with that goal in mind, which is described in the rest of this message. > One of my gripes with Haskell pattern matching is > that the anonymous variant, namely case expressions, > has an application to an argument built in, > and therefore does not by itself produce a function. > > However, lambda-abstraction already allows single-alternativepattern matching, so I propose to relax this to multi-alternative > pattern matching: >> length = \ >> [] -> 0 >> x : xs -> 1 + length xs I'm with you here. Extending lambda to introduce a layout group of alternatives makes sense even without the rest of the changes to matching. This isn't completely backwards-compatible, but it's pretty close. While we're at it, why not have the identifier of a top level definition introduce a layout group of alternatives, rather than requiring the name to be repeated all the time. How about take 0 _ = [] _ [] = [] n (x:xs) = x : take (pred n) ns > (Lists of alternatives correspond to the ``matchings'' of PMC, > and concatenation of those lists (using ``;'' or layout) corresponds > to matching alternative in PMC. > ``\ m'' then corresponds to ``{| m |}'' in PMC. > ) > > For multi-argument pattern matching, > I propose to allow nested matchings: >> zip = \ >> x : xs -> y : ys -> (x,y) : zip xs ys >> _ -> _ -> [] This deviates from the current syntax of multi-argument lambda, and introduces overloading on ->. Perhaps -> could be reserved for "match and lift", and whitespace could separate several alternatives: zip = \ (x:xs) (y:ys) -> (x,y) : zip xs ys _ _ -> [] There is some tension in the current between argument lists which allow several arguments and require parentheses around constructor applications to delimit patterns, and case expression which match only one item, but without grouping. If we are trying to unify things, perhaps case could be extended to support matching several values together, perhaps separating expressions with commas in the head and using the syntax of a lambda for the cases. Perhaps '=' in function declarations vs. "->" for other matching could also be simplified somehow. I don't have any ideas here. >> take' = \ >> 0 -> _ -> [] >> n -> { [] -> [] >> ; x : xs -> x : take (pred n) xs >> } I'm not sure how to handle a case like this. Introducing layout at whitespace seems a bit excessive, but requiring explicit separators looks a bit heavy on punctuation next to the current grammar, where only records (and perhaps Maybe the '\' could be reiterated to introduce the layout group: take' = \ 0 _ -> [] n \[] -> [] (x:x) -> x : take (pred n) xs > > Pattern guards now can be seen as a special case of > alternatives-level argument application > (``argument supply'' $\righttriangle$ in PMC). > I find it useful to write the argument first, as in PMC. > > I see two options of writing argument supply in Haskell: > either using new keywords, giving rise to the syntax production > > alt -> match exp with alts Maybe reuse "case", unless a new keyword is needed to avoid confusion. > or using a keyword infix operator: > > alt -> exp |> alts > > (Using this kind of argument supply instead of pattern guards > also has the advantage that multiple alternatives become possible.) I'm not using -> to separate patterns, but some leading symbol is required to separate the last pattern from the expression. I like '|' from the current syntax, selected with hopes of incorporating and extending the current guard syntax. I'm pretty sure incorporating the existing guard syntax will require that the grammar keep track whether the last "bit" of the matching was a pattern or a guard (just like currently | switches from patterns separated by whitespace to a list of guards separated by commas). Pattern guards can be translated to matching plus argument supply, so argument supply needs to be part of the primitive matching syntax. I like the suggestion alt | exp |> alts It would be unambiguous but require unbounded lookahead to allow a case to begin with argument supply: foo :: [Int] -> [Int] foo = \lookup env v |> (Just r) [] -> [r] Given argument supply, we can sugar in the existing guard syntax by allowing alt | guard, guards, exp |> alts and alt | guards -> expr The sequence "->\" will transition from guards back to matching more arguments. It might be nice to abbreviate that to '\'. Guards can be eliminated with the translations alt | exp, guards ... ==> alt | exp |> True |guards alt | exp -> expr ==> alt | exp |> True -> expr alt | pat <- exp, guards ==> alt | exp |> {pat | guards ... } alt | pat <- exp -> expr ==> alt | exp |> pat -> expr > > I start with Simon Peyton Jones' standard example: > >> clunky env v1 v2 | Just r1 <- lookup env v1 >> , Just r2 <- lookup env v2 = r1 + r2 >> | otherwise = v1 + v2 I'd like to accepts this unchanged. I think the treatment of guards above will work. > This could now be written using either ``match _ with _'': > >> clunky env v1 v2 = \ >> match lookup env v1 with >> Just r1 -> match lookup env v2 with >> Just r2 -> r1 + r2 >> v1 + v2 > > or infix ``_ |> _'': > >> clunky env v1 v2 = \ >> lookup env v1 |> Just r1 -> >> lookup env v2 |> Just r2 -> r1 + r2 >> v1 + v2 Because I'm using space to separate patterns, I would require parentheses (or the pat <- exp sugar) clunky env v1 v2 | lookup env v1 |> (Just r1) , lookup env v2 |> (Just r2) -> r1 + r2 > Boolean guards are matches against True: >> take = \ >> 0 -> _ -> [] >> n -> match n > 0 with >> True -> >> { [] -> [] >> ; x : xs -> x : take (pred n) xs >> } >> _ -> error "take: negative argument" take = \ 0 _ -> [] n | n > 0 \[] -> [] (x:xs) -> x : take (pred n) ns This syntax has a pretty nice pronunciation, reading | as "such that", a comma as an "and" (between guards), and both space between patterns or '\' after a guard as "and" or "and then" (either way, introducing a pattern for another argument). This PMC stuff seems like a description/semantics for pattern matching. Hopefully my attempts at backwards-compatible syntax help people give the semantics a deeper look. Brandon

1 0

How would you replace a field in a CSV file?
by tpledger＠ihug.co.nz 02 Oct '06

02 Oct '06

Hi Pete. For such a small self-contained task, I don't think Haskell is any better than Python. Haskell would come into its own if you wanted some assurance about type safety, and/or were taking on a task large enough to warrant the use of records (and hence record update notation). Regards, Tom

3 2

[Offtopic] Re: Re: A better syntax for qualified operators?
by Cale Gibbard 01 Oct '06

01 Oct '06

> "What a beautiful world this could be..." ;-)) (*) > > Cheers, > Ben > (*) Donald Fagen (forgot the name of the song) I think I.G.Y. (International Geophysical Year) is it: On that train all graphite and glitter Undersea by rail Ninety minutes from New York to Paris (More leisure time for artists everywhere) A just machine to make big decisions Programmed by fellows with compassion and vision We'll be clean when their work is done We'll be eternally free yes and eternally young What a beautiful world this will be What a glorious time to be free

2 1

irrefutable patterns for existential types / GADTs
by apfelmus＠quantentunnel.de 01 Oct '06

01 Oct '06

Ross Paterson wrote: > The story so far: > apfelmus: why are there no irrefutable patterns for GADTs? > Conor: because you could use them to write unsafeCoerce > Ross: how about irrefutable patterns (or newtypes) for existential types? > Simon: Try giving the translation into System F + (existential) data types I'd like to add that I see no problem with coerce :: Eq a b -> a -> b coerce ~Refl x = x as long as we have coerce _|_ x === _|_ The wish is that f = \refl -> Just . coerce refl = \~Refl x -> Just x should satisfy f _|_ x === Just _|_ f _|_ x =/= _|_ and likewise for any other constructor than Just. Regards, apfelmus

3 5

Re: Why is type 'b' forced to be type 'm a' and not possibly 'm a -> m a'
by tpledger＠ihug.co.nz 01 Oct '06

01 Oct '06

Vivian McPhail wrote: ... > I need the arg a to be evaluated before it gets > passed to a1 and a2. This definition does the right thing > when type 'a' is a function type, because it is not a > value, but with something like 'm a -> (m a -> m a) -> m > a' with Forkable (a -> b) the first arg gets evaluated > twice, to be more concrete: > > With > > (and golden white) eggs > > I want the 'eggs' that is passed to 'golden' to be the > same as the 'eggs' that is passed to 'white', i.e. ... Could you reduce the need for Forkable instances, by rewriting '(and golden white) eggs' as 'and golden white =<< eggs'? Or would the same piece of code also have to handle combinations such as monadic 'and golden white' and non-monadic eggs? [BTW, thanks for giving me a pretext to use the phrase non-monadic eggs!] > Tom suggested that I might be able to use the Reader monad > , but I'm not clear as to how I could do this. Please ignore that. I only mentioned it in case the sole purpose of fork was to propagate a String, which you've now explained is not so. Regards, Tom

1 0

Greetings...
by tpledger＠ihug.co.nz 01 Oct '06

01 Oct '06

Seth Gordon wrote: > I thought I should check and see if anyone > on this list has used Haskell to munge a > ten-million-row database table, and if > there are any particular gotchas I should > watch out for. Are you sure you want to target the data directly? Another approach, that might have a better chance of a quick win within your time frame, is to use Haskell to generate SQL code. That could still reduce the amount of code you maintain by hand. Regards, Tom

1 0

Re: Greetings
by Paul Johnson 01 Oct '06

01 Oct '06

I've done some stuff with maybe 50k rows at a time. A few bits and pieces: 1: I've used HSQL (http://sourceforge.net/project/showfiles.php?group_id=65248) to talk to ODBC databases. Works fine, but possibly a bit slowly. I'm not sure where the delay is: it might just be the network I was running it over. One gotcha: the field function takes a field name, but its not random access. Access the fields in query order or it crashes. 2: For large data sets laziness is your friend. When reading files "getContents" presents an entire file as a list, but its really evaluated lazily. This is implemented using unsafeInterleaveIO. I've never used this, but in theory you should be able to set up a query that returns the entire database as a list and then step through it using lazy evaluation in the same way. 3: You don't say whether these algorithms are just row-by-row algorithms or whether there is something more sophisticated going on. Either way, try to make things into lists and then apply map, fold and filter operations. Its much more declarative and high level when you do it that way. Let us know how you get on. Paul.

3 2

Greetings...
by Seth Gordon 01 Oct '06

01 Oct '06

I've finally gotten enough round tuits to learn Haskell, and now that I've done some of the exercises from _The Haskell School of Expression_ and I finally (think I) understand what a monad is, the language is making a lot more sense to me (although my code is not always making so much sense to the compiler :-). My employer (MetaCarta) makes a search engine that can recognize geographic data. My group within MetaCarta is responsible for building the "Geographic Data Module" within our software. To do this, we slurp a heap of geographic and linguistic data from a variety of sources, normalize it, and then use some algorithms (that I'm not allowed to describe) to generate the module. This seems like the sort of task that cries out for a functional-programming approach, and that's what we use, sorta: a lot of the code that I'm responsible for is SQL, with chains of "CREATE TEMP TABLE X AS [insert very complicated query here]", some C++ for the parts that would be very time-consuming or impossible to implement in SQL, and shell scripts to tie everything together. I told my tech lead that I want to try porting some of this code to Haskell in the hope that it would run faster and/or be easier to read. He said I should spend two work days on the project and then be prepared to convince my co-workers that further research in this vein is (or is not) worth doing. So before I embark on day 1 of the project, I thought I should check and see if anyone on this list has used Haskell to munge a ten-million-row database table, and if there are any particular gotchas I should watch out for. adTHANKSvance....

3 3

Re: [Haskell-cafe] smallest double eps
by Chad Scherrer 01 Oct '06

01 Oct '06

Tamas, You might want to read Joachim's post more carefully - he's trying to help you, and I think he makes a good point. -Chad > > Am Freitag, den 29.09.2006, 19:30 -0400 schrieb Tamas K Papp: > > > the smallest positive floating point number x such that 1+x /= x? > > That would be the smallest positive number, woudn't it? > > > > Do you mean the smalles postive number x with 1+x /= 1? > > Hi Joachim, > > Specifically, I would be happy with the smallest Double that makes the > statement true. I need it as a convergence bound for an iterative > algorithm. Anyhow, thanks for the clarification, but I would be > happier with an answer. > > Tamas > > > ------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > End of Haskell-Cafe Digest, Vol 37, Issue 92 > ******************************************** > -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

8 9

cutting long strings into lines
by Andrea Rossato 30 Sep '06

30 Sep '06

Hello! I've been trying for quite some time to find an elegant solution to cut long strings into lines, but the only solution I was able to come up is the following piece of ugly code. Is there a library function for that? What kind of approach would you suggest? Thanks for your kind attention. Andrea Here's the code: -- does the actual job wrapString str = foldr addNL "" $ rmFirstSpace $ concat $ splitS (getIndx $ indx str) str -- gets the indexes of the spaces within a string indx = findIndices (\x -> if x == ' ' then True else False) -- gets the indexes of where to split the string into lines: lines -- must be between 60 and 75 char long getIndx :: [Int] -> [Int] getIndx = takeFirst . checkBound . (delete 0) . nub . map (\x -> if x > 60 && x `rem` 60 >= 0 && x `rem` 70 <= 10 then x else 0) -- groups indexes when their distance is too short checkBound = groupBy (\x y -> if y - x < 10 then True else False) -- takes the first index of a group of indexes takeFirst = map (\(x:xs) -> x) -- split a string given a list of indexes splitS _ [] = [] splitS (x:xs) (ls) = [take x ls] : splitS (map (\i -> i - x) xs) (drop x ls) splitS _ ls = [ls]:[] -- remove the first space from the begging of a string in a list of strings rmFirstSpace = map (\(x:xs) -> if x == ' ' then xs else x:xs) -- used by foldr to fold the list of substrings addNL s s1 = s ++ "\n" ++ s1 try with putStrLn $ wrapString longString where: longString = "The Haskell XML Toolbox (HXT) is a collection of tools for processing XML with Haskell. The core component of the Haskell XML Toolbox is a domain specific language, consisting of a set of combinators, for processing XML trees in a simple and elegant way. The combinator library is based on the concept of arrows. The main component is a validating and namespace aware XML-Parser that supports almost fully the XML 1.0 Standard. Extensions are a validator for RelaxNG and an XPath evaluator."

7 11