Logs: freenode/#haskell
| 2020-09-19 18:45:48 | <monochrom> | To a large extent every GHC extension paper is of much higher quality than Haskell 2010 quality. |
| 2020-09-19 18:46:19 | <monochrom> | Every such paper painstakingly writes down typing rules. There is none in the Haskell Reports. |
| 2020-09-19 18:46:27 | <sm[m]> | nice tomsmeding |
| 2020-09-19 18:46:56 | <davean> | It would be nice if one could clean-room impliment Haskell from the report without other knowlege than how to read it and anything explicitely referenced. We don't have that. |
| 2020-09-19 18:47:05 | <tomsmeding> | (formatting is debatable) |
| 2020-09-19 18:47:07 | <davean> | Requiring that is a weird standard to update other parts of the report. |
| 2020-09-19 18:47:21 | <monochrom> | At this rate, adding most GHC extensions to the next Haskell Report is trivial, just write down the syntax, there is no need to write down the typing rules or the dynamic semantics, thus "no need", har har har. |
| 2020-09-19 18:47:50 | → | wavemode joins (~wavemode@097-070-075-143.res.spectrum.com) |
| 2020-09-19 18:48:19 | <geekosaur> | monochrom, the downside is that the typing rules often assume ghc's internal type system, which I'm not sure anyone wants to take as the basis for a Haskell standard |
| 2020-09-19 18:48:52 | → | jumper149 joins (~jumper149@ip185225.wh.uni-hannover.de) |
| 2020-09-19 18:48:58 | <maerwald> | tomsmeding: how do you download a paste? |
| 2020-09-19 18:49:07 | <geekosaur> | and nobody wants to do the work to specify a minimal type system for the Report |
| 2020-09-19 18:49:21 | <tomsmeding> | maerwald: there's the [raw] link for the first file |
| 2020-09-19 18:49:31 | <maerwald> | tomsmeding: I mean all files |
| 2020-09-19 18:49:36 | <davean> | geekosaur: right. |
| 2020-09-19 18:49:41 | <tomsmeding> | you don't, currently :p |
| 2020-09-19 18:49:51 | <tomsmeding> | how would you expect that to work, zip file? |
| 2020-09-19 18:49:58 | <dmwit> | ski: Counterpoint: the obvious alternative is for forall to take the variable out of scope. But foralls are overloaded now to also be part of the TypeApplications API. |
| 2020-09-19 18:50:02 | <tomsmeding> | also how often do you really need that |
| 2020-09-19 18:50:14 | <lechner> | Hi, why do I have to use the <- assignment operator on the result from getArgs, but not on the result from readFile, please? I see that the readLine result is not 'tainted' by the IO monad, but I do not otherwise see a distinction between these commands vs expressions. |
| 2020-09-19 18:50:18 | <dmwit> | ski: So that seems like it would be sort of a bad conflict in what you're able to express. |
| 2020-09-19 18:50:41 | <dmwit> | lechner: You *do* have to use <- on the result from readFile. Why do you believe you don't? |
| 2020-09-19 18:50:48 | <wwwww> | Let's say i would like to run something with forkIO, in OSX only single thread spawns but in linux there are many of them, why? |
| 2020-09-19 18:50:56 | <Uniaika> | < geekosaur> and nobody wants to do the work to specify a minimal type system for the Report // yeah, it takes time, effort and coordination, and I feel like we're too much in maintenance mode for that kind of thing to happen |
| 2020-09-19 18:50:56 | <dmwit> | lechner: Also, I challenge your claim that readLine is not 'tainted'. |
| 2020-09-19 18:51:29 | <lechner> | never mind, i thought i passed the result directly to putStr when i fact I placed a =<< in between |
| 2020-09-19 18:51:29 | <dolio> | wwwww: No threaded runtime maybe? |
| 2020-09-19 18:51:34 | <dmwit> | wwwww: Perhaps the compiler you're using on Linux has defaulted to the threaded runtime, but the one on OSX hasn't? |
| 2020-09-19 18:51:46 | <maerwald> | tomsmeding: tar.gz |
| 2020-09-19 18:51:49 | <davean> | wwwww: forkIO is not forkOS |
| 2020-09-19 18:52:06 | <wwwww> | I know they are different but i get same result |
| 2020-09-19 18:52:09 | <maerwald> | zip is trash |
| 2020-09-19 18:52:15 | × | irc_user quits (uid423822@gateway/web/irccloud.com/x-jxviwzlqotrdnqhx) (Quit: Connection closed for inactivity) |
| 2020-09-19 18:52:17 | <lechner> | does <- force an evaluation, in some sense ? |
| 2020-09-19 18:52:43 | <tomsmeding> | maerwald: fair :p |
| 2020-09-19 18:52:48 | <dmwit> | lechner: No, it forces an execution. |
| 2020-09-19 18:52:55 | <tomsmeding> | how many times have you wanted such functionality already |
| 2020-09-19 18:53:02 | <maerwald> | all the time man |
| 2020-09-19 18:53:10 | <ski> | dmwit : hm, point. however, if we get `foo @a ... = ..a..', then that could be combined with `foo :: forall a. ..a..' |
| 2020-09-19 18:53:11 | <davean> | wwwww: forkIO is a greenthread. Why would it produce a new OS thread generally? Thats a RTS decision. |
| 2020-09-19 18:53:19 | <lechner> | dmwit: in the world of haskell, that's not the same thing? |
| 2020-09-19 18:53:22 | tabemann_ | is now known as tabemann |
| 2020-09-19 18:53:29 | <dmwit> | lechner: "evaluation" is the process of reducing expressions to other expressions. "execution" is the process of submitting terms to the runtime system to request that effects be performed. |
| 2020-09-19 18:53:35 | <davean> | lechner: not at all the same. |
| 2020-09-19 18:53:49 | → | MaoZeDong_ joins (~yuri@2a00:1370:8135:91d4:956f:2ce4:9ce3:de8c) |
| 2020-09-19 18:53:58 | <dmwit> | ski: Neat idea! |
| 2020-09-19 18:54:05 | × | knupfer quits (~Thunderbi@mue-88-130-61-068.dsl.tropolys.de) (Ping timeout: 260 seconds) |
| 2020-09-19 18:54:10 | <tomsmeding> | maerwald: personally I'd barely ever use it, only on the wildest pastes with >3 files, but I guess other people work differently :p |
| 2020-09-19 18:54:20 | <monochrom> | Well, beginners from imperative backgrounds do not already know that, or why, we need two separate "eval" and "exec" notions. |
| 2020-09-19 18:54:24 | <dolio> | lechner: It's kind of jargon invented here. |
| 2020-09-19 18:54:37 | <ski> | dmwit : i dunno whether it will happen, but i can still complain about it ;) |
| 2020-09-19 18:54:40 | <dolio> | People tend to use it before explaining it for some reason. :) |
| 2020-09-19 18:54:43 | <dmwit> | ski: Hm, I'm not sure I understand that, though. How is the order of variables determined from `foo @a ... = ...`? |
| 2020-09-19 18:54:49 | <merijn> | davean: eh, note that forkOS doesn't spawn an OS thread either |
| 2020-09-19 18:54:50 | <geekosaur> | I've used the gist.github.com equivalent a few times. Not often, but I also haven't encountered that many multi-file pastes |
| 2020-09-19 18:54:57 | <lechner> | dmwit: doesn't an execution necessitate an evaluation? |
| 2020-09-19 18:54:59 | <monochrom> | So you need to be gentle in the sense that you can't just paint it as "everyone else already knows" truth. Every else doesn't already know. |
| 2020-09-19 18:54:59 | <dmwit> | ski: Are you suggesting that the `a` in `@a` must have the same name as in the type signature? |
| 2020-09-19 18:55:05 | <ski> | dmwit : `foo :: forall a. forall b. ..a..b..; foo @a @b ... = ...' |
| 2020-09-19 18:55:06 | <dmwit> | lechner: Very often, yes. But not always. |
| 2020-09-19 18:55:09 | <ski> | dmwit : no |
| 2020-09-19 18:55:14 | <davean> | merijn: yes, I was getting there. |
| 2020-09-19 18:55:34 | × | supercoven quits (~Supercove@dsl-hkibng32-54fb54-166.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2020-09-19 18:55:38 | <dmwit> | ski: Then I don't understand how it helps clear up the conflict I proposed. |
| 2020-09-19 18:55:39 | <davean> | merijn: threading is hard |
| 2020-09-19 18:55:40 | <monochrom> | The next surprising divergence will be how, and why, parsing is different from eval order. |
| 2020-09-19 18:55:41 | <wwwww> | I tried forkOS/forkIO and as result still i have single thread in OSX davean |
| 2020-09-19 18:55:46 | → | son0p joins (~son0p@186.159.4.142) |
| 2020-09-19 18:55:49 | tomsmeding | notes that the people coming here complaining that the channel is quiet should probably return during US waking times |
| 2020-09-19 18:55:55 | <dmwit> | ski: If forall is used both for variable hiding and variable order, how to I express the order of unhidden variables? |
| 2020-09-19 18:56:03 | <davean> | wwwww: sure, but my point is theres no reason to tihnk either of them would create a thread in particular. |
| 2020-09-19 18:56:08 | <lechner> | i guess commands can perhaps expect an expression, too |
| 2020-09-19 18:56:10 | <davean> | wwwww: How many threads is an RTS decision |
| 2020-09-19 18:56:11 | <merijn> | wwwww: What are you trying to do? |
| 2020-09-19 18:56:11 | <geekosaur> | what are you using to determine threads? they look different in OS X vs. Linux |
| 2020-09-19 18:56:17 | <davean> | which is what the RTS options are about. |
| 2020-09-19 18:56:23 | <monochrom> | Europe waking time is also pretty active here. |
| 2020-09-19 18:56:25 | <ski> | dmwit : `zip :: forall a. forall b. [a] -> [b] -> [(a,b)]; zip @u @v (xs :: [u]) (ys :: [v]) = ..u..v..xs..ys.' should be fine |
| 2020-09-19 18:56:28 | <davean> | geekosaur: yes, process vs. not |
| 2020-09-19 18:56:33 | <geekosaur> | in particular, on linux they show up in ps becuase of how linux implements threads |
| 2020-09-19 18:56:53 | <ski> | dmwit : each defining equation could name the type parameters differently, if it wanted to |
| 2020-09-19 18:56:53 | <wwwww> | merijn: i'm building server for my game |
| 2020-09-19 18:56:58 | <dmwit> | ski: Ahhh, so the foralls give the order, and the @ patterns give what's hidden? |
| 2020-09-19 18:57:03 | <dmwit> | (well, what's not hidden) |
| 2020-09-19 18:57:04 | <ski> | yes |
| 2020-09-19 18:57:12 | <dmwit> | Got it! Very sensible. |
| 2020-09-19 18:57:13 | <davean> | ski: I like that. |
| 2020-09-19 18:57:18 | <davean> | ski: Please give! |
| 2020-09-19 18:57:23 | <tomsmeding> | monochrom: apparently the Europeans are active in the evening then :) |
| 2020-09-19 18:57:23 | <ski> | give ? |
| 2020-09-19 18:57:28 | <merijn> | wwwww: "I need to concurrently handle many connections" (that's what forkIO is for) and "I need multiple OS threads" are orthogonal issues |
| 2020-09-19 18:57:41 | <davean> | ski: please give me that as how I get to do it :) |
| 2020-09-19 18:57:43 | <dmwit> | ski: I think he's asking you to implement it and send him a patch. ^_^ |
| 2020-09-19 18:57:56 | <merijn> | wwwww: You can spawn many threads handling independent conncections using a single OS thread, using multiple OS threads is optional |
| 2020-09-19 18:58:30 | → | exarkun1 joins (~exarkun@193.56.252.210) |
| 2020-09-19 18:58:36 | <ski> | dmwit : alternatively, you should be able to say `zip :: [a] -> [b] -> [(a,b)]; zip (xs :: [a]) (ys :: [b]) = ..a..b..xs..ys..', of course. but then the order of the type parameters isn't clear (as is already the case with implicit `forall') |
| 2020-09-19 19:00:17 | <ski> | hm .. i suppose, if this would have any chance of being accepted, it would probably be a differently named language extension than `ScopedTypedVariables' |
| 2020-09-19 19:00:38 | <dolio> | ski: Yeah, that's the problem. |
| 2020-09-19 19:00:45 | <maerwald> | south-east asia time is pretty silent |
| 2020-09-19 19:00:45 | <dolio> | Too late to fix the design. |
All times are in UTC.