Absolutely this. And when you look through the bug history of those low-level APIs there's a lot of evidence.
That said, the other big difference with Haskell is the low-level API actually provides functionality to solve the exact problem of an async exception being raised anywhere via `mask`. It's still hard to use correctly but at least it's possible.
If most applications don't satisfy soft real time requirements either, then maybe those requirements aren't really important for most cases.
There's only one industrial Haskell codebase I've worked on, and although parts of it were very procedural, that was probably less than half the codebase, even including the IO-bound code. Sure it's one way to use the language, but it's certainly not the only one.
It's hard to build systems with hard real-time requirements with GHC Haskell.
The vast majority of systems people build do not have hard real-time requirements. People have built video games, real-time audio, and all sorts of other soft-real-time systems with Haskell
You completely missed the point of my comment. The wording describes a specific instance. And additionally, the rhetorical convention implies that there is no instance of the problem for which the description doesn't hold. This part is unwritten; the reader is meant to apply it from context.
It seems like this is why there's a big disagreement about this particular write-up. Some people are applying this additional constraint, and others (yourself) aren't.
If you counter that this constraint isn't written, and therefore it shouldn't apply, I'm sorry but you're wrong. The author clearly intended it.
I think you're reading the description incorrectly. It is not meant to be a specific instance that may happen differently for other instances. "You" is an abstraction over all players of the game show, there's an implicit "forall you:" in front of the sentence.
I agree that this is not as precisely stated as it could be. And unfortunately there's a type of logic puzzle that relies on people understanding these implicit quantifiers and being prepared to ignore them, which sometimes makes it hard to determine if they're supposed to be assumed present or not. But the most common interpretation is to include it.
Have you seen BNFC (http://bnfc.digitalgrammars.com/)? I've used it with the Haskell bindings and really appreciated it. Parser, pretty-printer, and AST skeleton all auto-generated. I've only used it with Haskell though, can't speak to the other languages.
The financials aren't publicly available, but I'd expect PE firms still made money here. The funds probably lost money, but funds are an investment vehicle separate from the managing entity.
I disagree that profitable businesses can continue no matter the capital structure. You're assuming that there's a liquid market for businesses, or parts of them. For a huge retailer that's almost certainly not true. Additionally, the current owners have to actually want the business to continue. I would believe there's more value to a short-term owner in liquidating assets than accruing profits over a relatively short timeframe.
The PE fund's capital is partly other people's money too. In particular, fund limited partners (the fund investors) put up most of the initial money. The PE firm itself also puts in money but not nearly that much. This makes it easier for the fund managers to make a profit themselves quickly, even if the fund investors end up losing.
You're missing the key piece: Toys R Us didn't go into debt for any good business reason, it was bought by a private equity firm and loaded with debt it didn't need. This is how private equity works:
1. A PE firm uses a combination of other people's money (limited partners a.k.a investors) and debt to buy a company.
2. The PE transfers the debt to the company's books. This way, if the company goes bankrupt the PE fund isn't liable for that debt.
3. The PE firm charges millions of dollars in fees for providing management services. This way the PE firm makes money regardless what happens to the business.
Toys R Us was profitable before it was bought and saddled with debt that was essentially used to purchase it's own business.
Some resources are scarce, but food in the U.S. is not. We have allocation and distribution issues, with political choices as a major factor, not supply constraints.
You're claiming that 40% of their total earnings are lost to federal tax? In this example, what types and how much income are you proposing? Doesn't seem realistic to me.
No, Britain will have a very poor position in the negotiations that follow regardless. That's why the E.U. is insisting on the payments and citizen's rights issues being resolved first: they want a British commitment to items the E.U. cares about without having to make any concessions. If you think the E.U. will go back and renegotiate, or take British payments into account at later stages of negotiation, you're as delusional as May.
I hate to admit it, but May and Davis should absolutely refuse to play ball. They should agree to terms they think are fair here, and if the E.U. doesn't go along, prepare for a really hard brexit. Which of course means that they'll capitulate.
They were charged and pled, that doesn't necessarily mean fraud was actually committed. DAs have wide latitude when charging people with crimes. If you were a foreign national caught doing this, would you want to take a chance with a jury or bench trial in a hostile (to you) jurisdiction?
I surely don't know as much as simonmar about this, but I think this is a rhetorical shortcut. My understanding is that when a Haskell thread receiving the exception needs to allocate on the heap, the executing context will instead raise the exception.
As for why it's not a side effect, in Haskell all exceptions are considered to be bottom, the value that inhabits every type. Thus an exception can be raised anywhere and have any type. They can only be handled in IO though.
That said, the other big difference with Haskell is the low-level API actually provides functionality to solve the exact problem of an async exception being raised anywhere via `mask`. It's still hard to use correctly but at least it's possible.