May 2015 - Haskell-Cafe

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Herbert Valerio Riedel 06 May '15

06 May '15

On 2015-05-06 at 17:36:05 +0200, Stephen Paul Weber wrote: >>As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension >>currently relies on the system's C-compiler bundled `cpp` program to >>provide a "traditional mode" c-preprocessor. > > Yes. This is one of my favourite things in GHC-land -- that an > existing, good-enough, standardised, and widely-deployed solution was > chosen over a NiH reinvention of preprocessing. This allows other > Haskell compilers to support CPP on basically any system (since cpp is > so standard) without much effort, or even if the compiler does not > support {-# LANGUAGE CPP -#} the user can easily run `cpp` over the > source files themselves before feeding the source into the compiler. > > Because it is a real `cpp` being used, the developmer must take care > to follow the CPP syntax in the file that will then be transformed > into Haskell by `cpp` in the same way that C, C++, and other > developers have to take extra care (especially around use of # and > end-of-line \) when using `cpp`, but this is the normal state of > affairs for a secondary preprocessor step. As a benefit, the source > code will be processable by standard `cpp` implementations available > for virtually every platform. > > In short, the current solution provides a very robust and portable way > to do pre-compile preprocessing, and I like it very much. The problem I have with that line of argument is that we're using the so-called 'traditional mode' of `cpp`[1] for which afaik there is no written down common specification different implementations commit to adhere to (well, that's because 'traditional mode' refers to some vague implementation-specific "pre-standard" cpp semantics). And how is the developer supposed to take care to follow the (traditional mode) CPP syntax, if he can't test it easily with all potentially used (traditional-mode) `cpp`s out there? This already has led to problems with Clang's cpp vs GCC's cpp. Moreover, I was under the impression that it's only a matter of time till `traditional mode` support may be dropped from C compiler toolchains. Otoh, we can't use an ISO C spec conforming c-preprocessor, as that would conflict even more heavily w/ Haskell's grammar to the point of being inpractical. [1]: https://gcc.gnu.org/onlinedocs/cpp/Traditional-Mode.html

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Brandon Allbery 06 May '15

06 May '15

On Wed, May 6, 2015 at 11:27 AM, Kosyrev Serge <_deepfire(a)feelingofgreen.ru> wrote: > Why *shouldn't* TH fill that role? What can be done about it? For one, it's difficult to make it available in cross compilers (granted, work is being done on this) and not available on some platforms (ARM has been a problem, dunno if it currently is). For another, I don't think you can currently control things like imports or LANGUAGE pragmas --- and as TH is currently constructed it's not clear that you could do so, or that you could do so in a way that is sane for users. This is not to say that I like cpp --- I'd like it a lot more if it weren't actually using a C preprocessor that is not actually under our control or guaranteed to be compatible with Haskell --- but it does provide a "meta" in a different dimension than TH does. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Brandon Allbery 06 May '15

06 May '15

On Wed, May 6, 2015 at 10:59 AM, Bardur Arantsson <spam(a)scientician.net> wrote: > (I'm not going to be doing any of the work, so this is just armchairing, > but this seems like an 80/20 solution would be warranted.) > Only if you're convinced it will remain 80/20 for the foreseeable future. I do not want to bet on Linux always being gcc (and dislike the One True Platform-ism that line of thought encourages). -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

minor confusion over kinds....
by Nicholls, Mark 06 May '15

06 May '15

And what "*" means as opposed to other things e.g. an explicit name "Nat" or a kind variable "k" > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} what I want is a typeclass with instances of type level Naturals here's the class, the parameter is of kind (* -> *) i.e. a is some sort of wrapper that maps from types to values > class Foo (a :: * -> *) where > type Bar a > bar :: a (Bar a) lets ignore DataKinds define Zero and Succ as distinct types uninhabited...but of kind "*" and "k -> *" > data Z1 > data S1 nat SNat1 :: * -> * > data SNat1 a where > SZ1 :: SNat1 Z1 > SS1 :: SNat1 a -> SNat1 (S1 a) off we go... > instance Foo SNat1 where > type Bar SNat1 = Z1 > bar = SZ1 now lets do it the datakind route > data Nat where > Z :: Nat > S :: Nat -> Nat ahhh...SNat is of kind "Nat -> *" > data SNat a where > SZ :: SNat 'Z > SS :: SNat a -> SNat ('S a) so I cant make it an instance of the same type class "The first argument of 'Foo' should have kind '* -> *', but 'SNat' has kind 'Nat -> *' In the instance declaration for 'Foo SNat'" > --instance Foo SNat where > -- type Bar SNat = 'Z > -- bar = SZ unless I redefine my class (which seems a bit silly) > class Foo' (a :: k -> *) where > type Bar' a :: k > bar' :: a (Bar' a) now it works. > instance Foo' SNat where > type Bar' SNat = 'Z > bar' = SZ clearly named kinds (?) are somehow distinct from unnames ones? CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

1 0

Assistant Professorship in Nottingham
by Graham Hutton 06 May '15

06 May '15

Dear all, The School of Computer Science at the University of Nottingham is seeking to appoint a new Assistant Professor: http://www.nottingham.ac.uk/jobs/currentvacancies/ref/SCI41814 Applications in the area of the Functional Programming (FP) lab are encouraged. The FP lab is keen to receive applications from candidates with an excellent publication record, experience in combining theory with practice, and the ability to secure external funding to support their research. Further information about the FP lab is available from: http://fp.cs.nott.ac.uk The deadline for applications is Wednesday 15th July 2015. Best wishes, Graham -- Prof Graham Hutton Functional Programming Lab School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~gmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

ANN: HList 0.4
by adam vogt 06 May '15

06 May '15

Hello List, I've uploaded HList-0.4 [1]. Some highlights from this release: * support for 7.6 <= GHC <= 7.10 * new modules HCurry and HSort * many new functions: see the changelog [2] * data HList becomes data family. Trade-offs are explained in the documentation [3] Regards, Adam [1] http://hackage.haskell.org/package/HList-0.4.0.0 [2] http://hackage.haskell.org/package/HList-0.4.0.0/changelog [3] http://hackage.haskell.org/package/HList-0.4.0.0/docs/Data-HList-HList.html…

1 0

ANN: Yampa 0.9.7 and 0.10.0
by Ivan Perez 05 May '15

05 May '15

Dear all Two new versions of Yampa have just been made available on hackage. A short reminder for those who don't know: Yampa is a Functional Reactive Programming DSL structured around Signal Functions. It enforces a separation between effectful input/output and purely functional signal transformations. Arrow notation can be used to connect signal functions. Yampa has recently been used to write several games available on Github [2] and Google Play (for Android) [3, 4]. Regarding the new versions: - Version 0.9.7 is fully backwards compatible and includes minimal changes. - Version 0.10.0 is mostly, but not fully, backwards compatible and has been restructured in modules to make documentation easier. We expect this to help users find and understand the available combinators better. I have tried both versions with the game Haskanoid [2] and they work. If your project cannot be compiled or executed correctly with either version, please open an issue on our project page [1]. Yampa is being actively developed, and we are working on FRP extensions that we hope will be introduced in future versions. Code, documentation and research contributions are welcome. All the best Ivan [1] https://github.com/ivanperez-keera/Yampa [2] https://github.com/ivanperez-keera/haskanoid [3] https://play.google.com/store/apps/details?id=uk.co.keera.games.magiccookies [4] https://github.com/keera-studios/magic-cookies

1 1

Re: [Haskell-cafe] Significant changes in -Wall for GHC 7.10
by Alexander Eyers-Taylor 05 May '15

05 May '15

Sorry I forgot to reply to the list. Here is my earlier email -------- Forwarded Message -------- Subject: Re: [Haskell-cafe] Significant changes in -Wall for GHC 7.10 Date: Tue, 05 May 2015 16:29:46 +0100 From: Alexander Eyers-Taylor <aeyerstaylor11(a)gmail.com> To: Omari Norman <omari(a)smileystation.com> Those seem to be preciously the flags enabled by -Wall. It seems when updating the documentation the negative was missed and it was updated to list the flags enabled by -Wall. I have submitted a ticket (#10386) to fix the bug. On 05/05/15 16:03, Omari Norman wrote: > CORRECTION: -fwarn-trustworthy-safe was not in -Wall in GHC 7.8, but > -fwarn-trustworthy-safe did not exist in GHC 7.8. > > On Tue, May 5, 2015 at 10:54 AM, Omari Norman <omari(a)smileystation.com > <mailto:omari@smileystation.com>> wrote: > > I noticed some significant changes to the flags included with > -Wall in GHC 7.10. Many flags that were previously included in > -Wall are now not included. These include: > > -fwarn-type-defaults > -fwarn-name-shadowing > -fwarn-missing-signatures > -fwarn-hi-shadowing > -fwarn-orphans > -fwarn-unused-do-bind > -fwarn-trustworthy-safe > > I can't find any mention in the release notes of this change in > behavior. > > I was wondering what the rationale is for these changes? Any link > to relevant discussion would be appreciated if it exists. > > Also, what opinion do people have? I previously kept my code > -Wall clean, but sometimes that would be a pain. For instance I > would munge local names so they wouldn't trigger > -fwarn-name-shadowing, and I would add signatures to integers so > they wouldn't trigger -fwarn-type-defaults. In fact, I only > noticed this change in behavior in 7.10 because I was considering > dumping -Wall, and when I looked at the 7.10 manual I saw that it > does not enable -fwarn-name-shadowing. (I still use 7.8 but > Google pulled the 7.10 manual.) Does this change indicate that > people were finding -Wall too onerous and, thus, not using it? > > I do remember reading complaints about -fwarn-unused-do-bind being > added to -Wall, but I previously felt dirty about name shadowing > though I wondered if munging names to avoid shadowing was actually > worse. > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

1 0

Significant changes in -Wall for GHC 7.10
by Omari Norman 05 May '15

05 May '15

I noticed some significant changes to the flags included with -Wall in GHC 7.10. Many flags that were previously included in -Wall are now not included. These include: -fwarn-type-defaults -fwarn-name-shadowing -fwarn-missing-signatures -fwarn-hi-shadowing -fwarn-orphans -fwarn-unused-do-bind -fwarn-trustworthy-safe I can't find any mention in the release notes of this change in behavior. I was wondering what the rationale is for these changes? Any link to relevant discussion would be appreciated if it exists. Also, what opinion do people have? I previously kept my code -Wall clean, but sometimes that would be a pain. For instance I would munge local names so they wouldn't trigger -fwarn-name-shadowing, and I would add signatures to integers so they wouldn't trigger -fwarn-type-defaults. In fact, I only noticed this change in behavior in 7.10 because I was considering dumping -Wall, and when I looked at the 7.10 manual I saw that it does not enable -fwarn-name-shadowing. (I still use 7.8 but Google pulled the 7.10 manual.) Does this change indicate that people were finding -Wall too onerous and, thus, not using it? I do remember reading complaints about -fwarn-unused-do-bind being added to -Wall, but I previously felt dirty about name shadowing though I wondered if munging names to avoid shadowing was actually worse.

2 4

finding things on haskell.org
by Doug McIlroy 05 May '15

05 May '15

The only search feature I'm aware of on the haskell website is the haskell wiki, which is a self-contained little corner. For example, the wiki says nothing about minGHC. To find out what the website has on the subject, I used a Google query: site:haskell.org minghc. Is there thought of a comprehensive site-search facility that can find anything, including stuff that hasn't been wiki-ized? Doug

2 1