Foo.Bar.hs filenames poll

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Foo.Bar.hs filenames poll

Christopher Done-2
Short version: here is the poll 

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.
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

Haskell - Haskell-Cafe mailing list
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.
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

Sven Panne-2
In reply to this post by Christopher Done-2
2016-12-18 22:29 GMT+01:00 Christopher Done <[hidden email]>:
[...] 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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

erik
In reply to this post by Haskell - Haskell-Cafe mailing list

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" <[hidden email]> 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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

Haskell - Haskell-Cafe mailing list

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

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

Imants Cekusins
In reply to this post by erik
> 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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

Richard A. O'Keefe
In reply to this post by Haskell - Haskell-Cafe mailing list
I thought the use of dotted file names was part of the hierarchical
packages proposal from back when it was a new thing?
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

Serge Le Huitouze-2
In reply to this post by Haskell - Haskell-Cafe mailing list

On Sun, Dec 18, 2016 at 11:25 PM, MarLinn via Haskell-Cafe <[hidden email]> 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


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

Merijn Verstraaten
In reply to this post by Christopher Done-2
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 <[hidden email]> 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.

_______________________________________________
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.

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

Dimitri DeFigueiredo
In reply to this post by Christopher Done-2
I believe it is a mistake to tie the module structure of a software
system to a file structure on a hierarchical file system. I see those
too structures as different entities. Why can't I coalesce two tiny
modules into a single file? I also don't like having to capitalize my
file names (Foo.hs instead of foo.hs) in linux, that seems rather ugly.
It see this "ugliness" as a symptom of the "arbitrarily forced link"
between the module structure and the file structure. Obviously, some
conventions should apply, but a one-to-one correspondence seems too strict.


Dimitri

--
2E45 D376 A744 C671 5100 A261 210B 8461 0FB0 CA1F

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

Sven Panne-2
2016-12-19 17:38 GMT+01:00 Dimitri DeFigueiredo <[hidden email]>:
I believe it is a mistake to tie the module structure of a software
system to a file structure on a hierarchical file system. [..]

I think it's not a mistake, it's the only sane thing to do in the current tooling ecosystem. Try e.g. writing a correct Makefile without a 1:1 correspondence, and you will end up with either something shell-script like or miss some dependencies. As an exercise, try something like this for e.g. Java where there is no 1:1 correspondence between the source files and the build artifacts. OK, the compiler knows the dependencies when trying to compile things, but that is basically the only tool which is 100% correct. But this doesn't really help when writing Makefiles, because you can't even see the e.g. dependencies of a .class file (the compiler inlines e.g. "static final int"s without a trace where they came from). The situation in the Haskell world is not much different: Yes, "ghc --make" knows how to do its task, but integrating this into a project where Haskell compilation is only a part is not easy or ends up in something non-declarative shell-script-like.

To be honest: I can't really understand all of this discussion. It would be great if the status quo of a mapping between hierarchical names and a directory hierarchy would end up in a spec, so it is *the* way to do it. Doing things in exactly one way frees up the mind from figuring out useless details, in this case based only on personal taste. I haven't heard a single compelling *technical* reason for doing it differently up to now... 

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

Haskell - Haskell-Cafe mailing list
On 2016-12-19 18:24, Sven Panne wrote:

> 2016-12-19 17:38 GMT+01:00 Dimitri DeFigueiredo:
>> I believe it is a mistake to tie the module structure of a software
>> system to a file structure on a hierarchical file system. [..]
> I think it's not a mistake, it's the only sane thing to do in the
> current tooling ecosystem.
>
> […]
>
> Yes, "ghc --make" knows how to do its task, but integrating this into
> a project where Haskell compilation is only a part is not easy or ends
> up in something non-declarative shell-script-like.
>
> […]
>
> I haven't heard a single compelling *technical* reason for doing it
> differently up to now...

That's because it's not (purely) a technical issue. I think the
resistance comes mostly from a more philosophical point of view: If we
want our language to remain extensible and at the forefront of language
development, we can't tie down too many parts. That includes our module
system. Granted: the module system is not what the language is known for
right now. But maybe we do want our equivalents to friend classes,
extension classes, or multimethods one day, or we might even find that
there's a natural way to separate "normal" definitions from instance
declarations that is less ugly than orphans or overlapping. Or maybe we
realize that all scopes are basically equivalent anyway, from function
bodies up to whole modules – so why separate them syntactically.

What I'm getting at is not that the mere possibility of such
developments should prevent us from trying to find good mid-term
solutions. But after all, Haskell was originally conceived as a research
language. Even if this type of modularization is not a well-studied
topic and mostly solved in an ad-hoc manner in practice, that shouldn't
prevent us from leaving the door open at least a bit.

The next question then is: How *do* we combine both view points?
Especially, how do we do it efficiently?

> It would be great if the status quo of a mapping between hierarchical
> names and a directory hierarchy would end up in a spec, so it is *the*
> way to do it.

I think the key word here is "a". As in *a* spec, not *the* spec or
*the* report. One spec for each discovery-strategy, easy to find, easy
to reference. That makes it trackable like any other dependency. And if
there is a spec, translating it into code is almost mechanical, and must
only be done once per (tool,spec) pair at most.

Of course I'm simplifying a lot, not least because I'm not a tool-maker.
So this is only how far I can see from my hermit tower at the moment.

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.
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

Carl Eyeinsky
In reply to this post by Christopher Done-2
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" <[hidden email]> wrote:
Short version: here is the poll 

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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

Will Yager
In reply to this post by Haskell - Haskell-Cafe mailing list
On Mon, Dec 19, 2016 at 2:22 PM, MarLinn via Haskell-Cafe <[hidden email]> wrote:
If we want our language to remain extensible and at the forefront of language development, we can't tie down too many parts. 

I think this is an excellent point. One of the distinguishing features of Haskell is that, as a language, it makes almost no concessions to the underlying architecture on which it is compiled or eventually run (and, impressively, manages to achieve very good performance and usability anyway!).

Haskell, among all production languages, is perhaps the only one that would be equally at home on some sort of alien lambda-machine as it would on an x86 processor (i.e. not very, but Haskell's foundations are solid enough that we could make it work well).

More practically, one could imagine that someone might like to use Haskell as e.g. some sort of cloud-based scripting language where the notion of a filesystem hierarchy doesn't make a lot of sense. 

There's no good reason to force the language to adhere to something as arbitrary or restricted as a traditional filesystem hierarchy. "Modules" are a much more general concept than files on a disk, and it would be a mistake to over-specify them.

Cheers,
Will

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

Richard A. O'Keefe
> On Mon, Dec 19, 2016 at 2:22 PM, MarLinn via Haskell-Cafe <
> [hidden email]> wrote:
> There's no good reason to force the language to adhere to something as
> arbitrary or restricted as a traditional filesystem hierarchy. "Modules"
> are a much more general concept than files on a disk, and it would be a
> mistake to over-specify them.

It is already the case that Haskell identifiers (including module
names) are case sensitive, and some popular file systems are not,
making tying to a file system dodgy.

In attempt to solve a similar problem, SGML introduced the idea
of "entities".  SGML chunks are stored as "entities" managed by
an "entity manager" which might or might not be some sort of
file system.  OASIS introduced the idea of "catalogs" which allow
entity names to be mapped in various ways.

I don't see any reason why, for example, a Haskell compiler
couldn't map Foo.Bar.Ugh to Foo.zip(Bar/Ugh.hs) if so directed.


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Foo.Bar.hs filenames poll

Malcolm Wallace-2
In reply to this post by Will Yager

On 19 Dec 2016, at 22:22, William Yager wrote:

> There's no good reason to force the language to adhere to something as arbitrary or restricted as a traditional filesystem hierarchy. "Modules" are a much more general concept than files on a disk, and it would be a mistake to over-specify them.

And this is exactly why Haskell, the language, leaves this open.  There is no forced mapping between module names and their file storage.  That is an implementation matter, left to individual compilers.  In the past, there has been at least one conformant Haskell compiler which allowed multiple modules to live in the same file.  

Regards,
    Malcolm

_______________________________________________
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.