Logs: liberachat/#haskell
| 2021-07-15 19:03:40 | dminuoso | idly wonders whether someone else has thought of this before |
| 2021-07-15 19:05:29 | <[exa]> | dminuoso: that sounds so cool that I really expect a finished list of things that it would break in ghc gitlab |
| 2021-07-15 19:05:53 | <lechner> | boxscape tomsmeding [exa]: that worked well. thanks! |
| 2021-07-15 19:07:10 | <boxscape> | dminuoso: I believe this is intended to solve the same problem with a different approach (more expressive export lists) https://github.com/goldfirere/ghc-proposals/blob/local-modules/proposals/0000-local-modules.rst |
| 2021-07-15 19:07:31 | <dminuoso> | [exa]: Well, it doesn't really change language semantics. It seems, that files with a bunch of imports you just more easily get ambiguities. |
| 2021-07-15 19:07:57 | × | haykam2 quits (~haykam@static.100.2.21.65.clients.your-server.de) (Remote host closed the connection) |
| 2021-07-15 19:08:08 | <tomsmeding> | dminuoso: that sounds a bit too heavy-handed; it might work well when only importing container-like modules, but what if I have two modules that both define an Event data type and I resolve the ambiguity by importing them both qualified? |
| 2021-07-15 19:08:10 | → | haykam1 joins (~haykam@static.100.2.21.65.clients.your-server.de) |
| 2021-07-15 19:08:29 | <tomsmeding> | I guess then I should just not use that extension in said module :D |
| 2021-07-15 19:08:32 | <dminuoso> | tomsmeding: Then refer to them with the qualifier. |
| 2021-07-15 19:08:37 | <boxscape> | tomsmeding: that wouldn't bite you until you actually tried to use Event unqualified |
| 2021-07-15 19:08:38 | × | MQ-17J quits (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Ping timeout: 268 seconds) |
| 2021-07-15 19:08:42 | → | Deide joins (~Deide@217.155.19.23) |
| 2021-07-15 19:08:42 | × | Deide quits (~Deide@217.155.19.23) (Changing host) |
| 2021-07-15 19:08:42 | → | Deide joins (~Deide@user/deide) |
| 2021-07-15 19:08:44 | <tomsmeding> | hm, right |
| 2021-07-15 19:08:46 | <dminuoso> | Im not suggesting the type constructor would *only* be exposed unqualified. But in addition |
| 2021-07-15 19:08:53 | × | bgamari quits (~bgamari@72.65.101.148) (Ping timeout: 258 seconds) |
| 2021-07-15 19:09:04 | <tomsmeding> | that then begs the question, why only type constructors |
| 2021-07-15 19:09:24 | <dminuoso> | Because that would suit my personal usage pattern. |
| 2021-07-15 19:09:29 | <tomsmeding> | :p |
| 2021-07-15 19:09:43 | → | MQ-17J joins (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-15 19:10:12 | <dminuoso> | Let's face it, the only reason people put in so much energy into GHC proposals, is because they have some personal interest (for whatever reason) in them. :p |
| 2021-07-15 19:10:34 | <boxscape> | you could also imagine having two import lists for qualified import statements, one for qualified imports and one for unqualified |
| 2021-07-15 19:10:48 | → | bgamari joins (~bgamari@72.65.101.148) |
| 2021-07-15 19:11:00 | <boxscape> | (and some syntactic mechanism that allows you to omit either one or the other) |
| 2021-07-15 19:11:06 | <tomsmeding> | perhaps you can make it a bit more generic by instead allowing new import syntax: e.g. 'import Data.Map.Strict (Map) andalsoqualified' |
| 2021-07-15 19:11:11 | <tomsmeding> | where that clearly needs a better keyword name |
| 2021-07-15 19:11:26 | tomsmeding | high-fives boxscape |
| 2021-07-15 19:12:00 | <boxscape> | tomsmeding: how about `import Data.Map.Strict (Map) qualified (fromList)`, that meshes nicely with -XImportQualifiedPost |
| 2021-07-15 19:12:10 | <dminuoso> | Uh |
| 2021-07-15 19:12:16 | <dminuoso> | boxscape: That reads horrible! |
| 2021-07-15 19:12:21 | <boxscape> | :( |
| 2021-07-15 19:12:22 | <boxscape> | okay |
| 2021-07-15 19:12:24 | <tomsmeding> | `import Data.Map.Strict (Map) qualified as Map`? |
| 2021-07-15 19:12:25 | <dminuoso> | So the things to the left hand side are qualified? |
| 2021-07-15 19:12:43 | <boxscape> | I did kind of forget about the as part you usually have for that import |
| 2021-07-15 19:12:43 | <tomsmeding> | yeah this syntax reads completely ambiguous :p |
| 2021-07-15 19:12:47 | <boxscape> | dminuoso: I would have said the things on the right :P |
| 2021-07-15 19:12:51 | <boxscape> | but fair enough |
| 2021-07-15 19:13:15 | <dminuoso> | boxscape: Plus, that defeats the entire point of ImportQualifiedPost in the first place. :P |
| 2021-07-15 19:13:16 | <tomsmeding> | can you then also have ImportQualifiedPostPost that allows `import Data.Map.Strict (Map) (fromList) qualified` |
| 2021-07-15 19:13:24 | <boxscape> | dminuoso: that is a good point |
| 2021-07-15 19:13:52 | <tomsmeding> | reeks of () => () => from pattern synonyms |
| 2021-07-15 19:13:58 | <boxscape> | tomsmeding: what I liked about what I wrote is that it allows you to omit either import list in a syntactically lightweight way |
| 2021-07-15 19:14:13 | <boxscape> | which you can't have if the import lists are juxtaposed |
| 2021-07-15 19:14:16 | <[exa]> | dminuoso: what about `import Some.Module (data)` ? |
| 2021-07-15 19:14:49 | <tomsmeding> | boxscape: the PostPost part was jesting :p |
| 2021-07-15 19:15:03 | <boxscape> | I did kind of expect that :) |
| 2021-07-15 19:15:05 | <tomsmeding> | [exa]: `import Some.Module (Map)` is shorter :p |
| 2021-07-15 19:15:20 | × | ubikium quits (~ubikium@113x43x248x70.ap113.ftth.arteria-hikari.net) (Read error: Connection reset by peer) |
| 2021-07-15 19:15:20 | <dminuoso> | https://github.com/ghc-proposals/ghc-proposals/pull/340 |
| 2021-07-15 19:15:34 | × | o1lo01ol1o quits (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) (Remote host closed the connection) |
| 2021-07-15 19:15:36 | <dminuoso> | So this is in a similar design space |
| 2021-07-15 19:15:46 | → | eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-15 19:16:54 | <boxscape> | the current proposal that replaced that is https://github.com/ghc-proposals/ghc-proposals/pull/270 which allows `import Data.Proxy type qualified as T` |
| 2021-07-15 19:18:01 | <tomsmeding> | dminuoso: that proposal feels forced, kind of? |
| 2021-07-15 19:18:21 | <tomsmeding> | especially when it starts talking about importing from an alias |
| 2021-07-15 19:18:21 | <dminuoso> | Forced? |
| 2021-07-15 19:19:06 | <tomsmeding> | will there always be just two categories of names |
| 2021-07-15 19:19:26 | <dminuoso> | Well, actually this proposal gives a solution |
| 2021-07-15 19:19:28 | <dminuoso> | Since you can do: |
| 2021-07-15 19:19:45 | <dminuoso> | import qualified Data.Map.Strict as (_, M) |
| 2021-07-15 19:19:59 | <dminuoso> | This proposal has my attention now. :) |
| 2021-07-15 19:20:34 | <tomsmeding> | that wouldn't import the value names at all, right? Just the type names |
| 2021-07-15 19:20:42 | × | MQ-17J quits (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Ping timeout: 255 seconds) |
| 2021-07-15 19:20:45 | <dminuoso> | boxscape: Ah. |
| 2021-07-15 19:20:58 | <dminuoso> | tomsmeding: The proposal has actually been closed in favour of 270 |
| 2021-07-15 19:21:03 | <tomsmeding> | or did you mean (M, _), in which case you still need another import for the Map type -- and at two imports you aren't better than the status quo |
| 2021-07-15 19:21:21 | <dminuoso> | tomsmeding: In the proposal 340 that symtax would mean data level things unqualified, and type level things qualified under M |
| 2021-07-15 19:21:47 | tomsmeding | read it as data level things not at all, but I probably read wrong |
| 2021-07-15 19:21:57 | <dminuoso> | But at the end, I dont have strong feelings about syntax around import. |
| 2021-07-15 19:22:08 | <dminuoso> | Double importing is a slight nuissance, but nothing that really changes the way I write code |
| 2021-07-15 19:22:17 | → | MQ-17J joins (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-15 19:22:22 | <tomsmeding> | also I kind of think importing should not be the complex part of the language |
| 2021-07-15 19:22:40 | → | ubikium joins (~ubikium@113x43x248x70.ap113.ftth.arteria-hikari.net) |
| 2021-07-15 19:22:43 | <tomsmeding> | double-importing Map takes two lines but is quite clear in what it does |
| 2021-07-15 19:22:56 | × | Guest984 quits (~Guest9@43.241.144.126) (Quit: Connection closed) |
| 2021-07-15 19:23:52 | <dminuoso> | tomsmeding: Im not sure, phadej's most recent proposal about renaming has some merit. |
| 2021-07-15 19:24:08 | <dminuoso> | Much of our module code is concerned with naming things, binding values to *names* |
| 2021-07-15 19:24:08 | → | Null_A joins (~null_a@2601:645:8700:2290:f850:a5d3:841d:88de) |
| 2021-07-15 19:24:21 | <dminuoso> | It stands to reason that we get at least a slight bit of control when we bring identifiers into scope from other modules. |
| 2021-07-15 19:24:38 | <dminuoso> | (Or, rather, we bind expressions to names) |
| 2021-07-15 19:25:38 | <tomsmeding> | hm, true |
| 2021-07-15 19:28:17 | <tomsmeding> | dminuoso: which proposal is that, that you're referring to? |
| 2021-07-15 19:28:58 | <dminuoso> | https://github.com/ghc-proposals/ghc-proposals/pull/408 |
| 2021-07-15 19:29:15 | <tomsmeding> | heh |
| 2021-07-15 19:29:23 | <tomsmeding> | looks like backpack |
| 2021-07-15 19:29:38 | <yushyin> | mixins? |
| 2021-07-15 19:29:47 | <tomsmeding> | yeah |
| 2021-07-15 19:29:53 | <tomsmeding> | just reminds me of that |
| 2021-07-15 19:30:08 | <EvanR> | arkanoid: division by integer zero seems to be better handled as one of these things you probe to be impossible, if it happens anyway, throw an exception and fix the bug |
| 2021-07-15 19:30:09 | <tomsmeding> | dminuoso: the first two code blocks under Motivation are the same :p |
| 2021-07-15 19:30:17 | <EvanR> | prove* |
| 2021-07-15 19:30:29 | <tomsmeding> | OH they aren't |
| 2021-07-15 19:30:31 | <dminuoso> | newtype Fix = Fix { unFix :: f (Fix a) } |
| 2021-07-15 19:30:33 | <dminuoso> | newtype Fix = Fix { unfix :: f (Fix a) } |
| 2021-07-15 19:30:36 | <tomsmeding> | yes |
| 2021-07-15 19:31:28 | shane_ | is now known as shane |
| 2021-07-15 19:32:18 | <EvanR> | proving values can't be zero is out of scope of monads |
All times are in UTC.