- Haskell-Cafe - Haskell.org

question about "singletons"
by TP 02 Jun '13

02 Jun '13

Hi all, Following a discussion on Haskell Cafe some time ago (1), Roman C. wrote: """ On the other hand, the type 'Succ 'Zero has kind 'Nat and doesn't have any inhabitants — only types of kind * do. """ Indeed, this is what seems to occur in the following example: ----------------------- {-# LANGUAGE DataKinds #-} data Nat = Zero | Succ Nat deriving ( Show, Eq, Ord ) main = do let one = undefined :: 'Succ 'Zero print one ----------------------- We obtain an error (ghc 7.6.2): ----------------------- Kind mis-match Expected kind `OpenKind', but `Succ Zero' has kind `Nat' In an expression type signature: Succ Zero In the expression: undefined :: Succ Zero In an equation for `one': one = undefined :: Succ Zero ----------------------- (note that the error is slightly different in the HEAD version of GHC (2)). Is it related to the sentence "As bottom is an inhabitant of every type (though with some caveats concerning types of unboxed kind), bottoms can be used wherever a value of that type would be. " found at address (3)? Here we have a non-* kind, such that bottom would not be an inhabitant of ('Succ 'Zero). Why is this so? This seems to be an assumed choice (4), but I would like to understand the reason for this design, which makes necessary to use singletons, as explained at (4). Now, if I use a singleton to make my example work, I obtain an error when trying to make the type (Sing a) an instance of Show: ----------------------- {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE StandaloneDeriving #-} data Nat = Zero | Succ Nat deriving ( Show, Eq, Ord ) data Sing :: a -> * deriving instance Show (Sing a) main = do let one = undefined :: Sing ('Succ 'Zero) print one ----------------------- The error is simply: ----------------------- test_noinhabitant_corrected.hs: Void showsPrec ----------------------- Why? Thanks, TP References: ---------- (1): https://groups.google.com/forum/?fromgroups#!topic/haskell-cafe/AltmX5iCFi8 (2): ----------------------- Expected a type, but ‛Succ Zero’ has kind ‛Nat’ In an expression type signature: Succ Zero In the expression: undefined :: Succ Zero In an equation for ‛one’: one = undefined :: Succ Zero ----------------------- (3): http://www.haskell.org/haskellwiki/Bottom (4): http://hackage.haskell.org/trac/ghc/wiki/TypeNats/Basics """ Both numeric and symbol literal types are empty---they have no inhabitants. However, they may be used as parameters to other type constructors, which makes them useful. """ """ A singleton type is simply a type that has only one interesting inhabitant. """

2 4

Re: [Haskell-cafe] question about "singletons"
by wren ng thornton 02 Jun '13

02 Jun '13

On 6/1/13 3:18 PM, TP wrote: > In other words, bottom can be an inhabitant of a concrete type, not a type > constructor, which I can understand. But a type of kind Nat is a concrete > type, so why bottom cannot be an inhabitant of this type? The technical term is "proper type". That is, types are used as a way of characterizing collections of values; but, all sorts of things can exist at the type level. For lack of a better name, we call everything at the type level a "type", in order to distinguish them from things at the value level or kind level, etc. But in order to be a *proper* type, a type-level expression must serve to characterize a collection of values. Types of kind * are proper types, because they serve to characterize collections of values. Types of other kinds are not proper, since they do not characterize collections of values. Thus, we can't say: undefined :: (->) nor: undefined :: Maybe because (->) and Maybe are not proper types. It doesn't make sense to say that some value (like undefined) belongs to the collection of values characterized by them, since there is no such collection to belong to! The same sort of thing holds for datakinds. Types of kind 'Nat are not proper, in exactly the same way that types of kind *->* or *->*->* are not proper. -- Live well, ~wren

1 0

ANN: hledger 0.21
by Simon Michael 02 Jun '13

02 Jun '13

I'm pleased to announce hledger and hledger-web 0.21! hledger is a command-line tool and haskell library for tracking financial transactions, which are stored in a human-readable plain text format. In addition to reporting, it can also help you record new transactions, or convert CSV data from your bank. Add-on packages include hledger-web (providing a web interface), hledger-irr and hledger-interest. hledger is inspired by and compatible with John Wiegley's Ledger. For more, see http://hledger.org . Install it: cabal update; cabal install hledger [hledger-web] For more installation help, see http://hledger.org/MANUAL.html#installing . Or, sponsor a ready-to-run binary for your platform: http://hledger.org/DOWNLOAD.html . Release notes (http://hledger.org/NEWS.html#hledger-0.21) **Bugs fixed:** - parsing: don't fail when a csv amount has trailing whitespace (fixes #113) - web: don't show prices in the accounts sidebar (fixes #114) - web: show one line per commodity in charts. Needs more polish, but fixes #109. - web: bump yesod-platform dependency to avoid a cabal install failure **Journal reading:** - balance assertions are now checked after reading a journal **web command:** - web: support/require yesod 1.2 - web: show zero-balance accounts in the sidebar (fixes #106) - web: use nicer select2 autocomplete widgets in the add form **Documentation and infrastructure:** - add basic cabal test suites for hledger-lib and hledger Release contributors: - Xinruo Sun enhanced the hledger-web add form - Clint Adams added cabal test suites - Jeff Richards did hledger-web cleanup - Peter Simons provided the build bot

1 0

Simplest way to learn FRP through use
by Christopher Howard 02 Jun '13

02 Jun '13

I want to learn FRP but am having trouble wading through all the theory about how FRP is implemented and how it /could/ be used for various applications. What is the simplest, easiest-to-learn module or system allowing you to quickly make something interesting (if not very impressive) in an FRP style? Say, a simple simulation of some physical phenomena outputting its state to the terminal; or an object moving on the screen; or some other toy application that I could create and play with. -- frigidcode.com

4 5

mapFst and mapSnd
by Dominique Devriese 01 Jun '13

01 Jun '13

Hi all, I often find myself needing the following definitions: mapPair :: (a -> b) -> (c -> d) -> (a,c) -> (b,d) mapPair f g (x,y) = (f x, g y) mapFst :: (a -> b) -> (a,c) -> (b,c) mapFst f = mapPair f id mapSnd :: (b -> c) -> (a,b) -> (a,c) mapSnd = mapPair id But they seem missing from the prelude and Hoogle or Hayoo only turn up versions of them in packages like scion or fgl. Has anyone else felt the need for these functions? Am I missing some generalisation of them perhaps? Regards, Dominique

12 13

lifted-base linking failure with GHC HEAD
by Mateusz Kowalczyk 01 Jun '13

01 Jun '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, I'm attempting to build lifted-base (as a dependency for ghc-mod) but cabal-install fails every time during the linking phase. I pasted the full log of `cabal install lifted-base --verbose' to hpaste at [1]. I'm attempting to build it with GHC HEAD. Now, I should note that I have different directories for each ghc version in my ~. So, for ghc 7.6.3 I would have ~/ghc-7.6.3 with appropriate bin, lib etc. in there. I thought that might have made `ld' confused but I just tried to `cabal install lifted-base' with 7.6.3 and it succeeded. Any ideas about what might be wrong? [1] - http://hpaste.org/89046 - -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRqTOjAAoJEM1mucMq2pqXt+QQALM9oWexq5NrWwOmcIj+m+08 DdNpj37KYx+M+3SUZYQ7RVyW7pf7ounsl/1OtGGndhGBeBpeamOMeZxaYvIZr7da IUjd3Vgnl0W44G+T9Wg64g+MIgyy75oLFPNnP0BGbcLzDk5wVgAl/xl+H193lLmu LbBJGAzAE+YHIx1mM+mNGsYgr80dhpGTs5jGdauAEdsnZFdFGj86sxBeFBeKVF78 md0PA1HDwJSVo2FyAAULWhgPDpwBrScjNjTU2etMpegMto1aDaV7rwvJeNeewv15 89o19tpWTvdwxtddOI6YlBKFTL0u80IBlCRQ+NWwu7PB35wR67MbOchXx4qGJSOt TxNelfW+C3h0BW7KLskQjqcEPUKD1hYB5lAnOH2VOaTSFEN9QN66GhC3BHLJCBiu UWZBRyUikAsjRvWL6eQI+vc8fnPSieNa5K2jdPe410uHojr7Eq28WCCXsejaQ3e+ TviDUWLmGfJk97Zmz2NPy4oGqwNYvOQqXKZ4GIpzD1/UHfNUw9wykPuDCapuvXPl OcSlSyjPk70jG32aLEalVZKPYZ1g15VSY6d6WYquZO0mGpwL15Gvc8V7SlZfNpvT 8maX5CQEeNXqfEbl2PwnkfoCwvW7x2p7uD+M2MHxOozkn5vtUonXqFCOVCftE/nL KsYrafRMuMzNRCn4kE/M =OCEQ -----END PGP SIGNATURE-----

1 0

Performance difference between Linux and Windows?
by James Jones 31 May '13

31 May '13

I've been having a great deal of fun writing a program to solve this year's Code Jam "Fair and Square"problem in Haskell (and learning about Haskell in the process). Having gotten it to work, I've been optimizing it as best I can. I'm not quite in Captain Ahab mode, but before I let it go I would like to find out what's behind a difference I've seen compiling and running the program under Linux and under Windows 7. Profiling it under Linux (compiled with GHC 7.4.1), it had a total allocation of 165,375,112 bytes. I had an opportunity to compile and run on Windows 7, with GHC 7.4.2. I expected it to run faster, since the Windows computer had a 3.1 GHz i7 and my Linux computer has a 2.8 GHz AMD Propus, but what I didn't expect was that the total allocation on the Windows version was 88,438,372 bytes! Thinking it might be due to a compiler improvement, I upgraded my Linux computer to Ubuntu 13.04 so I could get a newer GHC, but it didn't make much difference: total allocation 163,248,688 bytes. So, I'm wondering: what is it about either the Windows implementation or GHC 7.4.2 in particular that would make a factor of two difference in memory allocation? Should anyone wish to compile the program, let me know the best way to make the source available and I will happily do so; I also use Twan van Laarhoven's semilattice search tree code available at http://twanvl.nl/blog/haskell/SemilatticeSearchTree. James Jones

2 1

Job opening Ph D student in type error diagnosis for domain specific languages in Haskell
by Jurriaan Hage 31 May '13

31 May '13

Dear Haskellers, Apologies in case you have received multiple copies. best, Jur =============================================================================== VACANCY : 1x Phd Student in domain specific type error diagnosis for Haskell =============================================================================== The activities of the Software Systems division at Utrecht University include research on programming methodologies, compiler construction, and program analysis, validation, and verification. For information about the research group of Software Technology, see: http://www.cs.uu.nl/wiki/Center Financed by the Netherlands Organisation for Scientific Research (NWO), we currently have a job opening for: * 1x PhD researcher (Ph D student) Software Technology Domain-specific languages (DSLs) have the potential both to reduce the effort of programming, and to result in programs that are easier to understand and maintain. For various good reasons, researchers have proposed to embed DSLs (then called EDSLs) into a general purpose host language. An important disadvantage of such an embedding is that it is very hard to make type error diagnosis domain-aware, because inconsistencies are by default explained in terms of the host language. We are currently looking for a highly motivated Ph D student to investigate this problem in the context of the functional language Haskell. The basic approach is to scale the concept of specialized type rules as developed by (Heeren, Hage and Swierstra, ICFP '03, see link below) for Haskell '98 to modern day Haskell with all of its type system extensions. The work is both technically challenging, i.e., how do you ensure that modifications to the type diagnositic process do not inadvertently change the type system, and practically immediately useful: making domain-specific type error diagnosis a reality for a full sized language such as Haskell is likely to have a pervasive influence on the field of domain-specific languages, and the language Haskell. The ICFP '03 paper can be found at http://www.cs.uu.nl/people/jur/scriptingthetypeinferencer.pdf A project paper that describes the context and aims of the current project can be found here: http://www.cs.uu.nl/people/jur/tfp2013_submission_2.pdf At first, the work will be prototyped in our own Utrecht Haskell Compiler. If succesfull, the work will also make its way into the GHC. We expect the candidate to communicate the results academically, to present the work at scientific conferences, to supervise Master students, and to assist in teaching courses at Bachelor or Master level. --------------------------------- What we are looking for --------------------------------- The candidate should have an MSc in Computer Science, be highly motivated, speak and write English very well, and be proficient in producing scientific reports. Knowledge of and experience with at least one of the following two areas is essential: * functional programming, and Haskell in particular * type system concepts Furthermore, we expect the candidate to be able to reason formally. Experience in compiler construction is expected to be useful in this project. --------------------------------- What we offer --------------------------------- You are offered a full-time position for 4 years. The gross salary is in the range between € 2083,- and maximum € 2664,- per month. The salary is supplemented with a holiday bonus of 8% and an end-of-year bonus of 8,3% per year. In addition we offer: a pension scheme, a partially paid parental leave, flexible employment conditions. Conditions are based on the Collective Labour Agreement Dutch Universities. We aim to start November 1, 2013 at the latest, but preferably sooner. --------------------------------- In order to apply --------------------------------- To apply please attach a letter of motivation, a curriculum vitae, and (email) addresses of two referees. Make sure to also include a transcript of the courses you have followed (at bachelor and master level), with the grades you obtained, and to include a sample of your scientific writing, e.g., the pdf of your master thesis. It is possible to apply for this position if you are close to obtaining your Master's. In that case include a letter of your supervisor with an estimate of your progress, and do not forget to include at least a sample of your technical writing skills. Application closes on the 20th of June 2013. For application, visit http://www.cs.uu.nl/vacatures/en/583630.html and follow the link to the official job application page at the bottom. --------------- Contact person --------------- For further information you can direct your inquiries to: Dr. Jurriaan Hage Phone: (+31) 30 253 3283 e-mail: J.Hage(a)uu.nl. website: http://www.cs.uu.nl/wiki/Hage/WebHome

1 0

Call for Papers IFL 2013
by publicityifl＠gmail.com 31 May '13

31 May '13

=============================================================================== VACANCY : 1x Phd Student in domain specific type error diagnosis for Haskell =============================================================================== The activities of the Software Systems division at Utrecht University include research on programming methodologies, compiler construction, and program analysis, validation, and verification. For information about the research group of Software Technology, see: http://www.cs.uu.nl/wiki/Center Financed by the Netherlands Organisation for Scientific Research (NWO), we currently have a job opening for: * 1x PhD researcher (Ph D student) Software Technology Domain-specific languages (DSLs) have the potential both to reduce the effort of programming, and to result in programs that are easier to understand and maintain. For various good reasons, researchers have proposed to embed DSLs (then called EDSLs) into a general purpose host language. An important disadvantage of such an embedding is that it is very hard to make type error diagnosis domain-aware, because inconsistencies are by default explained in terms of the host language. We are currently looking for a highly motivated Ph D student to investigate this problem in the context of the functional language Haskell. The basic approach is to scale the concept of specialized type rules as developed by (Heeren, Hage and Swierstra, ICFP '03, see link below) for Haskell '98 to modern day Haskell with all of its type system extensions. The work is both technically challenging, i.e., how do you ensure that modifications to the type diagnositic process do not inadvertently change the type system, and practically immediately useful: making domain-specific type error diagnosis a reality for a full sized language such as Haskell is likely to have a pervasive influence on the field of domain-specific languages, and the language Haskell. The ICFP '03 paper can be found at http://www.cs.uu.nl/people/jur/scriptingthetypeinferencer.pdf A project paper that describes the context and aims of the current project can be found here: http://www.cs.uu.nl/people/jur/tfp2013_submission_2.pdf At first, the work will be prototyped in our own Utrecht Haskell Compiler. If succesfull, the work will also make its way into the GHC. We expect the candidate to communicate the results academically, to present the work at scientific conferences, to supervise Master students, and to assist in teaching courses at Bachelor or Master level. --------------------------------- What we are looking for --------------------------------- The candidate should have an MSc in Computer Science, be highly motivated, speak and write English very well, and be proficient in producing scientific reports. Knowledge of and experience with at least one of the following two areas is essential: * functional programming, and Haskell in particular * type system concepts Furthermore, we expect the candidate to be able to reason formally. Experience in compiler construction is expected to be useful in this project. --------------------------------- What we offer --------------------------------- You are offered a full-time position for 4 years. The gross salary is in the range between Û 2083,- and maximum Û 2664,- per month. The salary is supplemented with a holiday bonus of 8% and an end-of-year bonus of 8,3% per year. In addition we offer: a pension scheme, a partially paid parental leave, flexible employment conditions. Conditions are based on the Collective Labour Agreement Dutch Universities. We aim to start November 1, 2013 at the latest, but preferably sooner. --------------------------------- In order to apply --------------------------------- To apply please attach a letter of motivation, a curriculum vitae, and (email) addresses of two referees. Make sure to also include a transcript of the courses you have followed (at bachelor and master level), with the grades you obtained, and to include a sample of your scientific writing, e.g., the pdf of your master thesis. It is possible to apply for this position if you are close to obtaining your Master's. In that case include a letter of your supervisor with an estimate of your progress, and do not forget to include at least a sample of your technical writing skills. Application closes on the 20th of June 2013. For application, visit http://www.cs.uu.nl/vacatures/en/583630.html and follow the link to the official job application page at the bottom. --------------- Contact person --------------- For further information you can direct your inquiries to: Dr. Jurriaan Hage Phone: (+31) 30 253 3283 e-mail: J.Hage(a)uu.nl. website: http://www.cs.uu.nl/wiki/Hage/WebHome

2 1

Projects using Shake
by Frerich Raabe 31 May '13

31 May '13

Hi, I'm considering to convert one of my projects to Shake; everything I've seen so far seemed really interesting! However, before I start, I'd like to see how other people structure their Shake-based build systems. I tried to find some open source projects which showcase how Shake is used, but unfortunately I didn't find anything yet. Is anybody aware of open source projects which I could look at, or is there maybe a conventional file extension for… what do you call them, "Shakefiles"? other than .hs which I could google for? -- Frerich Raabe - raabe(a)froglogic.com www.froglogic.com - Multi-Platform GUI Testing

3 2