November 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

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 20 Nov '06

20 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

String literals
by Lennart Augustsson 14 Nov '06

14 Nov '06

I think it's time that string literals got overloaded just like numeric literals. There are several reasons for this. One reason is the new fast string libraries. They are great, but string literals don't work; you need to pack them first. Another reason is the increasing use of Haskell for DSELs. In a DSEL you might want string literals to have a different type than the ordinary String. I have not implemented anything yet, but I would like to see something along the lines of the following: class IsString s where fromString :: String -> s instance IsString String where fromString = id The instance declaration is not allowed in Haskell-98, but it can be rewritten as class IsChar c where -- Make this class local to it's defining module fromChar :: Char -> c instance IsChar Char where fromChar = id instance (IsChar c) => IsString [c] where fromString = map fromChar And, like with numeric literals, any string literal will then have an implicit fromString insert to make the right conversion. My guess is that the defaulting mechanism needs to be extended to default to the String type as well, or we'll get some ambiguous expressions. Any thoughts? -- Lennart

8 15

String literals
by Rohan Drape 13 Nov '06

13 Nov '06

On Mon Nov 13 12:27:08 EST 2006, Simon Peyton-Jones wrote: > In my experience I've seen more requests for overloaded *Boolean* > literals than strings. In a Fran context, for example. Has there been discussion of the related issue, described in a Pan paper as 'Unfortunately, the Bool type is wired into the signatures of operations like >= and ||.'? (I searched the trac but couldn't find it?) It seems common to have to write something like: class OrdE a where (>*) :: a -> a -> a etc. While for finite signals both have meaning, ie. [1,2,3] > [1,2,1] == True [1,2,3] >* [1,2,1] == [False,False,True] for infinite signals '>' is often a nonsense, and if these are the primary type it'd be nice to write '>' for '>*'. Regards, Rohan

1 1

Annotation system for Haskell
by Bulat Ziganshin 13 Nov '06

13 Nov '06

Both Java and C# provides annotations that can be used to pass some additional information about code to around-language tools and queried at program runtime via Reflection API: [AuthorAttribute ("Ben Albahari")] class A { [Localizable(true)] public String Text { get {return text; } ... } } in the last poll for Haskell', it was widely noted that some form of attribute (annotation) system for Haskell will be great, although there is no any design yet. i think that i've found rather good one: 1. Attributes must be available at run-time via some library that uses RTS-provided information, at compile-time for TemplateHaskell-like language extensions using appropriate APIs, and for 3rd-party tools like DrIFT using database generated by compiler during compilation process 2. Attributes are linked to _entities_, which includes packages, modules, values, types, classes and instances. Entity can be found by specifying its _path_, say "package Foo -> module M -> class Eq -> value (==)". Of course this path on practice may be written just as "Foo:M:Eq:(==)". Because almost any module imports class Eq from Prelude, we can find the very same entity by a number of various paths, including "Base:Data.List:Eq:(==)" and "stm:Control.Concurrent.STM:Eq:(==)". If module A imports module B qualified, then path may look as "Foo:A:B.f". Of course, we will also need some way to get "current" package/module name 3. It should be also possible to _enumerate_ all sub-entities of given entity or all attributes of entity. I think that we should provide both ability to enumerate all entities _available_ inside module and to enumerate all entities _defined_ in the module 4. Each entity has a list of named attributes. We should provide a way to define new attribute name together with its "sort". Using Haskell type to define this "sort" looks like a natural solution: [Declare Author :: String] [Declare Deriving :: [String]] [Author "Bulat"] data T = X | Y [^Deriving ["Eq","Ord"]] 5. Then, using a path to entity and attribute's name, one can easily get attribute value: getAttr "Foo:M:T" "Author". Simplest solution is just to return String representation of attribute value, leaving to programmer the job of using "read" to convert this String value into right type I don't consider this in deeper details, but some form of dynamic typing (Typeable/Data class) can also be used. Ideal solution will be to allow programmer to define his own datatypes of attributes which then may be used _both_ instead of [Declare] statements above and as result type for getAttr function, say: data MyAttrs = Author String | Deriving [String] deriving (Attribute) [Author "Bulat"] data T = X | Y [^Deriving ["Eq","Ord"]] use_reflection_api = case getAttr (CurrentPackage ++ ":" ++ CurrentModule ++ ":T") "Author" of Author str -> str In this scenario, standard (predefined) attributes may be just imported as part of Prelude, and user-defined attributes may be defined in current or imported module But while this way greatly simplifies and makes almost type-safe the most common case - using of well-known attributes, it should also be possible to keep 2 features: 1) ability to declare new attribute types inside a module and use these new attributes immediately inside the same module 2) ability to enumerate and get values of attributes of unknown types. imagine, for example, attribute browsing tool 6. Returning to compiler/3rd-party tools interaction, we can now say that attributes database for each module should be build during compilation of this module. It is something very like .hi file, one per each module compiled, but for external consumption. It looks natural to use XML format here, so the entity path will be translated into the path of appropriate xml file and xml path inside the file. Information in this file don't limited to the attributes provided by module writers, it can also contains any information compiler may provide (types of values, code metrics, options used when compiling module) and 3rd-party tools can also add their own information here it seems that also some indexing/xml merging tools should arise at some moment to speed up access to this database, especially to databases of installed packages -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 1

RE: Re: [Haskell-cafe] Fractional/negative fixity?
by Simon Marlow 09 Nov '06

09 Nov '06

Nicolas Frisby wrote: > Let's remember that if something is broke, it's only _right_ to _fix_ > it. I patiently waited for someone else to make that pun. > > Understanding the language won't be much harder, but understanding > fixity declarations will become a task. Consider: > > infixl -1.7521 -- what and why? > > As the operator space becomes more dense, negative and fractional > fixities are going to become more obfuscated. The negative and > fractional fixities will satisfy a number purposes well, but they will > also be abused and lead to confusion. > > This smells like a wart growing on a wart to me. All these are valid points. However, given that we can't completely redesign, implement and test a new fixity system in time for Haskell', it makes sense to make a simple change that unambiguously improves the current system, and is no more difficult to implement (in fact, I bet it adds zero lines of code to the compiler). Cheers, Simon > Nick > > On 11/7/06, David House <dmhouse(a)gmail.com> wrote: >> On 07/11/06, Jon Fairbairn <jon.fairbairn(a)cl.cam.ac.uk> wrote: >>> I must say though, that I don't like the reasoning that we >>> can put in fractional fixities because it's a small >>> change. The way to hell is through a series of small >>> steps. If using integers to express fixities is a bit of a >>> hack, switching to rational numbers is a hack on top of a >>> hack. >> >> Well, It's a _conceptually_ simple idea, one that doesn't make >> understanding the language much harder. >> >> Also, it provides an infinite space for fixities. I think the problem >> 'binds tighter than X but not as tight as Y', where X and Y are only >> fixity integer apart is somewhat common, and this would fix it. It >> would allow for extensibility into the future, where the operator >> space will only become more dense, and maintaining a complete order >> with only 10 integers to play will become more and more difficult. >> Allowing an infinite amount of operators to come between any two >> operators sounds like a solid design decision to me. >> >> -- >> -David House, dmhouse(a)gmail.com >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe

3 2