Re: [Haskell-cafe] What library package fulfills these requirements?
Thanks for the link. I enjoyed it. It is quite a different approach as Simon had in the presentation I mentioned. Gives me food for thought, which is good. -- View this message in context: http://haskell.1045720.n5.nabble.com/What-library-package-fulfills-these-requirements-tp4945125p4948604.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] control-c only caught once -- bug?
brianjohnsonhaskellc...@gmail.com wrote: The second time I press control-c, it isn't caught -- the program exits instead. Why? I don't know why. Same behavior on my platform (Haiku.) While I imagine someone intimately acquainted with RTS signal handling might be able to explain it, I think the real problem is that Control.Exception.Catch isn't a real signal handler. For example, your program doesn't catch SIGHUP, or SIGALRM, or probably anything but SIGINT. The SIGINT handler looks like more of a quirk of the RTS, than a feature whose behavior you should depend on in great detail. I can use System.Posix.Signals.installHandler to catch ctrlC (SIGINT) in a repeatable way, on MacOS X, so that's working as it should. If you want it to return control to the user interface, that's going to take some work - for all I know, there may be some way to hook a signal handler up with Control.Exception.catch. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] control-c only caught once -- bug?
On Sat, Oct 29, 2011 at 9:36 AM, Donn Cave d...@avvanta.com wrote: The SIGINT handler looks like more of a quirk of the RTS, than a feature whose behavior you should depend on in great detail. I looked into this some more, and found that it is indeed a quirk of the RTS -- an apparently /intentional/ one. From http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals: When the interrupt signal is received, the default behaviour of the runtime is to attempt to shut down the Haskell program gracefully. It does this by calling interruptStgRts() in rts/Schedule.chttp://hackage.haskell.org/trac/ghc/browser/rts/Schedule.c (see Commentary/Rts/Scheduler#ShuttingDownhttp://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Scheduler#ShuttingDown). If a second interrupt signal is received, then we terminate the process immediately; this is just in case the normal shutdown procedure failed or hung for some reason, the user is always able to stop the process with two control-C keystrokes While I'm sure someone or ones meant well when designing the RTS to work in this way, I do not agree that this is sensible. It's fine for calculation or utility programs that perform one task and exit, but not for interactive programs such as shells, editors, or anything with a command line interface. IMO, handholding behavior such as this is exactly the sort of thing that risks new Haskell users coming to the conclusion that Haskell is not intended for real programming projects -- I know, because I nearly came to this exact conclusion while pulling my hair out trying to figure out what was going on here. Further complicating the matter is that this feature only exists in POSIX environments, i.e. not on Windows. I can use System.Posix.Signals.installHandler to catch ctrlC (SIGINT) in a repeatable way, on MacOS X, so that's working as it should. If you want it to return control to the user interface, that's going to take some work - for all I know, there may be some way to hook a signal handler up with Control.Exception.catch. Indeed, it's easy to hook up your own signal handler so that ALL keyboard interrupts have the expected behavior of throwing a UserInterrupt exception -- although I would not have thought to do this before learning that the RTS is broken in this regard: import Control.Exception as C import Control.Concurrent import System.Posix.Signals main = do tid - myThreadId installHandler keyboardSignal (Catch (throwTo tid UserInterrupt)) Nothing ... -- rest of program Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] control-c only caught once -- bug?
On Sat, Oct 29, 2011 at 12:18 PM, Brian Johnson brianjohnsonhaskellc...@gmail.com wrote: From http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals: When the interrupt signal is received, the default behaviour of the runtime is to attempt to shut down the Haskell program gracefully. It does this by calling interruptStgRts() in rts/Schedule.chttp://hackage.haskell.org/trac/ghc/browser/rts/Schedule.c (see Commentary/Rts/Scheduler#ShuttingDownhttp://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Scheduler#ShuttingDown). If a second interrupt signal is received, then we terminate the process immediately; this is just in case the normal shutdown procedure failed or hung for some reason, the user is always able to stop the process with two control-C keystrokes On further thought, there is something sensible here: the RTS might crash while trying to exit. I propose, for POSIX environments, the following change to SIGINT handling: * SIGINT is transformed into UserInterrupt during normal program execution * Once the RTS is committed to exiting, it resets the signal handler for SIGINT so that any additional control-c causes an immediate exit Makes sense? Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What library package fulfills these requirements?
This is great stuff. I specifically like the interaction part. Hands on experience, whilst skipping the wow-stuff (well, I will mention the possibilities, supplying some links, but no more than a couple of minutes.). And as side effect I now have to get acquainted to github. Like it. Thanks a lot! -- View this message in context: http://haskell.1045720.n5.nabble.com/What-library-package-fulfills-these-requirements-tp4945125p4949311.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] is Haskell missing a non-instantiating polymorphic case?
On 2011-10-24 00:18:45 -0700, Heinrich Apfelmus said:
Actually, polymorphism is not implicit in System F,
Of course; take a look at the explicit type-application {|t|} in the
second link I posted.
On 2011-10-24 00:18:45 -0700, Heinrich Apfelmus said:
With this in mind, it's clear that you can't write your example; it
would look like this:
hard :: ∀n.Maybe (f n) - Maybe (∀n.f n)
hard f = case f n of -- n is not in scope
Nothing - Nothing
Just x - Just (Λn.x) -- n bound here
I certainly agree that the program you've written won't work -- but
unfortunately that's not the same thing as proving it can't be written!
Of course, parametricity tells you that that the function f is actually
constant in a certain sense. But to my knowledge, there is no way to
make this knowledge internal to System F.
Indeed, this is precisely the sense in which I believe it is missing.
Thanks for your comments!
- a
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] control-c only caught once -- bug?
An interactive program that wants to handle interrupt itself should not rely on default signal behavior, because that has no idea where to stop (and I would argue that attempting to coerce interactive signals into exceptions within the program is not the right way to do things, because they're only superficially similar and oddities like this are the result). If you want to handle signals, handle signals; don't rely on exceptions to do it for you. Using the POSIX model, signals are blocked until the handler either returns or modifies the signal mask explicitly; this prevents a race condition which in this case could happen when a program is running slowly due to some other process slowing the machine down, which could lead to a second SIGINT aborting the program before the program could handle it. (This used to be common on ATT/v7-derived Unixes which didn't have signal blocking, and is why POSIX adopted the BSD-derived signal model.) If you try to map signals to exceptions, you can't make them behave like an exception (where a second one, received while in the exception handler, is thrown immediately to the outer scope) without losing the ability to handle that signal inside the exception handler (due to the race condition above). (I have a feeling I'm not describing this clearly enough; I'm a bit fuzzy due to not having caught up on sleep fully yet.) Possibly the way to do a higher level signal handler is something similar to catch: computation `withSignal` $ \sig - handler where, unlike catch, the signal is blocked until handler finishes unless explicitly unblocked (thus behaving like POSIX signal handlers and avoiding the race condition). (And then comes the question of how, if at all, any of this applies to Windows, which I'm unqualified to answer.) -- 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] Package documentation complaints -- and a suggestion
On 10/25/11 3:54 AM, Gregory Collins wrote: On Tue, Oct 25, 2011 at 4:34 AM, wren ng thorntonw...@freegeek.org wrote: I'm not so sure about that exemption. The experimental stability level seems to be the norm on Hackage and often means I use this for real projects, but because I use it for real projects I'm not quite willing to hammer the API in stone just yet. ... Before dealing with automatic documentation requirements, perhaps it'd be better to develop a standard consensus on the terms used in the stability field and actively advocating for people to adopt it, as was done with the PVP. I think there's no need to cajole people into it -- if Hackage 2 puts stable packages on a different / better list, there's your social pressure. Right now the stability flag in the .cabal file, as you pointed out, is almost completely content-free. The problem isn't social pressure to be stable, it's the ambiguity of what stable means. If Hackage 2 institutes a policy whereby things claiming to be stable are treated better, then stable is likely to become the new experimental. Just because I call something stable doesn't mean that it is. Just because I give something enough documentation so appease the bots so that I'm allowed to call it stable doesn't mean that it is. Frankly, giving a one-line synopsis of what a function does isn't a high enough barrier to entry to keep someone from abusing the system in order to self-select which index page they get put on. The only way to get a consensus about what stable, experimental, etc mean is ...to get a consensus about what they mean. It's exactly the same thing as the PVP: in order to get people to agree about what version increments mean, we need to get them to agree to mean whatever it is everybody else thinks they mean. Automating the verification of that agreement is a nice tool to have to hand, but it's meaningless without the agreement about what we're all engaged in. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] MonadPlus versus Alternative
Hey everyone, What is the difference between MonadPlus and Alternative? In my mind, it would make sense for the difference to be that the former provides and semantics (i.e., x `mplus` y means do both x and y) whereas the latter provides or semantics (i.e., x | y means do x or y but not both). However, when I look at the instances defined for List I see that it is exactly the same as MonadPlus. So is there any difference between the interpretation of MonadPlus and Alternative, or is the only difference between them that the former applies to Monad whereas the latter applies to Applicative? Also, along similar lines, why does MonadPlus exist when it is essentially just a special case of Monoid? (That is, any MonadPlus instance could be equivalently cast as a Monoid instance.) Thanks! Greg___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MonadPlus versus Alternative
MonadPlus is `or` semantics, as is Alternative. It does, indeed, reflect the Applicative/Monad difference. On Sat, Oct 29, 2011 at 8:02 PM, Gregory Crosswhite gcrosswh...@gmail.comwrote: Hey everyone, What is the difference between MonadPlus and Alternative? In my mind, it would make sense for the difference to be that the former provides and semantics (i.e., x `mplus` y means do both x and y) whereas the latter provides or semantics (i.e., x | y means do x or y but not both). However, when I look at the instances defined for List I see that it is exactly the same as MonadPlus. So is there any difference between the interpretation of MonadPlus and Alternative, or is the only difference between them that the former applies to Monad whereas the latter applies to Applicative? Also, along similar lines, why does MonadPlus exist when it is essentially just a special case of Monoid? (That is, any MonadPlus instance could be equivalently cast as a Monoid instance.) Thanks! Greg ___ 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
