After seeing Harry’s issue, I’ve moved to the dark side. If we’re gonna replace the Data prefix and its fellows, I’m all for it. I was originally against it because @srghma’s code sample has a lot of repetition in its imports. So you may want to change your example @srghma.
Shifting to your proposal would break my repo’s syntax folder as Syntax.Basic.01-Learn-Foo isn’t a valid module name. If hyphens were dropped and numbers could be included, it would no longer be a problem.
I want to also add this post that saw about 4 months ago complaining about package, and I do agree with what the author’s argument here. I also like a lot of some of the points that @hdgarrood pointed in his github issue.
Looking at the issue, there seems to be a solution for most cases except for some possible edge cases that we might be missing. Now, I feel there is a bit resistance when it comes to aesthetic and also not wanting to be aware of the package when importing modules.
Personally, I think that the voting system that @srghma is proposing is good first step. If we don’t vote on it will just be another floating issue. I think that it’s important that we agree about the package system earlier on before 1.0 - whether you like or not its important that it’s clear early on.
Would it not be better if we collect all the points in this post and then create a separate post for votes? Of course, the voting post would display all the points.
I think we can get most of the benefit of package-qualified imports by requiring, that published packages have the top-level module be the package name.
Data.Functor from purescript-prelude would become Prelude.Data.Functor
etc.
Some packages already do this: Affjax.RequestBody from purescript-affjax is already Affjax.RequestBody
That way we don’t need to break all purescript code, but still get the benefits
We started on this path already, although admittedly we didn’t go very far down it - this is why Effect lives in a module just called Effect rather than Control.Monad.Effect or whatever. I am not such a fan of this approach though, because it doesn’t solve the issue as neatly, but it would still be more or less equally big a breaking change as changing the language - if the majority of the libraries you depend on have breaking changes (renaming a module is a breaking change) that can be just as disruptive as the language itself having a breaking change.
The problem with a rule about translating package names to module names is that the translation isn’t always obvious and we would need tooling to enforce the convention if it was going to catch on. For example, a module in the strings-extra should be StringsExtra.Whatever, not Strings.Extra.Whatever, but the latter style is already common for extending an existing library, so I’m sure people would keep using that style unless we had tooling telling them not to.
@srghma, it sounds like you’re in hurry with this. Why are you? If you like this solved then just starting discussion like this is kind of a great thing and you’re welcome to do so. Though you could relax a bit and let us (and maybe help us) find the best way to do a module system that we know of at the moment.
I had difficulty expressing it. I think it should have been “we’ll figure out”. That DuplicateModule -error needs to go like you said in the start. Btw. Albert Y. C. Lai told me a potential known solution to it and I would have not known to ask if you had not written this post.
I have no vision about this one. However I see that you hate what Purescript offers you right now with module/import declarations, and I do not hate it as much.
Why I’m unable to hate purescript’s module/import system is because I know this problem is very hard, and that purescript community figures out how to do it right eventually. Who knows perhaps you’ll figure it out, at least you’ve helped it out.
Well… I have one thing to say. That you don’t see implementation names in the import declarations might be a feature, given that your problem with them is solved. Those things separate the interfaces from their implementations. This could be useful since purescript has multiple target platforms, Javascript is only the one of them.
@srghma I found this issue https://github.com/purescript/purescript/issues/3493 in the “Intend to Implement” section, I think that it’s related. I see that a few have already voted, maybe we need to post it on slack in order to get more votes.
The next step is to understand in detail the changes needed - I think that it will help the maintainers or whoever is capable of implementing and it will keep this issue from just floating.
Since I am not too sure of the procedures myself, a goal that seems realistic to me is to try and see if we can move this issue to a stage where there is a potential agreement based on the vote and the details that the maintainers/implementer might need.
That you don’t see implementation names in the import declarations might be a feature, given that your problem with them is solved. Those things separate the interfaces from their implementations.
could you explain more
This could be useful since purescript has multiple target platforms, Javascript is only the one of them.
I cannot imagine a language that couldn’t support
import "@noname/other-strings/String" as OtherString
I always hated the directory structure
…
and wanted to write about
Since PureScript doesn’t enforce module names matching the directory structure, you can actually have whatever structure you want. For example, you could have the Default.purs file under Foo/, but write module Foo where at the top of that file.
Personally, I’ve been using structure like this:
| Foo/
| Foo.purs -- module Foo where
| Foo1.purs -- module Foo.Foo1 where
| Foo2.purs -- module Foo.Foo2 where
| Bar/
| Bar.purs
| Bar1.purs
| Bar2.purs
Then you’d have to do spago install strings-extra but it requires you to remember this and I agree this is an annoying thing having to recall.
Ok. I’ll explain more about the interface/implementation separation.
If you have function, eg. camelCase :: String -> String, this is an interface that lives in Data.String.Extra
The strings-extra is an implementation, a means to fill up the module Data.String.Extra. However something else can do this fill-in as well.
This is a generic system and if we look at something else like DOM interface or alternatively SDL or OpenGL. Depending on your target platform, different libraries might fill these up, or same library need to be configured differently.
Now I do not know if you’re right and we should just do it your way. Your proposed syntax at least could coexist with the old syntax.