News aggregator

Proposal: Change the signature of mkWeakMVar

libraries list - Fri, 11/07/2014 - 6:16pm
We've had a ticket languishing in the trac for a couple of years that probably belongs as a libraries proposal: To summarize it here: In base 4.6 addMVarFinalizer is deprecated in favour of mkWeakMVar of type mkWeakMVar :: MVar a -> IO () -> IO (Weak (MVar a)) This type makes it inherently non-compositional. For instance, if we have a larger datatype T that contains an MVar somewhere inside then there in no way to define mkWeakT in terms of mkWeakMVar; instead, mkWeakT would have to be defined along the lines of mkWeakT :: T a -> IO () -> IO (Weak (T a)) mkWeakT m< at >(MkT (MVar m#) _) f = IO $ \s -> case mkWeak# m# m f s of (# s1, w #) -> (# s1, Weak w #) It would be better if the type of mkWeakMVar would change to mkWeakMVar :: MVar a -> v -> Maybe (IO ()) -> IO (Weak v) (i.e., following mkWeak rather than mkWeakPtr). (The same comment goes for related functions such as mkWeakIORef.) I'm personally in favor of the change,
Categories: Offsite Discussion

cabal keeps relinking

haskell-cafe - Fri, 11/07/2014 - 5:35pm
Dear Haskell-Cafe, cabal seems to be re-linking every time I run cabal build Wait was not an issue for small projects but for big ones it is starting to get in the way… How could I persuade cabal to re-link only if there are changes in the source tree and only these exes that require it? Many thanks, Semen PS I googled around and found this which seems to imply relink is (was?) conditional on multiple exes being present in the project. However, for me it was always relinking regardless.
Categories: Offsite Discussion access problems

haskell-cafe - Fri, 11/07/2014 - 4:09pm
L.S., When I try to browse with Opera, I get the following message: --- Unable to complete secure transaction You tried to access the address, which is currently unavailable. Please make sure that the web address (URL) is correctly spelled and punctuated, then try reloading the page. Secure connection: fatal error (1066) Unable to verify the website's identity (OCSP error). The response from the online certificate validation (OCSP) server was too old. --- The browser doesn't allow me in. Another thing that I get with Firefox: a captcha, probably because I am using the TOR network and the site is buffered by CloudFlare. Opera does not handle these captchas properly. Regards, Henk-Jan van Tuyl
Categories: Offsite Discussion

The GHC Team: GHC Weekly News - 2014/11/07

Planet Haskell - Fri, 11/07/2014 - 3:55pm

Hello *,

It's that time again, so get ready for some good ol' fashion news about your favorite compiler.

And this weeks closed tickets include quite a long list, thanks to everyone cleaning up the bug tracker: #9747, #9236, #9753, #9752, #9262, #8953, #9084, #9738, #8571, #8295, #8261, #9754, #110, #9345, #8849, #8819, #9658, #8960, #9395, #9705, #9433, #9633, #9359, #9081, #8482, #3376, #9712, #9739, #9211, #9728, #9750, #9768, #9773, #9741, #9284, #9774, #9771, #9001, #8626, #8986, #9268, #8975, #8962, #8921, #8089, #8843, #8829, #9295, #7913, #2528, #9779.

Categories: Offsite Blogs

What are examples of optimizations supercompilation achieve, that transducer composition can't?

Haskell on Reddit - Fri, 11/07/2014 - 1:04pm

Tree transducer composition can cut every intermediate structure when combining multiple functions. It, thus, can generalize many optimization techniques by itself, including stream fusion. Supercompilation, too, can generalize a wide range of optimizations by itself, including the fusion. My question is: what exactly are the cases where supercompilation achieves optimizations that transducer composition can't?

submitted by SrPeixinho
[link] [31 comments]
Categories: Incoming News

Bill Atkins: NSNotificationCenter, Swift and blocks

Planet Haskell - Fri, 11/07/2014 - 11:52am
The conventional way to register observers with NSNotificationCenter is to use the target-action pattern. While this gets the job done, it's inherently not type-safe.

For example, the following Swift snippet will compile perfectly:

    NSNotificationCenter.defaultCenter().addObserver(self, selector: Selector("itemAdded:"),      name: MyNotificationItemAdded, object: nil)
even though at runtime it will fail unless self has a method named itemAdded that takes exactly one parameter (leaving off that last colon in the selector will turn this line into a no-op). Plus, this method gives you no way to take advantages of Swift's closures, which would allow the observer to access local variables in the method that adds the observer and would eliminate the need to create a dedicated method to handle the event.
A better way to do this is to use blocks. And NSNotificationCenter does include a block-based API:
    NSNotificationCenter.defaultCenter().addObserverForName(MyNotificationItemAdded, object: nil, queue: nil) { note in      // ...    }
This is much nicer, especially with Swift's trailing closure syntax. There are no method names to be looked up at runtime, we can refer to local variables in the method that registered the observer and we can perform small bits of logic in reaction to events without having to create and name dedicated methods.
The catch comes in resource management. It's very important that an object remove its event observers when it's deallocated, or else NSNotificationCenter will try to invoke methods on invalid pointers.
The traditional target-action method has the one advantage that we can easily handle this requirement with a single call in deinit:
  deinit {    NSNotificationCenter.defaultCenter().removeObserver(self)  }
With the block API, however, since there is no explicit target object, each call to addObserverForName returns "an opaque object to act as observer." So your observer class would need to track all of these objects and then remove them all from the notification center in deinit, which is a pain.
In fact, the hassle of having to do bookkeeping on the observer objects almost cancels out the convenience of using the block API. Frustrated by this situation, I sat down and created a simple helper class, NotificationManager:
class NotificationManager {  private var observerTokens: [AnyObject] = []
  deinit {    deregisterAll()  }
  func deregisterAll() {    for token in observerTokens {      NSNotificationCenter.defaultCenter().removeObserver(token)    }
    observerTokens = []  }
  func registerObserver(name: String!, block: (NSNotification! -> Void)) {    let newToken = NSNotificationCenter.defaultCenter().addObserverForName(name, object: nil, queue: nil) {note in      block(note)    }
    observerTokens.append(newToken)  }    func registerObserver(name: String!, forObject object: AnyObject!, block: (NSNotification! -> Void)) {    let newToken = NSNotificationCenter.defaultCenter().addObserverForName(name, object: object, queue: nil) {note in      block(note)    }        observerTokens.append(newToken)  }}
First, this simple class provides a Swift-specialized API around NSNotificationCenter.  It provides an additional convenience method without an object parameter (rarely used, in my experience) to make it easier to use trailing-closure syntax. But most importantly, it keeps track of the observer objects generated when observers are registered, and removes them when the object is deinit'd.

A client of this class can simply keep a member variable of type NotificationManager and use it to register its observers. When the parent class is deallocated, the deinit method will automatically be called on its NotificationManager member variable, and its observers will be properly disposed of:

class MyController: UIViewController {  private let notificationManager = NotificationManager()    override init() {    notificationManager.registerObserver(MyNotificationItemAdded) { note in      println("item added!")    }        super.init()  }    required init(coder: NSCoder) {    fatalError("decoding not implemented")  }}
When the MyController instance is deallocated, its NotificationManager member variable will be automatically deallocated, triggering the call to deregisterAll that will remove the dead objects from NSNotificationCenter.
In my apps, I add a notificationManager instance to my common UIViewController base class so I don't have to explicitly declare the member variable in all of my controller subclasses.

Another benefit of using my own wrapper around NSNotificationCenter is that I can add useful functionality, like group observers: an observer that's triggered when any one of a group of notifications are posted:

struct NotificationGroup {  let entries: [String]    init(_ newEntries: String...) {    entries = newEntries  }
extension NotificationManager {  func registerGroupObserver(group: NotificationGroup, block: (NSNotification! -> ()?)) {    for name in group.entries {      registerObserver(name, block: block)    }  }}
This can be a great way to easily set up an event handler to run when, for example, an item is changed in any way at all:
   let MyNotificationItemsChanged = NotificationGroup(      MyNotificationItemAdded,      MyNotificationItemDeleted,      MyNotificationItemMoved,      MyNotificationItemEdited    )
    notificationManager.registerGroupObserver(MyNotificationItemsChanged) { note in      // ...    }
Categories: Offsite Blogs

Does this typeclass already have a name?

Haskell on Reddit - Fri, 11/07/2014 - 8:53am

I have a datatype parameterized by a c, and for the core operations, I really only need c to be to be a Category. However, for some of the extended operations on that data type, I needed to convert values of c a b to functions w a -> m b for some w and m.

So I defined this typeclass to describe the cs that I could run these operations on:

class Functionish c where type Src c :: * -> * type Dst c :: * -> * run :: c a b -> Src c a -> Dst c b

Some example instances:

data Identity a = Identity { runIdentity :: a } deriving Functor class Functionish (->) where type Src (->) = Identity type Dst (->) = Identity run = fmap data Kleisli m a b = Kleisli { runKleisli :: a -> m b } class Functionish (Kleisli m) where type Src (Kleisli m) = Identity type Dst (Kleisli m) = m run c = runKleisli c . runIdentity data Cokleisli w a b = Cokleisli { runCokleisli :: w a -> b } class Functionish (Cokleisli w) where type Src (Cokleisli w) = w type Dst (Cokleisli w) = Identity run c = Identity . runCokleisli c data Isomorphism a b = Isomorphism { runForwards :: a -> b, runBackwards :: b -> a } class Functionish Isomorphism where type Src Isomorphism = Identity type Dst Isomorphism = Identity run = fmap . runForwards data Dual k a b = Dual { runDual :: k b a } class Functionish (Dual Isomorphism) where type Src (Dual Isomorphism) = Identity type Dst (Dual Isomorphism) = Identity run = fmap . runBackwards . runDual

In general though, not all Category instances can be Functionish (e.g. Dual (->)), nor are all Functionish instances necessarily categories.

Is there an existing name for this typeclass, or a name I can steal for it from type theory?

submitted by rampion
[link] [18 comments]
Categories: Incoming News - Fri, 11/07/2014 - 5:40am
Categories: Offsite Blogs

Discussion: remove the Applicative superclass from Alternative

libraries list - Fri, 11/07/2014 - 3:36am
Currently, Applicative is a superclass of Alternative. Unfortunately, the *only* laws for Alternative are the monoid laws. Sensible sets of laws have been proposed in the past, but unfortunately *none* of them cover all the current important instances. Thus we have a rather awkward situation where Alternative is a subclass of Applicative, but there's no real way to take advantage of that fact. There are essentially no useful functions that would end up with signatures that look like p :: (Applicative f, Alternative f) => ... I'm wondering, therefore, what people think of the idea of making Alternative entirely independent—just a version of Monoid with a different kind. class Alternative f where empty :: f a (<|>) :: f a -> f a -> f a A second option would be to go with a Functor superclass for Alternative; that might save some typing over the independent Alternative, and it comes with the free theorem fmap f empty = empty _______________________________________________ Libraries mailing list Libra
Categories: Offsite Discussion

The Type-Checker's Prayer

Haskell on Reddit - Fri, 11/07/2014 - 3:28am
Categories: Incoming News - Fri, 11/07/2014 - 12:45am
Categories: Offsite Blogs - Fri, 11/07/2014 - 12:45am
Categories: Offsite Blogs