
Short version: here is the poll < https://docs.google.com/forms/d/e/1FAIpQLSdniOfoaX7xflgdWRnjVQ6_VLtk1oxA00SoK3KPMUsoTSPZDw/viewform?c=0&w=1
I noticed recently that Foo.Bar.hs is supported by GHC. I had always assumed it wasn't because people always use directories. I've never liked having separate directories for each level of hierarchy. It's easier to just list a list of files and script (e.g. even copying a file X.hs to Y.hs is a bummer). When opening them on GitHub you have to click through to get a complete picture of a project. Other languages do and don't do this. Lispers, for example, don't. How do other Haskellers feel about it? Would it mess with anybody's tooling or mojo if I switched to that style in my packages? For one I know that Stack (my own implementation), actually assumes hierarchical filenames. So I'd have to patch that to implement this. E.g.
Unable to find a known candidate for the Cabal entry "HIndent.Types", but did find: HIndent.Types.hs. If you are using a custom preprocessor for this module with its own file extension, consider adding the file(s) to your .cabal under extra-source-files.
I suppose the real question is, as a language standard and a community preference, should this be considered a bug? Should people be free to use X.Y.hs or X/Y.hs styles? Ciao!

So here's a variation which goes to the other extreme. It is completely unsupported right now though: ╶┮▬ Bar/ ├─┮▬ Baz/ │ ├─╴ Internals.hs │ ╰─╴ hs ╰─┮▬ Foo/ ├─╴ Internals.hs ╰─╴ hs You may know this already (and I suspect there are those in your audience who know as well), but this is how Python works, except that your 'hs' files are called '__init__.py' and they're generally required for every directory with Python modules in it (mostly you will find empty ones littered throughout Python projects). You can, of course, put code in the __init__.py or rexport stuff from the modules to make them available at the level of Bar.Baz, for instance. For an extended example, if these were Python modules and you wrote: "from bar.baz.internals import some_function" The python interpreter would evaluate the top-level declarations within the __init__.py in each directory in order (1. bar, 2.baz) before finally importing from the internals module (at which point it would also execute all top-level declarations there as well. There are some clunky aspects to it and a danger of circular imports which results in all kinds of nonsense, but one thing I like about Python-style imports is that it's pretty much always obvious where things originated from. On Dec 18, 2016 2:29 PM, "MarLinn via Haskell-Cafe" < haskell-cafe@haskell.org> wrote:
I suppose the real question is, as a language standard and a community preference, should this be considered a bug? Should people be free to use X.Y.hs or X/Y.hs styles?
First off all, the support you mention seems to be incomplete, or very recent. At least my ghci 7.10 failed to import a module with a dot-name. But maybe my quick-and-dirty test was broken…
I'll also add a fun variation to the discussion. Let's say I have two modules named Bar.Foo, and Bar.Baz and submodules Bar.Foo.Internals and Bar.Baz.Internals. (eg. for testing purposes) It always bugged me that the usual approach would be this:
╶┮▬ Bar/ ├─┮▬ Baz/ │ ╰─╴ Internals.hs ├─┮▬ Foo/ │ ╰─╴ Internals.hs ├──╴ Baz.hs ╰──╴ Foo.hs
My gripe is that here related modules are in completely unrelated positions. One way to solve it with dot-names would be
╶┮▬ Bar/ ├──╴ Baz.hs ├──╴ Baz.Internals.hs ├──╴ Foo.hs ╰──╴ Foo.Internals.hs
But that can lead to a lot of clutter fast. So here's a variation which goes to the other extreme. It is completely unsupported right now though:
╶┮▬ Bar/ ├─┮▬ Baz/ │ ├─╴ Internals.hs │ ╰─╴ hs ╰─┮▬ Foo/ ├─╴ Internals.hs ╰─╴ hs
That hs name does look a bit ridiculous, but the idea is to have something like an index.html without reserving a name. If slashes and dots were 100% interchangeable, this would be the logical extension. Now related files are in related positions. Downside: The hs files don't have a file extension. (There could be a special case to use .hs as a special name instead, but that would lead to hidden files and break consistency…)
I realize this version probably won't gain much approval, but between this and throwing everything and the kitchen sink on the top level just because some tools don't offer opened-up nested hierarchical views into directory structures – I would choose this one, personally. Or maybe a mixture, depending on actual structure. But then both options are better than the one with unrelated positions, and the dot-name approach might at least be one that works right now.
Cheers, MarLinn
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

You may know this already (and I suspect there are those in your audience who know as well), but this is how Python works, except that your 'hs' files are called '__init__.py' and they're generally required for every directory with Python modules in it (mostly you will find empty ones littered throughout Python projects).
No, I did not know this! But now that you mention it I am reminded of the magic files you can use to add package-level comments (but only those, no code) in java. It's interesting that there is more prior art like this. However now I am even more convinced that this topic is quite orthogonal to the original question. Speaking of orthogonal issues:
For an extended example, if these were Python modules and you wrote:
"from bar.baz.internals import some_function"
The python interpreter would evaluate the top-level declarations within the __init__.py in each directory in order (1. bar, 2.baz) before finally importing from the internals module (at which point it would also execute all top-level declarations there as well.
That sounds like something that might be easy to add to Haskell via a syntax extension: whenever an import contains two dots in a row (or a dot and a question mark, or what have you), special handling like this could kick in from that point on downwards. Maybe require an explicit import list in this case? This is only the engineer in me speaking though, I very much suspect this to be a solution without a problem in our world. Neat thing to ponder though. Cheers, MarLinn

should this be considered a bug?
the fewer and simpler standards there are, the better. There may be benefit in simplifying syntax. every non-essential variation in standards is a few hours wasted for someone, often for more than one. in chess, board has been 8x8, same pieces, B&W - for a long time. Seems to be enough: seasoned masters still take time to prepare before each essential game.

I thought the use of dotted file names was part of the hierarchical packages proposal from back when it was a new thing?

On Sun, Dec 18, 2016 at 11:25 PM, MarLinn via Haskell-Cafe < haskell-cafe@haskell.org> wrote:
But that can lead to a lot of clutter fast. So here's a variation which goes to the other extreme. It is completely unsupported right now though:
╶┮▬ Bar/ ├─┮▬ Baz/ │ ├─╴ Internals.hs │ ╰─╴ hs ╰─┮▬ Foo/ ├─╴ Internals.hs ╰─╴ hs
That hs name does look a bit ridiculous, but the idea is to have something like an index.html without reserving a name. If slashes and dots were 100% interchangeable, this would be the logical extension.
Well, not exactly THE "logical" extension. How about the following one? ╶┮▬ Bar/ ├─┮▬ Baz/ │ ├─┮▬ Internals/ │ ╰─╴ hs │ ╰─╴ hs ╰─┮▬ Foo/ ├─┮▬ Internals/ ╰─╴ hs ╰─╴ hs [Not that I endorse my own proposition, though :-)] Cheers. --Serge

2016-12-18 22:29 GMT+01:00 Christopher Done
[...] I've never liked having separate directories for each level of hierarchy. It's easier to just list a list of files and script (e.g. even copying a file X.hs to Y.hs is a bummer). When opening them on GitHub you have to click through to get a complete picture of a project.
I think this is just a matter of personal preference, I actually like directories: If you have a toy project, it doesn't make a difference, because you have only a few modules a no urgent need for structuring things. OTOH, if you have a medium or large project, using directories is essential IMHO, and if your namespace is structured in a sane way, you rarely want to see stuff from different parts of the directory tree. If you do: Restructure! :-)
[...] I suppose the real question is, as a language standard and a community preference, should this be considered a bug? Should people be free to use X.Y.hs or X/Y.hs styles?
If you have both X.Y.hs *and* X/Y.hs, which one should GHC choose? And what about X.Y.Z.hs vs. X/Y.Z.hs vs X.Y/Z.hs vs. X/Y/Z.hs? My POV is: There should only be one way of doing things, and in our case that should be directories (the no-directories approach doesn't scale). Leaving things up to personal taste confuses different readers, makes tooling more complicated than necessary etc. But that's just my 2c... Cheers, S.

Hi Chris, When I proposed adding support for more useful literate haskell extensions (i.e. allow Foo.lhs.md and Foo.lhs.rst) I encountered this too and after further investigation discovered that the Report has *0* specification of how module names are supposed to map to file names/directories. As such, it's impossible to actually write portable source code. The common version of one directory per component with a file for the end seems the most commonly supported one across GHC, Hugs and UHC, which is I think why people using it (And probably why the multiple components in a file name is best avoided). For tools like stack (and everyone's sanity in general) I think it would be best to standardise how modules are resolved, but when I last floated this idea it got shot down, so.... Cheers, Merijn
On 18 Dec 2016, at 22:29, Christopher Done
wrote: Short version: here is the poll https://docs.google.com/forms/d/e/1FAIpQLSdniOfoaX7xflgdWRnjVQ6_VLtk1oxA00SoK3KPMUsoTSPZDw/viewform?c=0&w=1
I noticed recently that Foo.Bar.hs is supported by GHC. I had always assumed it wasn't because people always use directories.
I've never liked having separate directories for each level of hierarchy. It's easier to just list a list of files and script (e.g. even copying a file X.hs to Y.hs is a bummer). When opening them on GitHub you have to click through to get a complete picture of a project.
Other languages do and don't do this. Lispers, for example, don't.
How do other Haskellers feel about it? Would it mess with anybody's tooling or mojo if I switched to that style in my packages?
For one I know that Stack (my own implementation), actually assumes hierarchical filenames. So I'd have to patch that to implement this. E.g.
Unable to find a known candidate for the Cabal entry "HIndent.Types", but did find: HIndent.Types.hs. If you are using a custom preprocessor for this module with its own file extension, consider adding the file(s) to your .cabal under extra-source-files.
I suppose the real question is, as a language standard and a community preference, should this be considered a bug? Should people be free to use X.Y.hs or X/Y.hs styles?
Ciao! _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

There was discussion of this some years ago, too lazy to find it. I think
John Meacham's jhc supported it, and there was discussion if it should be
added to ghc, the general opinion wasn't too eager so nothing happened.
On Dec 18, 2016 10:30 PM, "Christopher Done"
Short version: here is the poll <https://docs.google.com/forms/d/e/1FAIpQLSdniOfoaX7xflgdWRnjVQ6_ VLtk1oxA00SoK3KPMUsoTSPZDw/viewform?c=0&w=1>
I noticed recently that Foo.Bar.hs is supported by GHC. I had always assumed it wasn't because people always use directories.
I've never liked having separate directories for each level of hierarchy. It's easier to just list a list of files and script (e.g. even copying a file X.hs to Y.hs is a bummer). When opening them on GitHub you have to click through to get a complete picture of a project.
Other languages do and don't do this. Lispers, for example, don't.
How do other Haskellers feel about it? Would it mess with anybody's tooling or mojo if I switched to that style in my packages?
For one I know that Stack (my own implementation), actually assumes hierarchical filenames. So I'd have to patch that to implement this. E.g.
Unable to find a known candidate for the Cabal entry "HIndent.Types", but did find: HIndent.Types.hs. If you are using a custom preprocessor for this module with its own file extension, consider adding the file(s) to your .cabal under extra-source-files.
I suppose the real question is, as a language standard and a community preference, should this be considered a bug? Should people be free to use X.Y.hs or X/Y.hs styles?
Ciao!
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
participants (9)
-
Christopher Done
-
erik
-
eyeinsky .
-
Imants Cekusins
-
MarLinn
-
Merijn Verstraaten
-
Richard A. O'Keefe
-
Serge Le Huitouze
-
Sven Panne