The only thing I hate in purescript and haskell - imports (discussion)

Change Proposals
#22

relax a bit and let us find the best way to do a module system

What this even means? I cannot write?

and maybe help us

Am I not doing this?

If you have your own vision - tell me. Right now you sound like a gatekeeper

1 Like
#23

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.

#24

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

#25

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
#26

added a comment to the issue you posted

maybe we need to post it on slack in order to get more votes

I could, but I don’t want to bother, tnx anyway

to try and see if we can move this issue

I have mentioned in comment, let’s see how it goes

#27

Just so you know, this issue is unlikely to get any real maintainer attention until (at the very least) after 0.14 is out.

3 Likes
#28

@srghma My two cents about this detail:

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
1 Like
#29

You pointed out that when you import a module.

import Data.String.Extra

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.

1 Like
#30

sorry for late reply

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.

the same could be possible with import style

import "@contrib/strings-extra" as StringsExtra
  ( Foo(Bar)
  )

just change

purs compile --output output \
  --package @contrib/strings-extra:.spago/@contrib/strings-extra/v9.9.9/src \

to

purs compile --output output \
  --package @contrib/strings-extra:.spago/@my/strings-extra/v9.9.9/src \

though I’m not a fan of this

I would rather import it as

purs compile --output output \
  --package @my/strings-extra:.spago/@my/strings-extra/v9.9.9/src \

and change code everywhere to

import "@my/strings-extra" as StringsExtra
  ( Foo(Bar)
  )

to clearly see that it’s different package