December 2006 - Haskell-prime

defaults
by Malcolm Wallace 16 Jan '07

16 Jan '07

Prompted by recent discussion on the Hat mailing list about the problems of type-defaulting, I have added two new proposals for this issue to the Haskell-prime wiki at: http://hackage.haskell.org/trac/haskell-prime/wiki/Defaulting The main new proposal is a different way of specifying defaults, which includes the name of the class being defaulted (thus allowing user-defined classes to play this game), but unlike the original proposal, permits only one type to be specified per class. The rules are therefore also simpler, whilst still (I believe) capturing the useful cases. A secondary proposal is to generalise defaults from having module-local scope, to global scope. This would allow library authors to capture the intended behaviour of their own classes and types, without bothering the library users. (Also, whilst removing module-local redefinition of defaults, the proposal would instead permit function-local re-definition.) I am less convinced of the need for this proposal, but in the spirit of exploring the design space, I thought it worth bringing up. Regards, Malcolm

15 30

New Layout Rule
by John Meacham 20 Dec '06

20 Dec '06

Motivated by some recent discussion, I thought I would explore the possibilty of formalizing the haskell layout rule without the dreaded parse-error clause, as in, one that can be completly handled by the lexer. motivated by that I have written a little program that takes a haskell file with layout on stdin and spits out one without layout on stdout. it can be gotten here: darcs get http://repetae.net/repos/getlaid/ the code is designed to make the layout algorithm completly transparent, so that we might experiment with it. The function layout in 'Layout.hs' is the single and complete layout algorithm and the only thing that need be modified by experimentors. I have come up with a simple improvement to the algorithm given in the paper that seems to catch a very large number of layouts. basically, whenever it comes across something that must come in matched pairs (, ), case of, if then. it pushes a special context onto the stack, when it comes across the closing token, it pops every layout context down to the special context. there is a special case for "in" that causes it to pop only up to the last context created with a "let", but not further. here is the complete algorithm (with my modification, sans the parse-error rule): > data Token = Token String | TokenVLCurly String !Int | TokenNL !Int deriving(Show) > > data Context = NoLayout | Layout String !Int > > -- the string on 'Layout' and 'TokenVLCurly' is the token that > -- created the layout, always one of "where", "let", "do", or "of" > > layout :: [Token] -> [Context] -> [Token] > layout (TokenNL n:rs) (Layout h n':ls) > | n == n' = semi:layout rs (Layout h n':ls) > | n > n' = layout rs (Layout h n':ls) > | n < n' = rbrace:layout (TokenNL n:rs) ls > layout (TokenNL _:rs) ls = layout rs ls > layout (TokenVLCurly h n:rs) (Layout h' n':ls) > | n >= n' = lbrace:layout rs (Layout h n:Layout h' n':ls) > | otherwise = error "inner layout can't be shorter than outer one" > layout (TokenVLCurly h n:rs) ls = lbrace:layout rs (Layout h n:ls) > layout (t@(Token s):rs) ls | s `elem` fsts layoutBrackets = t:layout rs (NoLayout:ls) > layout (t@(Token s):rs) ls | s `elem` snds layoutBrackets = case ls of > Layout _ _:ls -> rbrace:layout (t:rs) ls > NoLayout:ls -> t:layout rs ls > [] -> error $ "unexpected " ++ show s > layout (t@(Token "in"):rs) ls = case ls of > Layout "let" n:ls -> rbrace:t:layout rs ls > Layout _ _:ls -> rbrace:layout (t:rs) ls > ls -> t:layout rs ls > layout (t:rs) ls = t:layout rs ls > layout [] (Layout _ n:ls) = rbrace:layout [] ls > layout [] [] = [] > > layoutBrackets = [ ("case","of"), ("if","then"), > ("(",")"), ("[","]"), ("{","}") ] now. there are a few cases it doesn't catch. the hanging case at the end of a guard for instance, I believe this can be solved easily by treating '|' and '=' as opening and closing pairs in lets and wheres '|' and '->' as opening and closing pairs in case bodies. it is easy to see which one you are in by looking at the context stack. commas are trickier and are the only other case I think we need to consider. I welcome people to experiment and send patches or brainstorm ideas, I have what I believe is a full solution percolating in my head, but am unhappy with it, I am going to sleep on it and see if it crystalizes by morning. In the meantime, perhaps someone can come up with something more elegant for dealing with the remaining cases. or at least find some real programs that this code breaks down on! (bug fixes for the lexer and everything are very much welcome. it will probably choke on some ghc extensions that would be trivial to add to the alex grammar) John -- John Meacham - ⑆repetae.net⑆john⑈

3 4

Are pattern guards obsolete?
by mm 17 Dec '06

17 Dec '06

Hello, recently I read about pattern guards which are a candidate for Haskell'. As I understand them, their purpose is to provide an easier way to write functions like (taken from the wiki, it does not run): clunky env var1 var1 = case lookup env var1 of Nothing -> fail Just val1 -> case lookup env var2 of Nothing -> fail Just val2 -> val1 + val2 where fail = var1 + var2 Wouldn't > clunky :: Num a => [(a, a)] -> a -> a -> a > clunky env var1 var2 = case (lookup var1 env, lookup var2 env) of > (Just v1, Just v2) -> v1 + v2 > _ -> var1 + var2 be simple enough to make a syntax change superflous? It is so simple, that there is no need for `fail` in Haskell or Haskell' :) schneegloeckchen

10 21

Type sections
by Twan van Laarhoven 11 Dec '06

11 Dec '06

Since operators are allowed in type and class names, I think it would make sense if the section notation was also allowed. In particular the Reader monad would be a little bit nicer: > instance Monad (e ->) where ... And maybe type level programming can benefit as well. Twan

3 2

infix MPTC?
by David Roundy 06 Dec '06

06 Dec '06

I was just thinking today. Is there any reason we couldn't have infix multiparameter typeclasses? For typeclasses standing as witnesses of relationships it'd be much clearer, for example to have something like (a :<: b) rather than the always-vague (LT a b) which either reads the same as the infix version or backwards. This isn't so much a proposal as a query regarding reasonableness. I certainly wouldn't like to have precedence rules for type classes, but perhaps if you simply always required parentheses it'd be more readable than always requiring prefix notation, and yet still not too insane to parse? -- David Roundy Department of Physics Oregon State University

2 2

character literal question
by Iavor Diatchki 02 Dec '06

02 Dec '06

Hello, Is there a reason why we have to escape the character ' (apostrophe) when used in a character literal? For example, we have to write '\'' instead of '''. (With syntax highlighting, the second is a lot better looking than the first.) It seems that in this case we do not need the escape because a literal contains exactly one character. If there is no good reason for having the scape, I think that we should remove this restriction in Haskell'. -Iavor

4 4

Standard (core) libraries initiative: rationale
by Bulat Ziganshin 02 Dec '06

02 Dec '06

Hello libraries, like "computer is a net", nowadays language is a library. there is nothing exceptional in C++ and Java languages except for their huge library codebase that makes them so widely appreciated while it's impossible for Haskell to have the same level of libraries maturity, we can try to do our best. Libraries was considered so important, that in H98 report libs required more pages than language itself. But, really, all libraries described there together is appropriate only for learning and small programs - to do real work, we need even much, much more fortunately, now we have large enough set of libs. moreover, this set grows each year. but these libs don't have official/recommended status. now we have two languages - H98 as reported with its bare libs, which is appropriate only for teaching, and real Haskell language with many extensions and rich set of libs, used to develop real programs with a language itself, now we go to standardize current practice and include into language definition all popular extensions. this will close the gap between standard and practice. Haskell' committee also plan to define new version of standard Haskell library. but what a library can be defined in this way? slightly extended version of standard Haskell98 lib? or, if it will be significantly extended - how much time this work will require and isn't that a duplication of work done at libraries list? i propose not to try to define reality, but accept existing one and join committee's work on new library definition with a current discussion of core libraries, which should define a set of libs available on any Haskell compiler on any platform - aren't goals the same? instead of providing rather small and meaningless standard Haskell library, now we can just include in Report docs existing and widely used libs, such as Network, mtl and so on. This will mean that language, defined in Haskell standard, can be used to write real programs, which will be guaranteed to run in any Haskell environment. of course, this mind game can't change anything in one moment. but it will change *accents* first, Haskell with its libraries will become language for a real work. such extended language isn't small nor easy to master in full, but it is normal for any mature programming environment. people learning Haskell should select in which area they need to specialize - be it gaming or web service development, and study appropriate subset of libs. people teaching Haskell now can show how *standard* Haskell may be used to solve real world problems, and this should change treatment of Haskell as academic language. also, we may expect that books teaching Haskell will start to teach on using standard libs, while their authors now don't consider teaching for non-standard libs second, by declaring these libs as standard ones we create sort of lingua franca, common language spoken by all Haskell users. for example, now there are about 10 serialization libs. by declaring one of them as standard, we will make choice simpler for most of users (who don't need very specific features) and allow them to speak in common language. in other words, number of Haskell libs is so large now that we should define some core subset in order to escape syndrome of Babel tower. defining core libraries set is just sharing knowledge that some libraries are more portable, easier to use, faster and so on, so they become more popular than alternatives in this area third. now we have Cabal that automates installation of any lib. next year we will got Hackage that automates downloading and checking dependencies. but these tools still can't replace a rich set of standard libs shipped with compiler. there are still many places and social situations where Internet downloading isn't available. Compiler can be sold on CD, transferred on USB stick. and separate Haskell libs probably will be not included here. Standard libraries bundled with compiler will ensure that at least this set of libs will be available for any haskell installation. Internet access shouldn't be a precondition for Haskell usage! :) fourth. now there is tendency to write ghc-specific libs. by defining requirements to the standard libs we may facilitate development of more portable, well documented and quick-checked ones. or may be some good enough libraries will be passed to society which will "polish" them in order to include in the set. anyway, i hope that *extensible* set of standard libraries with a published requirements to such libs would facilitate "polishing" of all Haskell libs just because ;) and this leads us to other question - whether this set and API of each library should be fixed in language standard or it can evolve during the time?... -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

5 4