Logs: liberachat/#haskell
| 2021-06-29 12:11:13 | → | functor joins (~functor@151.51.141.57) |
| 2021-06-29 12:11:13 | <tomsmeding> | on a case-insensitive file system, there is still only one possible canonical path; if there were multiple, there would be multiple directory entries that differ only by case, which is nonsensical on a case-insensitive file system |
| 2021-06-29 12:11:15 | <merijn> | tomsmeding: You are just *assuming* that, because the default filesystem for your distro happens to be |
| 2021-06-29 12:11:34 | <Athas> | merijn: but the problem isn't about finding the path to an arbitrary file. The problem is having a path 'foo/bar.hs' that we already know resolves to a file, and then figuring out what the name would look like if you just 'ls'ed that file (or rather, the containing directory). _Much_ simpler. |
| 2021-06-29 12:11:37 | <merijn> | tomsmeding: Not true, you can have multiple paths refering to the same inode |
| 2021-06-29 12:11:57 | <tomsmeding> | I know! |
| 2021-06-29 12:12:06 | <tomsmeding> | but on a case-insensitive file system they cannot differ only by case |
| 2021-06-29 12:12:08 | <Athas> | I think the portable (if inefficient) way of doing this is to just walk the tree and list the contents of every directory. |
| 2021-06-29 12:12:18 | <tomsmeding> | and we know that the canonical path we're looking for differs from our given path only by case |
| 2021-06-29 12:12:22 | <Athas> | tomsmeding: in theory they might! |
| 2021-06-29 12:12:23 | <merijn> | Athas: My point was that the original error is right, but from a different viewpoint. Your viewpoint is "the import is typoed and the file should not be found" |
| 2021-06-29 12:12:41 | <merijn> | Athas: GHC's viewpoint is "the import is right and the file exists, but you typoed the module name in the imported file" |
| 2021-06-29 12:12:51 | <int-e> | Athas: "it can be done" is not a good argument for doing something |
| 2021-06-29 12:13:02 | <merijn> | Whether you typoed the module name or the import is equally valid as error message |
| 2021-06-29 12:13:03 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-06-29 12:13:04 | <int-e> | s/good // |
| 2021-06-29 12:13:21 | <merijn> | tomsmeding: We don't actually :p |
| 2021-06-29 12:13:36 | <Athas> | merijn: sure, but this means that a module might type-check, then later contain errors (according to GHC) depending on how it is imported, which seems wrong to me. |
| 2021-06-29 12:13:45 | <merijn> | tomsmeding: Since .lhs extensions exist too *and* GHC accepts (accepted?) collapsed directory names |
| 2021-06-29 12:14:02 | <tomsmeding> | ooooh |
| 2021-06-29 12:14:04 | <Athas> | Oh, it has already been reported: https://gitlab.haskell.org/ghc/ghc/-/issues/16507 |
| 2021-06-29 12:14:10 | <merijn> | tomsmeding: Which means every module has at least 4 possible names that don't clash on case insensitive filesytems |
| 2021-06-29 12:14:12 | <tomsmeding> | A.hs and a.lhs in the same directory |
| 2021-06-29 12:14:24 | <Athas> | What happens in that case, I wonder. |
| 2021-06-29 12:14:29 | <Athas> | Even A.lhs and A.hs is ambiguous. |
| 2021-06-29 12:14:37 | <merijn> | You are fucked anyway |
| 2021-06-29 12:14:42 | × | fendor_ quits (~fendor@77.119.197.237.wireless.dyn.drei.com) (Ping timeout: 240 seconds) |
| 2021-06-29 12:14:46 | <merijn> | Haskell doesn't specify how imports related to filenames |
| 2021-06-29 12:14:52 | <merijn> | And GHC is handwavey about the semantics |
| 2021-06-29 12:15:00 | × | amk quits (~amk@176.61.106.150) (Remote host closed the connection) |
| 2021-06-29 12:15:06 | <merijn> | So it's all unspecified and a matter of "what happens to work on GHC" |
| 2021-06-29 12:15:11 | <int-e> | Haskell doesn't specify how modules map to files |
| 2021-06-29 12:15:17 | <merijn> | I already made a ticket complaining about this years ago |
| 2021-06-29 12:15:29 | <merijn> | And saying we should have deterministic semantics |
| 2021-06-29 12:15:37 | <merijn> | But I never implemented anything for it, so the status quo remains |
| 2021-06-29 12:15:41 | <int-e> | I mean, you could have a single file declaring all your modules |
| 2021-06-29 12:15:58 | <int-e> | and that'd be okay because it's outside the scope of Haskell's language definition |
| 2021-06-29 12:16:01 | <merijn> | int-e: *That* is not allowed by the grammar |
| 2021-06-29 12:16:14 | <int-e> | But the grammar is for a module? |
| 2021-06-29 12:16:21 | → | nschoe joins (~quassel@178.251.84.79) |
| 2021-06-29 12:16:22 | int-e | shrugs |
| 2021-06-29 12:16:32 | <merijn> | hmm, is it? I don't remember enough details |
| 2021-06-29 12:16:54 | <Athas> | merijn: I am pretty sure it is. |
| 2021-06-29 12:16:59 | <merijn> | Athas: Anyway, I'm not saying GHC is *right* I'm just saying its "definitely not wrong" :p |
| 2021-06-29 12:17:16 | <Athas> | The Haskell 2010 report explicitly shows an example of a "program" with multiple consecutive module definitions. |
| 2021-06-29 12:17:21 | <Athas> | No idea whether GHC accepts it. |
| 2021-06-29 12:17:26 | <merijn> | It doesn't |
| 2021-06-29 12:17:39 | <merijn> | GHC also doesn't accept circular imports :(( |
| 2021-06-29 12:17:46 | <Rembane> | Athas: In the same file? |
| 2021-06-29 12:18:12 | <Athas> | Rembane: the report doesn't say anything about files. |
| 2021-06-29 12:18:20 | → | amk joins (~amk@176.61.106.150) |
| 2021-06-29 12:18:20 | <tdammers> | ^ |
| 2021-06-29 12:18:41 | <tdammers> | I've always assumed that those code samples were meant to be in the same file, but they're not. The report doesn't specify anything wrt source files at all. |
| 2021-06-29 12:18:52 | <merijn> | The problem isn't that the report doesn't say anything about files |
| 2021-06-29 12:18:53 | <Athas> | And strictly speaking, the grammar doesn't have a production permitting consecutive modules. The 'module' nonterminal is the top level, I think. |
| 2021-06-29 12:19:02 | <merijn> | The problem is that GHC doesn't have any specified semantics either |
| 2021-06-29 12:19:43 | <Athas> | Yet GHC's mapping of modules to files is still much better than many other languages. And didn't the other Haskell compilers (when they existed) behave much as GHC does now? |
| 2021-06-29 12:19:59 | <merijn> | There was at least one compiler that accepted the file "Foo.Bar.Baz.hs" for module "Foo.Bar.Baz" |
| 2021-06-29 12:20:10 | <Athas> | It's much better than the SML situation, which despite its much-vaunted formal specification, neglected to talk about multi-file programs at all. So every implementation does it differently. |
| 2021-06-29 12:20:12 | <merijn> | Without needing directories |
| 2021-06-29 12:20:27 | <tdammers> | personally, I've always hated it when compilers/interpreters couple filenames to in-language things |
| 2021-06-29 12:20:36 | <merijn> | tdammers: Yes, but also no |
| 2021-06-29 12:20:57 | <int-e> | merijn: I guess it depends on how much you're willing to read into "The lexical structure captures the concrete representation of Haskell programs in text files." |
| 2021-06-29 12:21:06 | <merijn> | tdammers: I think file names should correspond to modules, but without requiring 1 file per module |
| 2021-06-29 12:21:13 | <Rembane> | Athas, tdammers Interesting and potentially very powerful. |
| 2021-06-29 12:21:15 | <int-e> | The word "file" is mostly absent from the syntax portion of the report :P |
| 2021-06-29 12:21:30 | <merijn> | tdammers: So "Foo/Bar.hz" *should* contain module Foo.Bar but *might* also contain more nested submodules |
| 2021-06-29 12:21:31 | × | kspalaiologos quits (~kspalaiol@user/kspalaiologos) (Quit: Leaving) |
| 2021-06-29 12:21:31 | <tdammers> | merijn: I think that that should be left for the programmer to decide |
| 2021-06-29 12:22:01 | <merijn> | tdammers: I've taught to many students and been surrounded by too many scientists to think that's a good idea :) |
| 2021-06-29 12:22:20 | <Athas> | I like when language concepts are directly coupled to things I already know about (like the hierarchical structure of a file system). Means I have to remember fewer arbitrary details. |
| 2021-06-29 12:22:23 | <tdammers> | merijn: if they can't master discipline, then they don't deserve a toolchain that tries to keep them honest |
| 2021-06-29 12:22:29 | <Athas> | I have _never_ enjoyed learning about include path semantics. |
| 2021-06-29 12:22:29 | <tdammers> | merijn: let them dig their own graves |
| 2021-06-29 12:22:49 | → | d4 joins (~d4@151.51.141.57) |
| 2021-06-29 12:23:08 | ← | functor parts (~functor@151.51.141.57) () |
| 2021-06-29 12:23:15 | <int-e> | .hz <- "Haskell zoo"? :-) |
| 2021-06-29 12:23:54 | <Rembane> | Is there any specific reason for why GHC doesn't handle circular imports? |
| 2021-06-29 12:24:01 | <tdammers> | In all seriousness, "include path semantics" are just a horrible thing to have to be dealing with. And then there's the problem that filenames are subjects to all sorts of restrictions, and identifiers / module names are subject to *other* restrictions, and so you need a translation step between the two which means that in fact module names never equal filenames, and ugh |
| 2021-06-29 12:24:07 | <int-e> | personally I think the "every module is a file" convention is /healthy/ even though it's sometimes inconvenient because there's a tendency for making very small modules. |
| 2021-06-29 12:24:26 | <Athas> | Rembane: it is difficult to do automatically. GHC requires hand-written "boot files" containing type signatures, which are used to break the circularity. |
| 2021-06-29 12:24:29 | <int-e> | And I certainly rely on it... |
| 2021-06-29 12:24:49 | <Rembane> | Athas: Got it. That sounds painful but that a solution exists which is good |
| 2021-06-29 12:24:54 | <boxscape_> | Rembane the code for GHC itself has a few import loops that are resolved in that way |
| 2021-06-29 12:24:54 | <Athas> | tdammers: restricting module names to some simple subset of ASCII solves that, though. |
| 2021-06-29 12:25:24 | × | killsushi quits (~killsushi@user/killsushi) (Quit: Leaving) |
| 2021-06-29 12:25:37 | <boxscape_> | Athas that sucks if you want to code in a language that doesn't use ASCII, though |
| 2021-06-29 12:25:40 | → | nate1 joins (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) |
| 2021-06-29 12:25:47 | <Athas> | I think the circularity limitation is mostly a performance thing. You could always just concatecate a multi-module program to one big module and then type-check that. |
| 2021-06-29 12:25:56 | <boxscape_> | (natural language, that is) |
| 2021-06-29 12:25:57 | <int-e> | (in a dumb way: locate Foo/Bar.l?hs + less --> cheap way of getting a likely source of a Foo.Bar module) |
| 2021-06-29 12:26:46 | <tdammers> | Athas: not entirely. E.g., in Haskell, a source file still needs a .hs extension; and you also violate established file naming conventions (e.g., Unix-like systems tend to prefer kebab-cased filenames, but Haskell modules need to be PascalCased) |
| 2021-06-29 12:27:07 | <Athas> | tdammers: you can use underscores in module names, can't you? |
| 2021-06-29 12:27:20 | <boxscape_> | % module Under_Score where |
| 2021-06-29 12:27:21 | <yahb> | boxscape_: |
| 2021-06-29 12:27:23 | <boxscape_> | yes |
| 2021-06-29 12:27:26 | <tdammers> | Athas: yes, and now you're violating both Unix filename and Haskell module name conventions |
| 2021-06-29 12:27:45 | <Athas> | I wouldn't say undescores in Unix file names is much of a violation. |
| 2021-06-29 12:28:00 | <tdammers> | Athas: it works, but it's not idiomatic |
| 2021-06-29 12:28:02 | → | Pickchea joins (~private@user/pickchea) |
All times are in UTC.