- Haskell-prime - Haskell.org

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 07 Dec '06

07 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

Re[2]: base libraries
by Bulat Ziganshin 26 Nov '06

26 Nov '06

Hello Malcolm, Friday, November 24, 2006, 8:26:11 PM, you wrote: >> i think that we should require H' compatibility instead of H98 one, so >> require to not use fundeps, but allow MPTC. this means that NHC should >> be ruled out as non-H' compliant compiler instead of these libs > Why pick on nhc98? Today, there are absolutely _no_ haskell-prime > compliant implementations, because there is no haskell-prime standard > yet. As and when the standard is fixed, implementations will catch up. that was started as internal GHC initiative, now seems to also have support from you and Ross Paterson and that's great. i hope we can consider this as initiative to define modern set of standard libraries which should be available with any modern Haskell compiler. because nowadays Haskell-prime standard also developed i hope that these two initiatives will come together, probably we can develop libraries part of this standard (or, to be exact, describe current state of widely used libs as Library Report part of this standard) the next question to consider is that a "modern" compiler? may be it's only ghc? or ghc/hugs which has a lot of common extensions? or ghc/hugs/nhc which is declared as supporting Base lib? or maybe all 5 compilers whose authors present here? in the light of forthcoming Haskell' standard, i propose to consider compatibility with H' as a mark that library may be standardized. it is especially important if we want to continue live of this proposal in the H' world instead of reinventing the wheel again yes, this means that some "standard" libraries will be available only for hugs/ghc now, but we have the same situation even for parts of Base library (Data.Array.*, at least) >> but when other problems >> arrives, this may be a stop-mark, because these problems will not be >> fixed in future NHC versions > Who says? nhc98 is not dead. Yhc is a very active project, and it is > basically just a re-branding of nhc98. i tried to say that problems which probably will be not fixed in future nhc versions, should be a stop-mark for inclusion library in standard set so, my proposal now is to require that libraries going to Core should obey H' standard in its current proposed form and for non-language features (if such exists) it should be compatible with ghc/hugs/nhc (i hope that yhc is compatible with nhc in this aspect) this will allow, when H' arrives and nhc will be updated to support this standard, to have standard libraries readily available on these 3 or 4 platforms of course, it's rather speculative to test on compatibility with non yet fixed standard. on the other hand, such tests may influence the standard itself, requiring inclusion of some language features that is required for some great lib (like mine ;) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Pattern guards and where clauses
by Ravi Nanavati 21 Nov '06

21 Nov '06

While playing with some pattern guard code, I discovered some scoping behavior that I wasn't expecting. I learned that pattern guard bindings aren't visible in their equation's where clauses. To make this concrete, in the following (contrived) example, "test1" works, but "test2" complains that 'v' is unbound: data Bar = Baz Int | Biz Int | Empty toInt (Baz i) = Just i toInt (Biz i) = Just (2 * i) toInt Empty = Nothing test1 :: Bar -> Int test1 b | Just v <- toInt b = v + 1 test1 _ = 0 test2 :: Bar -> Int test2 b | Just v <- toInt b = k where k = v + 1 test2 _ = 0 From an implementation perspective, I understand the behavior as an artifact of desugaring pattern guards into a case expression. But, as a user, it seems like an odd restriction on how I organize my code (since I often prefer to separate out tricky bits of logic into nearby where clauses without disturbing the main flow of the right-hand side). Moreover, unless I'm missing something, a slight tweak to the desugaring (by adding irrefutable patterns corresponding to the pattern guard bindings) could easily recover the behavior I expected. I'm thinking something like this (which could be tweaked to remove the repeated expression, of course): test2' :: Bar -> Int test2' b | Just v <- toInt b = k where Just v = toInt b k = v + 1 Anyway, what do other people think? Do people besides me find it pleasing to have pattern guard bindings visible in where clauses? Or are people more worried about the failures that would happen if you used a binding from a pattern guard that ended up false? - Ravi

3 3

proposal: introduce lambda-match (explicit match failure and fall-through)
by Claus Reinke 21 Nov '06

21 Nov '06

name: introduce lambda-match (explicit match failure and fall-through) summary: Haskell 98 provides *two different translations* of lambda abstractions involving pattern matching, only one of which is directly accessible (Section 3.3 - the other is embedded in the translation of do-notation, see "ok" in Section 3.14). providing explicit source notation for the second translation, substantially simplifies programmability of pattern-match fall-through by reification of pattern-match failure, two central language features that are so far only available through the built-in, non-composable case construct. what: in Section 3.3, the translation for conventional lambda abstractions with patterns is given as [| \p1 .. pn-> e |] = \x1 .. xn-> case (x1,..,xn) of (p1,..,pn) -> e with xi fresh identifiers, and pattern-match failure resulting in _|_. the latter is unfortunate, and results in partial functions the coverage of which cannot be combined, but it is forced by translation into conventional lambda calculus. since computational lambda calculus (\-M) has become a central part of Haskell programming practice, there shall be an alternative form of lambda abstraction, dubbed here lambda-match, with associated translation into \-M: [| |p1 .. pn-> e |] = \x1 .. xn-> case (x1,..,xn) of { (p1,..,pn) -> return e; _ -> fail "no match" } [note1: this is the translation in principle - in practice, to enable composition of lambda-matches without further language extensions, a slight modification is needed, wrapping the right-hand sides of the case in a Match constructor, see library and patch] a library for composing these lambda-matches shall provide for composition of alternative lambda-matches (+++), match failure (nomatch) and embedding of the explicit match monad into pure expressions (splice, where "splice |p1..pn->e = \p1..pn->e"). [note2: an alternative translation would use do-notation instead of case as the target: [| |p1 .. pn-> e |] = \x1 .. xn-> do { (p1,..,pn) <- return (x1,..,xn); return e } both translations easily accomodate guards and pattern guards as well, the former by building on existing support for these two features in case constructs, the latter without requiring any previous implementation of pattern guards, by lifting (pattern) guards into the match monad] implementation impact: minimal - limited to an extension in parser/desugarer, employing previously inaccessible syntax for lambda-match, and a slight variation of the existing lambda translation; also adds a small library to support composition of matches. [note3: a first draft of the composition library and a patch for GHC (about a dozen new lines in the parser) are provided as attachments to this proposal, together with some examples] context: as has been pointed out in the thread on replacing and improving pattern guards, Haskell's pattern matching support, even before pattern guards, is monolithic (built-in case is the only way to handle multiple alternative matches) rather than compositional (lambdas represent individual alternatives, but cannot be composed on match fall-through). this implies increased complexity of the language definition and limited expressiveness of its features, when compared with alternative models (eg, adapting Wolfram's pattern match calculus for Haskell). see, eg.: http://www.haskell.org/pipermail/haskell-prime/2006-October/001713.html http://www.haskell.org/pipermail/haskell-prime/2006-October/001720.html http://www.haskell.org/pipermail/haskell-prime/2006-October/001723.html http://www.haskell.org/pipermail/haskell-prime/2006-October/001724.html in principle, replacing Haskell's current pattern matching support with a simpler, more compositional model, and defining the current constructs on top of that new core is the way forward, IMHO. in practice, however, I suspect that the committee is less than tempted to introduce such a substantial simplification for Haskell'. the present proposal is an attempt at a compromise, suggesting a minimal language change to introduce compositional pattern-match failure and fall-through. with lambda-match, it implements only a single language extension (as syntactic sugar), delegating the rest of the functionality to a library. without the sugar, the result of the by-hand translation becomes so hard to read as to be near unusable, while the chosen form of sugaring allows to provide most of the language features discussed in the earlier threads to be provided as a library. this does seem to be a useable balance. building constructs of the simpler pattern-match model on top of the more complex one is somewhat irksome from a language design perspective, but does at least gain the expressiveness of the simpler model. if programmers make substantial use of this new functionality in Haskell' (as I strongly suspect they will - I have been doing similar translations by hand for some time now), it will be up to Haskell'' to turn the table, and to define the current complex model on top of a compositional one. as a preview of this anticipated language refactoring;), it is instructive to compare the two alternative translations of lambda-match sketched above: - the first directly builds on the existing, complex case constructs with their built-in (pattern) guards and match fall-through support; this eases adding the new, simpler features to implementations that support the old, complex ones (like GHC), but completely foregoes any attempt to simplify those implementations in the process; [the attached patch for GHC follows this route] - the second translation avoids any direct reference to case, employing do-notation instead; this requires slightly more effort, eg. in translating pattern guards into the match monad, but is eminently suitable for adding the new features to implementations that do not support pattern guards yet, or that simply want to reduce the number of built-in constructs. [patchers for Hugs, etc., might want to follow this route?]

2 4

Re: [Haskell-cafe] Fractional/negative fixity?
by Bulat Ziganshin 15 Nov '06

15 Nov '06

Hello Dan, Saturday, November 4, 2006, 5:07:15 AM, you wrote: > Here's an idea that (I think) is useful and backwards compatible: > fractional and negative fixity. yes, i think the same. for example, once i've tried to define postfix 'when' operator like those in perl/ruby print msg `on` mode==debug but failed because my code frequently contains '$' and there is no way to define operation with a lower precedence really, there is another alternative to solve my particular problem: make `op` applications having fixed -1 precedence. such applications look "heavyweight" and once i have a wonderful debugging story just because for my eyes it was obvious that (a `div` b+1) means "do add before div" -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

12 19