![]() ![]() Balanced against the proposals for namespacing look like a lot of work and/or disruption. So any fancy business with modules/namespaces for my code has relatively small benefit. Most of those imports are libraries, including core libraries/about which I can do nothing. The 1 module is per the 1 file the many modules are the imports the few extra are the modules getting imported twice as unqualified or with multiple qualifiers. Where the 1 file is the immediate source you give to the compiler the many are the files it imports. Rather: 1 compilation unit = 1+many files = 1+many+few modules. (And if one TH decl wants to use another, you must compile that first it rapidly gets ugly.) I’m not seeing your proposal is tackling TH(?) The discussion is also concerned about Template Haskell, where certainly it’s a royal pain that you need to compile the module/file declaring the TH functions before you can compile the module/files that use them. One of the proposals claims “compilation units = modules = files” – that’s in the discussion/not quoting the author. You can also consult the two other proposals Then the solution for you is easy: go away and write in Rust. I guess, that the problem statement is, I would like to write code like the examples. Types (and all the names they introduce) must be global, for type coherence. Using namespaces to try to wrangle types will certainly come to grief in more complex cases – as already pointed out at “won’t fix orphans”. NoFieldSelectors is there to make sure I can’t even try to access via selector name. Main = print (pretty (Mk2 0 1) pretty (Mk3 0 1 0))ĭuplicateRecordFields is there to allow data decls with same-named fields not to use any of the type-directed disambiguation. In another extension, we could make record functions be automatically assigned to the namespace of the record. We could prevent name collisions on records in a structured way. For example, if we type Entry:: the IDE would know there is only two interesting functions to report. We can make tooling give better code predictions. To use a namespace variable, you can refer to it directly: main = do We can add functions and variables to namespace like so: namespace Entry where I’m going to use the X::a notation to indicate namespaces, we can differentiate it from types in the same way as we do for modules M.a. So, I was thinking about how namespaces could be implemented in Haskell, and I’m not sure it’s good enough to create a GHC proposal, so I would like your feedback.įirst, why not just use modules? Well, modules are currently being tied to specific files, and often we want our namespaces to be more particular. I have been following the Advent-of-Code using Rust, and one thing that really hit me is how well integrated the namespace system is compared to the one we have in Haskell.
0 Comments
Leave a Reply. |