Re: [Haskell-cafe] ANN: generic-deepseq 1.0.0.0
Hi, 2012/2/19 Bas van Dijk > > I do think it's better to integrate this into the deepseq package (and > thus removing the default implementation of rnf). Otherwise we end up > with two ways of evaluating values to normal form. > I agree with this, and I guess many people are already using the deepseq package (simply because it was there first), so it would be better to integrate the generic code with that package. As for the backwards compatibility loss, it is indeed a pity that you are forced to choose between a generic default and a "normal" default, but I don't see any easy way to change that, and the current behaviour is simple and predictable. So I do not propose we change that. In this case I agree with Bas, and propose removing the "normal" default for `rnf`. > > One last issue: Say I have a type like: "data T = C !Int" > Currently GHC Generics can't express the strictness annotation. This > means that your deepseq will unnecessarily evaluate the Int (since it > will always be evaluated already). It would be nice if the strictness > information could be added to the K1 type. (José, would it be hard to > add this to GHC.Generics?) > I don't think so; I think the right place to put it is as a method of the Selector class, though. But, I'm wondering, for your example, wouldn't/couldn't GHC optimize away `seq` calls to strict arguments? Cheers, Pedro ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper
On Sun, Feb 19, 2012 at 23:27, Richard O'Keefe wrote: > Now *that's* annoying. It turns out that the xattr command is *there*, > but 'man xattr' is completely silent. There is nothing for it in > /usr/share/man/man1 . I had been using my own command to do the > equivalent of xattr -d. Bzuh? haral:23276 Z$ pkgutil --file-info /usr/share/man/man1/xattr.1 volume: / path: /usr/share/man/man1/xattr.1 pkgid: com.apple.pkg.BSD pkg-version: 10.7.0.1.1.1293150744 install-time: 1310114676 uid: 0 gid: 0 mode: 644 (Lion, as you probably got from the pkg-version field, but I recall it also being on my SL desktop box that's currently in storage.) -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper
On 20/02/2012, at 3:04 PM, Jack Henahan wrote: > > What's your setup like that you can't even use gdb in your own directory? > That sounds unusual. And you can turn off the warning, either globally or > selectively.[3][4] My setup is Mac OS X 10.6.8, pretty much out of the box, plus a bunch of additional stuff, but nothing removed. The invariable University policy is that *nobody* except a few designated system administrators is allowed to have root access on any machine connected to the University's ethernets. (Apparently nobody has told them about VirtualBox yet, so I can happily root access Solaris, Linux, and OpenBSD on my Macs.) So - there's the root account, - there's an "admin" account just for me, which lets me turn the printer on and install software, but not run DTrace, and - there's my ordinary user account. I can run gdb just fine, it's setting a breakpoint and then trying to run the program that it doesn't like. I have to re-authenticate for this every time I log in. > > [3]: > http://osxdaily.com/2010/03/29/disable-the-are-you-sure-you-want-to-open-this-file-warning-dialogue-in-mac-os-x/ Thank you. I did not know about that. I have been working around it by deleting the com.apple.quarantine xattr. > [4]: > http://osxdaily.com/2010/09/12/disable-application-downloaded-from-the-internet-message-in-mac-os-x/ Now *that's* annoying. It turns out that the xattr command is *there*, but 'man xattr' is completely silent. There is nothing for it in /usr/share/man/man1 . I had been using my own command to do the equivalent of xattr -d. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Disabling warning over ranges of source lines
On 20 February 2012 15:06, Thomas DuBuisson wrote:
> Using GHC, is there any way to disable warnings (entirely or
> selectively) during a section of source code? I ask because of some
> Template Haskell that periodically generates unused code and I'd
> rather not see the warnings or rework the macros (beyond emitting some
> sort of "disable" and "re-enable" pragma which probably isn't in the
> AST now that I think about it).
You can do something like:
{-# OPTIONS_GHC -fno-warn-orphans #-}
At the top of specified modules. However, I'm not sure if there's a
specific flag to disable *all* warnings.
>
> Cheers,
> Thomas
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Disabling warning over ranges of source lines
Using GHC, is there any way to disable warnings (entirely or selectively) during a section of source code? I ask because of some Template Haskell that periodically generates unused code and I'd rather not see the warnings or rework the macros (beyond emitting some sort of "disable" and "re-enable" pragma which probably isn't in the AST now that I think about it). Cheers, Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper
In fact, since Gatekeeper, by design, can only quarantine applications acquired through the App Store or a download (or any other method which applies the quarantine flag), it may be entirely irrelevant for you depending on how you distribute. Applications on physical media are exempt, source builds are exempt, as are apps you create. Anything you've already run is similarly trusted, and anything you have to build yourself is, as well. It's fairly developer-friendly, really. Jack Henahan jhena...@uvm.edu == Computer science is no more about computers than astronomy is about telescopes. -- Michael R. Fellows == PublicKey.asc Description: application/apple-msg-attachment signature.asc Description: Message signed with OpenPGP using GPGMail ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
> I'm proposing my record fields so that selectors are just functions. Then it's > independent of dot notation. (It's the semantics I'm far more concerned > with.) Folks, I've put my 'Record in Haskell' proposal on the wiki http://hackage.haskell.org/trac/ghc/wiki/Records as suggestion 5 Declared Overloaded Record Fields. Thanks to the voiciferousness on this thread, dot notation is completely optional. Feedback welcome. AntC -- View this message in context: http://haskell.1045720.n5.nabble.com/Some-thoughts-on-Type-Directed-Name-Resolution-tp5280846p5498073.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper
As has been mentioned, it's already possible to override Gatekeeper on a per-app basis, and what I've seen so far is that it operates just as the download warning: once you get past the first check, it never bothers you again. Is it unreasonable for your users to open it that way once? As for signing, there's nothing exclusive to Xcode there. Just the `codesign` tool available as usual. Jack Henahan jhena...@uvm.edu == Computer science is no more about computers than astronomy is about telescopes. -- Michael R. Fellows == PublicKey.asc Description: application/apple-msg-attachment On Feb 19, 2012, at 9:19 PM, Tom Murphy wrote: > On 2/19/12, Austin Seipp wrote: >> On Sun, Feb 19, 2012 at 6:01 PM, Tom Murphy wrote: >>> 0) Distributing non-Cocoa-built apps, even if you're approved by Apple >> >> Do you just mean binaries that you expect users run under >> /usr/local/bin or something, not app bundles? If that's the case, I >> cannot say if the same restrictions will apply. > > Actually, what I was more concerned about was the ability to > distribute a "full" Mac application, with a GUI, made with a method > other than calling Haskell from Objective-C. > It seems that *none* of these applications will be usable by > anyone except users with all security settings turned off (it doesn't > sound great in a user manual: "Every time you run this program, be > sure to turn the malware-detector all the way off") > > The reason I'm concerned is that having a security signature > requires a membership to the Apple Developers program, which is > exclusively for XCode [0]. Isn't it logical to assume that the > signature-"bundling" process [1] occurs within XCode? > (I'm assuming the "digital summary of the contents of the > application" is a hash, which (I think) would imply that > XCode-compilation would have to be the final step in the development > chain) > > Which (again, unless I'm reading it wrong) means that most > Haskell OS X GUI work (incl. FRP) goes out the window?! > > amindfv / Tom > > > [0] Not to mention $100 every year! > > [1] "Digital signatures are created by combining a secret key known > only to the developer with a digital summary of the contents of the > application. It’s all wrapped together in an encrypted file that > becomes part of the app." > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc Description: Message signed with OpenPGP using GPGMail ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper
On Sun, Feb 19, 2012 at 8:39 PM, Tom Murphy wrote: > On the other hand, > it's impossible for a software company to maintain a sense of > professionalism, when a user has to know a weird "secret handshake" to > disable what they may perceive as equivalent to antivirus software. I'll also just add that if you're an actual software company, large or small, the $100 for the developer ID, certificate, ability to do iOS/App store apps, whatever, is a business expense, that is utterly dominated by a million other factors, as developing high quality applications isn't exactly cheap, and the price of a license is really the last thing you're going to worry about. If you're more worried about the potential to impact individual developers and small open source teams who want to get their work out there, you are right it's a concern. We'll have to wait and see when more details arise. -- Regards, Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper
On Sun, Feb 19, 2012 at 8:19 PM, Tom Murphy wrote: > Actually, what I was more concerned about was the ability to > distribute a "full" Mac application, with a GUI, made with a method > other than calling Haskell from Objective-C. > It seems that *none* of these applications will be usable by > anyone except users with all security settings turned off (it doesn't > sound great in a user manual: "Every time you run this program, be > sure to turn the malware-detector all the way off") > > The reason I'm concerned is that having a security signature > requires a membership to the Apple Developers program, which is > exclusively for XCode [0]. Isn't it logical to assume that the > signature-"bundling" process [1] occurs within XCode? > (I'm assuming the "digital summary of the contents of the > application" is a hash, which (I think) would imply that > XCode-compilation would have to be the final step in the development > chain) On OS X, you can sign applications or paths using any certificate you like using the 'codesign' utility, including a .app bundle. If you're going to distribute an OS X application to average users, let's face it: you're going to give them an .app bundle. You can do it yourself with a self-trusted code signing certificate already. Building LLDB on OS X for example, requires self signing in this manner, because the debugging engine needs permissions granted by the signature (AFAIK.) Regular LLDB with XCode already comes signed by Apple, obviously. > Which (again, unless I'm reading it wrong) means that most > Haskell OS X GUI work (incl. FRP) goes out the window?! No. Just sign your .app bundle with your Developer ID cert using codesign after the build and bundling process, and it'll work unless they only have Gatekeeper enabled to allow Mac App store apps. There's nothing you can do about this if they have it enabled if you're not willing to put it on the store, other than advise them to disable it. If it's on the store, you've already paid for the developer license and signed it anyway. The only differences mountain lion adds is that now you must at least sign those applications which you intend to distribute to regular users by whatever means, but not put them on the App Store. That's really it at the core. And tech demos and code examples will never be relevant if the target is programmers really, because developers are just going to have it disabled (equivalent to the way OS X is now, in effect.) The only two things not clear at this point, at least to me, are: 1) Will Apple require the paid development program, as opposed to the free one, if you only want to self-sign applications with a cert they trust? 2) What will the default Gatekeeper setting in Mountain Lion be? These 2 factors will control whether or not you'd have to pay and the user impact. In an ideal world, you won't require the paid dev ID (I don't know the expense of giving out certs however,) and the default setting would be App store + Dev signed. Unfortunately we'll just have to wait and see on that note. -- Regards, Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper
> *Short* term, the most that will happen is that people will have to > say "yeah yeah I know just let me have it OK?". > > Already in 10.6 there was this nagging feature where you click on a > downloaded document and it says "this was downloaded, do you really > want to open it" and it takes a painfully long time bouncing in the > dock before that dialogue box comes up. > I disagree. I don't think the control-click bypass is realistic for real world applications. (Meaning software written for "the average user"). With the 10.6 dialogue box, it's clear that there's no negative inference about the particular software downloaded. On the other hand, it's impossible for a software company to maintain a sense of professionalism, when a user has to know a weird "secret handshake" to disable what they may perceive as equivalent to antivirus software. > *Short* term, it's just more continuing low-level harassment by > Apple (even if perhaps with good intentions). Long term, well, > there's a reason why I keep Solaris, Linux, and OpenBSD around... I disagree that this is a small move. $100 per year from every Mac OS X developer in the world, plus 30% of the take from the App Store is big money. - amindfv / Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper
On 2/19/12, Austin Seipp wrote: > On Sun, Feb 19, 2012 at 6:01 PM, Tom Murphy wrote: >> 0) Distributing non-Cocoa-built apps, even if you're approved by Apple > > Do you just mean binaries that you expect users run under > /usr/local/bin or something, not app bundles? If that's the case, I > cannot say if the same restrictions will apply. Actually, what I was more concerned about was the ability to distribute a "full" Mac application, with a GUI, made with a method other than calling Haskell from Objective-C. It seems that *none* of these applications will be usable by anyone except users with all security settings turned off (it doesn't sound great in a user manual: "Every time you run this program, be sure to turn the malware-detector all the way off") The reason I'm concerned is that having a security signature requires a membership to the Apple Developers program, which is exclusively for XCode [0]. Isn't it logical to assume that the signature-"bundling" process [1] occurs within XCode? (I'm assuming the "digital summary of the contents of the application" is a hash, which (I think) would imply that XCode-compilation would have to be the final step in the development chain) Which (again, unless I'm reading it wrong) means that most Haskell OS X GUI work (incl. FRP) goes out the window?! amindfv / Tom [0] Not to mention $100 every year! [1] "Digital signatures are created by combining a secret key known only to the developer with a digital summary of the contents of the application. It’s all wrapped together in an encrypted file that becomes part of the app." ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Test suite sections of cabal
Hello Felipe, > If we have separate directories, then you can "build-depends: > own-package". This means that on the test suite's build-depends you > need to list only the dependencies that the test-suite needs, not > every dependency. Also, you don't need to constrain the version of > any duplicated dependency. This worked well. Thank you very much! --Kazu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper
Well, the command-line tools are now available as a standalone package[1] separate from Xcode[2], so Apple's taken notice of and responded positively to large efforts like Homebrew and MacRuby. With that in mind, I don't think it's unreasonable to think this support also applies to other users of those tools, although the overall impact on source building is unclear so far. I haven't been able to find anything specific to that, yet. But Gatekeeper isn't for programmers and the like. It's for people who don't even know where the menu option is. That's why there's an option to shut it off. What's your setup like that you can't even use gdb in your own directory? That sounds unusual. And you can turn off the warning, either globally or selectively.[3][4] [1]: http://kennethreitz.com/xcode-gcc-and-homebrew.html [2]: https://developer.apple.com/downloads/index.action [3]: http://osxdaily.com/2010/03/29/disable-the-are-you-sure-you-want-to-open-this-file-warning-dialogue-in-mac-os-x/ [4]: http://osxdaily.com/2010/09/12/disable-application-downloaded-from-the-internet-message-in-mac-os-x/ Jack Henahan jhena...@uvm.edu == Computer science is no more about computers than astronomy is about telescopes. -- Michael R. Fellows == PublicKey.asc Description: application/apple-msg-attachment On Feb 19, 2012, at 8:27 PM, Richard O'Keefe wrote: > > On 20/02/2012, at 1:01 PM, Tom Murphy wrote: > >> Does anyone know what this will mean for the future of Haskell >> development in OS X?: >> >> http://www.apple.com/macosx/mountain-lion/security.html > > Quoting that document: > Or you can install all apps from anywhere, > just as you can today. You can even temporarily > override your setting by Control-clicking, and > install any app at any time. Gatekeeper leaves it all up to you. > > So in the *short* term, it makes little difference. > >> 1) Writing software for widespread use (a security setting is to only >> run software from the App Store, and I'd like to have my software >> function on users' computers.) > > *Short* term, the most that will happen is that people will have to > say "yeah yeah I know just let me have it OK?". > > Already in 10.6 there was this nagging feature where you click on a > downloaded document and it says "this was downloaded, do you really > want to open it" and it takes a painfully long time bouncing in the > dock before that dialogue box comes up. > > Heck, I have to provide an administrator account & password when I > want to run GDB in my own directory on my own program. (And you > have to love the way they removed the MacOS equivalent of truss > because it was superceded by DTrace, but you have to be superuser > to use DTrace...) > > *Short* term, it's just more continuing low-level harassment by > Apple (even if perhaps with good intentions). Long term, well, > there's a reason why I keep Solaris, Linux, and OpenBSD around... > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc Description: Message signed with OpenPGP using GPGMail ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper
On 20/02/2012, at 1:01 PM, Tom Murphy wrote: > Does anyone know what this will mean for the future of Haskell > development in OS X?: > > http://www.apple.com/macosx/mountain-lion/security.html Quoting that document: Or you can install all apps from anywhere, just as you can today. You can even temporarily override your setting by Control-clicking, and install any app at any time. Gatekeeper leaves it all up to you. So in the *short* term, it makes little difference. > 1) Writing software for widespread use (a security setting is to only > run software from the App Store, and I'd like to have my software > function on users' computers.) *Short* term, the most that will happen is that people will have to say "yeah yeah I know just let me have it OK?". Already in 10.6 there was this nagging feature where you click on a downloaded document and it says "this was downloaded, do you really want to open it" and it takes a painfully long time bouncing in the dock before that dialogue box comes up. Heck, I have to provide an administrator account & password when I want to run GDB in my own directory on my own program. (And you have to love the way they removed the MacOS equivalent of truss because it was superceded by DTrace, but you have to be superuser to use DTrace...) *Short* term, it's just more continuing low-level harassment by Apple (even if perhaps with good intentions). Long term, well, there's a reason why I keep Solaris, Linux, and OpenBSD around... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper
On Sun, Feb 19, 2012 at 6:01 PM, Tom Murphy wrote: > 0) Distributing non-Cocoa-built apps, even if you're approved by Apple Do you just mean binaries that you expect users run under /usr/local/bin or something, not app bundles? If that's the case, I cannot say if the same restrictions will apply. From my reading on the issue though, in the case of an app bundle, is that you don't have to be 'approved' per se by Apple. By having a Developer ID, you have a key you can then sign your binaries with. A binary signed with a valid key from Apple will run on any OS X machine, provided the Gatekeeper settings allow it - should that app later be discoverd as malware, or the *key* is used to sign some other piece of malware (because maybe it got stolen,) they just blacklist your key and no users can then run it. As a result, none of your applications you distribute outside of the Mac App Store have to be 'approved' - you just need to sign the binaries with your key before distributing them. It's blacklisting based, not whitelisted. > 1) Writing software for widespread use (a security setting is to only > run software from the App Store, and I'd like to have my software > function on users' computers.) Settings like this are beyond your control, it's just a fact of life. This basically affects every single thing that *isn't* in the Mac App Store, and if users decide to enable this, there's nothing you can really do other than telling them to change gatekeeper settings. Users can always over-ride this on a temporary, per-app basis, by holding control and clicking on the binary instead. > 1.0) Aren't you unable to put software under the GPL or certain > other open-source licenses on the App Store? Someone more familiar with the AS on Mac/iOS will have to comment here. I'm fairly certain the iOS store does not do GPL'd applications, but I don't know about the Mac App Store. -- Regards, Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell development in Mac OS X after Gatekeeper
Does anyone know what this will mean for the future of Haskell development in OS X?: http://www.apple.com/macosx/mountain-lion/security.html I'm particularly interested in what it'll mean for 0) Distributing non-Cocoa-built apps, even if you're approved by Apple 1) Writing software for widespread use (a security setting is to only run software from the App Store, and I'd like to have my software function on users' computers.) 1.0) Aren't you unable to put software under the GPL or certain other open-source licenses on the App Store? amindfv / Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: generic-deepseq 1.0.0.0
On Sun, 2012-02-19 at 21:06 +0100, Bas van Dijk wrote: > On 19 February 2012 18:11, Maxime Henrion wrote: > > If you're not dealing with an abstract datatype, you _shouldn't_ have an > > explicit instance, because it would be possible to write an incorrect one, > > while that is impossible if you just derive a generic implementation > > (as long as the generic code is correct, of course). > > I agree. I hadn't considered this advantage yet. I guess it's the same > argument for why it's better to automatically derive Data and Typeable > instances using the DeriveDataTypeable extension. > > > So, knowing that it would necessarily be backwards incompatible (I > > wasn't intending to hack on GHC :-), and also that, in the end, this is > > not quite the same class as the NFData class from the deepseq package, I > > thought it made more sense to create another package that would be > > mostly compatible with deepseq, but with a different class name so as to > > force people to reevaluate the need for their instances if they have > > some. I'd be interested in knowing what you and others think about that. > > Maybe I'm being overly cautious? > > I do think it's better to integrate this into the deepseq package (and > thus removing the default implementation of rnf). Otherwise we end up > with two ways of evaluating values to normal form. I'm okay with that, but I was interested in knowing whether you think my reasoning for changing the class name and thus deliberately breaking the API slightly more was sane or not (I say "more" because removing the default implementation of rnf already constitutes an API breakage in that the generic replacement would be optional and depends on having Generic instances to work). > > I'm guilty of not having preserved the "rnf :: a -> ()" > > function as the class function though, it's a wrapper around "deepseq" > > in my code. I just didn't see the point of having a class function with > > such a signature versus having a function just like "seq :: a -> b -> > > b". In retrospect, that might have been a bad idea, and maybe I should > > switch to have an "rnf :: a -> ()" class function to make switching even > > easier? > > I'm not sure but maybe a method like "rnf :: a -> ()" is easier to optimize. > > Also in my experience (with generics support in aeson and cereal) it's > a very good idea (performance-wise) to INLINE your methods like I did > in my previous message. Of course the only way to know for sure is the > create some (criterion) benchmarks. Yeah, I should definitely get going on the benchmarks. > One last issue: Say I have a type like: "data T = C !Int" > Currently GHC Generics can't express the strictness annotation. This > means that your deepseq will unnecessarily evaluate the Int (since it > will always be evaluated already). It would be nice if the strictness > information could be added to the K1 type. (José, would it be hard to > add this to GHC.Generics?) Assuming there is way to differentiate strict constructors in GHC.Generics, and that I have a specific instance so as to not call seq in that case, can you actually do such an optimization safely? Consider this code (imports omitted for simplicity): data T = C !Int deriving Generic instance DeepSeq T x :: T x = undefined main :: IO () main = print (x `deepseq` ()) I would expect this to diverge, just like it does if one uses `seq`. If we implement the optimization you suggest, I believe that deepseq wouldn't diverge, but I admit I'm not 100% sure either. Cheers, Maxime Henrion signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: generic-deepseq 1.0.0.0
On 19 February 2012 18:11, Maxime Henrion wrote: > If you're not dealing with an abstract datatype, you _shouldn't_ have an > explicit instance, because it would be possible to write an incorrect one, > while that is impossible if you just derive a generic implementation > (as long as the generic code is correct, of course). I agree. I hadn't considered this advantage yet. I guess it's the same argument for why it's better to automatically derive Data and Typeable instances using the DeriveDataTypeable extension. > So, knowing that it would necessarily be backwards incompatible (I > wasn't intending to hack on GHC :-), and also that, in the end, this is > not quite the same class as the NFData class from the deepseq package, I > thought it made more sense to create another package that would be > mostly compatible with deepseq, but with a different class name so as to > force people to reevaluate the need for their instances if they have > some. I'd be interested in knowing what you and others think about that. > Maybe I'm being overly cautious? I do think it's better to integrate this into the deepseq package (and thus removing the default implementation of rnf). Otherwise we end up with two ways of evaluating values to normal form. > I'm guilty of not having preserved the "rnf :: a -> ()" > function as the class function though, it's a wrapper around "deepseq" > in my code. I just didn't see the point of having a class function with > such a signature versus having a function just like "seq :: a -> b -> > b". In retrospect, that might have been a bad idea, and maybe I should > switch to have an "rnf :: a -> ()" class function to make switching even > easier? I'm not sure but maybe a method like "rnf :: a -> ()" is easier to optimize. Also in my experience (with generics support in aeson and cereal) it's a very good idea (performance-wise) to INLINE your methods like I did in my previous message. Of course the only way to know for sure is the create some (criterion) benchmarks. One last issue: Say I have a type like: "data T = C !Int" Currently GHC Generics can't express the strictness annotation. This means that your deepseq will unnecessarily evaluate the Int (since it will always be evaluated already). It would be nice if the strictness information could be added to the K1 type. (José, would it be hard to add this to GHC.Generics?) Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: generic-deepseq 1.0.0.0
On Sun, 2012-02-19 at 16:17 +0100, Bas van Dijk wrote:
> On 19 February 2012 13:12, Maxime Henrion wrote:
> > Any suggestions are welcome.
>
> Nice work but it would be nice to have this functionality directly in
> the deepseq package as in:
>
> #ifdef GENERICS
> {-# LANGUAGE DefaultSignatures, TypeOperators, FlexibleContexts #-}
> #endif
>
> class NFData a where
> rnf :: a -> ()
> rnf a = a `seq` ()
>
> #ifdef GENERICS
> default rnf :: (Generic a, GNFData (Rep a)) => a -> ()
> rnf = grnf . from
>
> class GNFData f where
> grnf :: f a -> ()
>
> instance GNFData U1 where
> grnf U1 = ()
> {-# INLINE grnf #-}
>
> instance NFData a => GNFData (K1 i a) where
> grnf = rnf . unK1
> {-# INLINE grnf #-}
>
> instance GNFData f => GNFData (M1 i c f) where
> grnf = grnf . unM1
> {-# INLINE grnf #-}
>
> instance (GNFData f, GNFData g) => GNFData (f :+: g) where
> grnf (L1 x) = grnf x
> grnf (R1 x) = grnf x
> {-# INLINE grnf #-}
>
> instance (GNFData f, GNFData g) => GNFData (f :*: g) where
> grnf (x :*: y) = grnf x `seq` grnf y
> {-# INLINE grnf #-}
> #endif
>
> Unfortunately this is not possible since the two default
> implementations conflict. I see two solutions:
>
> 1) Change the DefaultSignatures extension to always give preference to
> the default signature. I think giving preference to the default
> signature makes sense since it's usually more specific (more
> constraint) and thus "more correct" than the default implementation.
>
> 2) Remove the default implementation of rnf. I understand the default
> implementation gives some convenience when writing instances for types
> that have an all strict representation, as in:
>
> instance NFData Int
> instance NFData Word
> instance NFData Integer
> ...
>
> However, I think having the default implementation can mask some bugs as in:
> data T = C Int; instance NFData T
> which will neither give a compile time error nor warning.
>
> I don't think it's that much more inconvenient to write:
>
> instance NFData Int where rnf = rnf'
> instance NFData Word where rnf = rnf'
> instance NFData Integer where rnf = rnf'
> ...
> where
> rnf' :: a -> ()
> rnf' a = a `seq` ()
>
> So I would vote for option 2, removing the default rnf implementation.
> If I find some time I will turn this into an official proposal.
I agree it would have been nice to have that functionality directly in
the deepseq package, or at least in a way that extends the existing
functionality rather than completely replace it. However, as you noted,
it isn't possible to do that in a backwards compatible way, unless we
hack the implementation of the DefaultSignatures extension. That being
said, even if it was possible to do this in a backwards compatible way,
I'm not entirely sure it would be desirable to do so because there is
one subtle difference between this code and the deepseq package.
With the generic-deepseq package, you should only need to provide an
explicit DeepSeq instance for some type if it is abstract, because you
can't get a Generic instance in that case (unless the library author
derived Generic himself, but that would be a weird and dangerous thing
to do for an abstract datatype). If you're not dealing with an abstract
datatype, you _shouldn't_ have an explicit instance, because it would be
possible to write an incorrect one, while that is impossible if you just
derive a generic implementation (as long as the generic code is correct,
of course).
So, knowing that it would necessarily be backwards incompatible (I
wasn't intending to hack on GHC :-), and also that, in the end, this is
not quite the same class as the NFData class from the deepseq package, I
thought it made more sense to create another package that would be
mostly compatible with deepseq, but with a different class name so as to
force people to reevaluate the need for their instances if they have
some. I'd be interested in knowing what you and others think about that.
Maybe I'm being overly cautious?
I kept the rest of the API identical so that it's still easy to switch
to this package, thus you can still use the ($!!), force, and rnf
functions. I'm guilty of not having preserved the "rnf :: a -> ()"
function as the class function though, it's a wrapper around "deepseq"
in my code. I just didn't see the point of having a class function with
such a signature versus having a function just like "seq :: a -> b ->
b". In retrospect, that might have been a bad idea, and maybe I should
switch to have an "rnf :: a -> ()" class function to make switching even
easier?
Thanks a lot for your input!
Maxime Henrion
signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: generic-deepseq 1.0.0.0
On 19 February 2012 13:12, Maxime Henrion wrote:
> Any suggestions are welcome.
Nice work but it would be nice to have this functionality directly in
the deepseq package as in:
#ifdef GENERICS
{-# LANGUAGE DefaultSignatures, TypeOperators, FlexibleContexts #-}
#endif
class NFData a where
rnf :: a -> ()
rnf a = a `seq` ()
#ifdef GENERICS
default rnf :: (Generic a, GNFData (Rep a)) => a -> ()
rnf = grnf . from
class GNFData f where
grnf :: f a -> ()
instance GNFData U1 where
grnf U1 = ()
{-# INLINE grnf #-}
instance NFData a => GNFData (K1 i a) where
grnf = rnf . unK1
{-# INLINE grnf #-}
instance GNFData f => GNFData (M1 i c f) where
grnf = grnf . unM1
{-# INLINE grnf #-}
instance (GNFData f, GNFData g) => GNFData (f :+: g) where
grnf (L1 x) = grnf x
grnf (R1 x) = grnf x
{-# INLINE grnf #-}
instance (GNFData f, GNFData g) => GNFData (f :*: g) where
grnf (x :*: y) = grnf x `seq` grnf y
{-# INLINE grnf #-}
#endif
Unfortunately this is not possible since the two default
implementations conflict. I see two solutions:
1) Change the DefaultSignatures extension to always give preference to
the default signature. I think giving preference to the default
signature makes sense since it's usually more specific (more
constraint) and thus "more correct" than the default implementation.
2) Remove the default implementation of rnf. I understand the default
implementation gives some convenience when writing instances for types
that have an all strict representation, as in:
instance NFData Int
instance NFData Word
instance NFData Integer
...
However, I think having the default implementation can mask some bugs as in:
data T = C Int; instance NFData T
which will neither give a compile time error nor warning.
I don't think it's that much more inconvenient to write:
instance NFData Int where rnf = rnf'
instance NFData Word where rnf = rnf'
instance NFData Integer where rnf = rnf'
...
where
rnf' :: a -> ()
rnf' a = a `seq` ()
So I would vote for option 2, removing the default rnf implementation.
If I find some time I will turn this into an official proposal.
Regards,
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Failing to find a function
Erik Hesselink writes: > On Sun, Feb 19, 2012 at 12:50, Jon Fairbairn > wrote: >> This is probably a failure of my search fu or some other mental >> lacuna, but is there already a definition of this function >> somewhere: >> \a b -> runKleisli $ (Kleisli a) <+> Kleisli b >> ? > Not a single name, but I believe > > liftA2 mplus > > is the same function, and much shorter (and more general). That’s the ticket. I was sure there was something like that (and I almost asked if there was a library function g such that g mplus = …). Thanks, — Jón ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: generic-deepseq 1.0.0.0
Hello all, Yesterday I uploaded a new package on Hackage called generic-deepseq. It implements the 'deepseq' function generically using the new GHC.Generics framework as found in GHC >= 7.2. It can be used as a replacement for the deepseq package. Given that hackage is currently down, here is an URL from a mirror where the package description & documentation can be found: http://hackage.factisresearch.com/package/generic-deepseq-1.0.0.0 Any suggestions are welcome. Cheers, Maxime Henrion signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Failing to find a function
Isn't that just something like liftA2 mplus? Отправлено с iPhone Feb 19, 2012, в 15:50, Jon Fairbairn написал(а): > > This is probably a failure of my search fu or some other mental > lacuna, but is there already a definition of this function > somewhere: > > \a b -> runKleisli $ (Kleisli a) <+> Kleisli b > ? > > Hoogling for its type > > MonadPlus m => (a -> m b) -> (a -> m b) -> a -> m b > > doesn’t net me anything useful. > > -- > Jón Fairbairn jon.fairba...@cl.cam.ac.uk > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Failing to find a function
Not a single name, but I believe liftA2 mplus is the same function, and much shorter (and more general). It uses the Applicative instance for (a ->). Of course, it also works with liftM2. Erik On Sun, Feb 19, 2012 at 12:50, Jon Fairbairn wrote: > > This is probably a failure of my search fu or some other mental > lacuna, but is there already a definition of this function > somewhere: > > \a b -> runKleisli $ (Kleisli a) <+> Kleisli b > ? > > Hoogling for its type > > MonadPlus m => (a -> m b) -> (a -> m b) -> a -> m b > > doesn’t net me anything useful. > > -- > Jón Fairbairn jon.fairba...@cl.cam.ac.uk > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Failing to find a function
This is probably a failure of my search fu or some other mental lacuna, but is there already a definition of this function somewhere: \a b -> runKleisli $ (Kleisli a) <+> Kleisli b ? Hoogling for its type MonadPlus m => (a -> m b) -> (a -> m b) -> a -> m b doesn’t net me anything useful. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] "Best" FRP package for newbie
edgar klerks wrote: As beginner I really liked reactive-banana. I used it in a inhouse project for the graphical user interface (wx) and I found it easier to use than the "imperative" approach. Unfortunately the reactive-banana-wx package seems to be broken on 7.2. Actually, it's a weird bug in GHC 7.2 that break reactive-banana-wx. Watching the build log on Hackage is fun: sometimes it doesn't build, then it does build, then not. Fortunately, everything works fine on GHC 7.0.4 . Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
