Logs: freenode/#haskell
| 2020-10-09 00:29:25 | <spinnylights> | i might be the voice against the choir here a bit but i think the relative vagueness of the c standard is reasonable :P c code needs to compile for a huge variety of different hardware with widely varying characteristics, and if the standard was too specific it would cut certain platforms out |
| 2020-10-09 00:29:41 | <dolio> | Yeah, the person a few days ago was lamenting the Haskell report saying "you should expect a reasonable graph reduction algorithm" or something. But the C spec is full of those kind of 'reasonable expectation' things that don't technically hold force. |
| 2020-10-09 00:29:47 | <koz_> | spinnylights: Yeah, but the POSIX standard is _much_ more restrictive and somehow nobody's died yet. |
| 2020-10-09 00:30:10 | <koz_> | Back the 80s it was an architectural wild west. |
| 2020-10-09 00:30:11 | <spinnylights> | yes but POSIX-compliant operating systems don't run on as wide a variety of hardware as any given c code |
| 2020-10-09 00:30:13 | <koz_> | Implementational too. |
| 2020-10-09 00:30:21 | <koz_> | Nowadays it's _way_ more convergent. |
| 2020-10-09 00:30:29 | → | nineonine joins (~nineonine@216-19-190-182.dyn.novuscom.net) |
| 2020-10-09 00:30:52 | <koz_> | dolio: The only reasonable expectation one can have vis a vis C is that you're invoking UB. |
| 2020-10-09 00:31:08 | <koz_> | Since there's like, over 100 sources of UB, some of which are highly surprising and almost impossible to guard against. |
| 2020-10-09 00:31:28 | <koz_> | (I've been bitten by a few, and I do not see how you can possibly ensure you don't violate them in general) |
| 2020-10-09 00:31:34 | <spinnylights> | people write c to control factory equipment, small appliances, etc. etc.—if you look at the implementation for the specific hardware you're targeting it's generally much more precise about its behavior than the standard is |
| 2020-10-09 00:31:37 | × | psygate quits (~psygate@unaffiliated/psygate) (Ping timeout: 272 seconds) |
| 2020-10-09 00:32:04 | <spinnylights> | i think that's basically by design |
| 2020-10-09 00:32:40 | <koz_> | spinnylights: And I believe said design is absolutely bonkers. The way the standard defines 'portability' translates to 'compiler writers should have the easiest job defining conformant implementations'. |
| 2020-10-09 00:32:51 | <koz_> | Which I argue is literally not how _anyone_ else views 'portability'. |
| 2020-10-09 00:33:22 | <dolio> | I have no real beef with the C standard. But the context was a claim that the standard was/needed to be precise, not the implementation. |
| 2020-10-09 00:34:10 | <dolio> | I mean, the implementation needs to be precise, of course, but that that isn't good enough. |
| 2020-10-09 00:34:18 | <spinnylights> | i don't think portability is as high a priority for c as it is for c++, in the sense that you mean; a lot of the places where c is used, the alternative would be some assembly language, and it's being used for ease of programming, not portability |
| 2020-10-09 00:34:55 | <spinnylights> | c code like that might be portable over some specific class of hardware but it's not usually meant to even run on PCs |
| 2020-10-09 00:34:58 | <koz_> | spinnylights: Then what's the point of the standard? |
| 2020-10-09 00:35:18 | <spinnylights> | if you _do_ need to write portable c code, it's there for you |
| 2020-10-09 00:35:18 | × | nineonine quits (~nineonine@216-19-190-182.dyn.novuscom.net) (Ping timeout: 260 seconds) |
| 2020-10-09 00:35:31 | <spinnylights> | it's good to be able to know what's portable and what's implementation-specific |
| 2020-10-09 00:35:43 | <spinnylights> | plus, without it compiler writers wouldn't know what to do :P |
| 2020-10-09 00:35:51 | <koz_> | Which translates essentially to 'essentially nothing' and 'essentially everything'. |
| 2020-10-09 00:36:07 | <koz_> | And I _really_ question the last assertion, considering that most languages lack anything like a standard and their authors seem to be just fine. |
| 2020-10-09 00:36:13 | → | shatriff joins (~vitaliish@78.111.190.16) |
| 2020-10-09 00:36:21 | <koz_> | Or certainly no worse than the authors of compilers for 'standardized' languages. |
| 2020-10-09 00:36:35 | <spinnylights> | well not literally nothing or everything :P i kind of wish that was the case, it might be easier to make a good FFI |
| 2020-10-09 00:36:58 | <koz_> | spinnylights: 'Almost nothing', much like 'almost everything' is almost useless as a claim of anything. |
| 2020-10-09 00:37:00 | <dolio> | I was surprised by the scheme 'proper tail recursion' spec, too. |
| 2020-10-09 00:37:12 | <koz_> | dolio: Yeah, unlike Common Lisp. |
| 2020-10-09 00:37:16 | <dolio> | It's more vague than I'd heard. |
| 2020-10-09 00:37:22 | <spinnylights> | those are not the same kinds of languages :P i doubt those languages are widely used in the embedded world |
| 2020-10-09 00:37:45 | <monochrom> | Ah, atomicModifyIORef includes memory barrier, I didn't notice that. |
| 2020-10-09 00:37:47 | × | xerox_ quits (~xerox@unaffiliated/xerox) (Ping timeout: 240 seconds) |
| 2020-10-09 00:37:52 | <spinnylights> | maybe you have a good counterexample but it would be surprising to me |
| 2020-10-09 00:37:53 | <koz_> | spinnylights: Perhaps, but being the _only_ option does not imply being the _best_ option. It's a grubby world nobody wants to grub around in. |
| 2020-10-09 00:38:15 | <koz_> | So there's no other options because nobody wants to write languages for that space, not because C is somehow good there. |
| 2020-10-09 00:38:18 | <spinnylights> | well sure :P i don't think c is too many people's favorite language in the world or anything, but the constraints on its design are really severe |
| 2020-10-09 00:39:08 | <spinnylights> | a language like c++ or rust could theoretically take its place but they require much bulkier, harder-to-implement compilers |
| 2020-10-09 00:39:38 | <koz_> | C++ does so because it's the clown car of proglangs and must include literally everything. Except garbage collection because it's badwrongfun somehow. |
| 2020-10-09 00:39:52 | → | emmanuel_erc joins (~user@2604:2000:1382:ce03:ddc4:166d:60ea:ae29) |
| 2020-10-09 00:39:54 | <spinnylights> | writing a c compiler is relatively easy by comparison, which is nice if your language is meant to support a wide variety of esoteric hardware |
| 2020-10-09 00:39:59 | ski | . o O ( isn't the only element of an ordered singleton set the greatest (and the least) element ? ) |
| 2020-10-09 00:40:20 | <koz_> | ski: Isn't every singleton set ordered? Like, vacuously? |
| 2020-10-09 00:40:44 | <ski> | there's only one order on it that you can impose, sure |
| 2020-10-09 00:40:55 | <ski> | (but `Set' is not the same category as `PO') |
| 2020-10-09 00:41:05 | <spinnylights> | and that's partially thanks to the permissive standard :P there's a reason for everything, even if it's not exactly utopian |
| 2020-10-09 00:41:31 | <koz_> | spinnylights: I question the merits of such a standard, if the outcome is 'it's easy to throw together something that may or may not do anything you may or may not expect'. |
| 2020-10-09 00:41:48 | <koz_> | I don't wanna have to play language lawyer when aiming for portability, and C _forces_ you to do this _even when you're not trying_. |
| 2020-10-09 00:42:07 | <koz_> | (again, I got bitten by UB, and portability wasn't even my tenth damned concern) |
| 2020-10-09 00:42:37 | <koz_> | There's no reason for the situation _other_ than an adoption drive (back in the 80s) and legacy (today). |
| 2020-10-09 00:43:45 | <spinnylights> | to be fair, i think claiming that the standard doesn't specify any behavior in particular is overstating your case a bit ;^^ i've written quite a bit of c and any time i've produced ub i've had only myself to blame :P i have yet to find a real compiler bug or anything |
| 2020-10-09 00:44:03 | <spinnylights> | perhaps, i think it's kind of hard to say one way or the other with something like that since the history is so complicated |
| 2020-10-09 00:44:20 | <koz_> | spinnylights: Glad that one of us is lucky like that. I'm not, because I find every bug in everything by breathing. |
| 2020-10-09 00:44:39 | <koz_> | (I'm not joking - I just found a bug in my Real Money Job's nix config by _running nix-build_) |
| 2020-10-09 00:44:48 | <koz_> | (this went unnoticed by everyone for _months_) |
| 2020-10-09 00:44:53 | <koz_> | (well, everyone _else_) |
| 2020-10-09 00:45:09 | <koz_> | And that's basically my life forever with everything. |
| 2020-10-09 00:45:11 | <spinnylights> | i'm not talking about software in general, to be fair :P i've never found a bug compiling c code with gcc |
| 2020-10-09 00:45:22 | <koz_> | spinnylights: Again, compared to me, you lead a charmed life. |
| 2020-10-09 00:45:36 | <koz_> | May you forever continue to be this fortunate. |
| 2020-10-09 00:45:48 | <spinnylights> | if you regularly find bugs in gcc then you're a great boon to the rest of us ^^ |
| 2020-10-09 00:45:59 | <koz_> | spinnylights: Trust me, nobody thanks you for doing this kind of work. |
| 2020-10-09 00:46:17 | <koz_> | (believe me, the responses I've had from certain communities for daring to suggest that somehow I am not responsible personally for every bug I find...) |
| 2020-10-09 00:47:14 | <koz_> | But anyway, I'm _way_ off-topic, so to bring it back to Haskell: I recently realized that wai's Application is effectively ReaderT Request (ContT ResponseReceived IO) Response. |
| 2020-10-09 00:47:15 | <spinnylights> | well, if you're really confident, keep fighting the good fight ^^ if you can find the time to submit a patch they may be more receptive in some cases, also |
| 2020-10-09 00:47:58 | <spinnylights> | but yeah, that's true, this is far away from haskelland :P |
| 2020-10-09 00:48:06 | <koz_> | spinnylights: I do when I can, but a lot of the time, I can't really. I've found bugs in LibreOffice and Firefox - good luck trying to figure out how to fix _those_ unless you've been wrangling those codebases intimately for years. |
| 2020-10-09 00:48:13 | <monochrom> | @unmtl ReaderT Request (ContT ResponseReceived IO) Response |
| 2020-10-09 00:48:14 | <lambdabot> | Request -> (Response -> IO ResponseReceived) -> IO ResponseReceived |
| 2020-10-09 00:48:39 | <spinnylights> | i just patched a bug in firefox's audio backend last week ^^ it's possible |
| 2020-10-09 00:48:50 | <monochrom> | Hrm, what is that ContT doing there? |
| 2020-10-09 00:48:50 | <spinnylights> | sometimes the code's not as gnarly as you would think |
| 2020-10-09 00:49:05 | <spinnylights> | sorry, you're right about all this being off topic though |
| 2020-10-09 00:49:17 | <koz_> | spinnylights: 'Possible' is one thing. It is also 'possible' for me to write a GPGPU-based AV1 encoder, but the number of hours, days, or _months_ it would take me preclude this possibility from being realized. |
| 2020-10-09 00:49:26 | <koz_> | monochrom: Resource handling according to the docs. |
| 2020-10-09 00:49:31 | <koz_> | (no really) |
| 2020-10-09 00:50:04 | → | falafel joins (~falafel@2605:e000:1527:d491:1ccf:5c8d:7928:e9cc) |
| 2020-10-09 00:50:25 | <monochrom> | I think I know that idiom, yeah. |
| 2020-10-09 00:50:56 | <koz_> | How would you ensure resource release a la bracket by way of ContT? |
| 2020-10-09 00:51:04 | <monochrom> | (after "resource handling") |
| 2020-10-09 00:51:07 | <koz_> | Like, if this is an idiom, it's one I've never seen. |
| 2020-10-09 00:51:35 | <monochrom> | It doesn't ensure more than bracket does, but it looks nicely syntactically. |
| 2020-10-09 00:52:07 | → | thir joins (~thir@p200300f27f02580060eb7dde324e54c8.dip0.t-ipconnect.de) |
| 2020-10-09 00:52:52 | <monochrom> | Whereas you normally write "withFoo (\h1 -> withBar (\h2 -> ...))" and after 5 levels it is indenting too much to the right... |
| 2020-10-09 00:53:17 | → | nineonine joins (~nineonine@216-19-190-182.dyn.novuscom.net) |
| 2020-10-09 00:54:12 | <monochrom> | do { h1 <- ContT (\k -> withFoo k); h2 <- ContT (\k -> withBar k); ... } looks more vertical, sequential, straightline. |
| 2020-10-09 00:54:59 | <koz_> | So what's the ContT-based translation of withFile, say? |
| 2020-10-09 00:55:21 | <monochrom> | withFoo k = withFile "filename" ReadMode k |
| 2020-10-09 00:55:44 | <monochrom> | withBar k = bracket acquire release k |
| 2020-10-09 00:56:10 | → | elliott_ joins (~elliott@pool-108-51-141-12.washdc.fios.verizon.net) |
| 2020-10-09 00:56:27 | × | thir quits (~thir@p200300f27f02580060eb7dde324e54c8.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2020-10-09 00:56:28 | <monochrom> | You just slap a ContT (the data constructor) wrapper around each one. And a runContT at some outer level. |
| 2020-10-09 00:57:36 | <ski> | @hackage managed -- koz_ ? |
| 2020-10-09 00:57:37 | <lambdabot> | https://hackage.haskell.org/package/managed -- koz_ ? |
| 2020-10-09 00:57:46 | <monochrom> | Also, this: http://blog.sigfpe.com/2011/10/quick-and-dirty-reinversion-of-control.html |
| 2020-10-09 00:58:07 | <dolio> | So this is an example of a monad where each action causes something in the listed order, and also something in the opposite of the listed order. |
All times are in UTC.