Pure use of this library

[passy]

Feel free to close this and point me to StackOverflow if this is too generic for the issue tracker. I hope I can verbalize my thoughts around this in a somewhat understandable manner.

I was wondering what the correct use of the library would look like with regards to the side-effecting behavior. In my app I took a shortcut and didn't quite realize what the implications of it were that looked like this when breaking it down:

data Input = { name :: String, ... }
data Entry = { id :: UUID, name :: String, ... }

makeEntry :: Input -> Entry
makeEntry inp = do
  let uuid = UUID.runUUID UUID.v4
  in
  { id: uuid, name: inp.name }

Afterwards I saw that I've created an impure function, even though the type signature doesn't give you any hint about it. Which brings me to my question: How would the library be used correctly for cases like this? What are the rules for the context to evaluate runUUID in?

When I try to apply my limited Haskell experience, the right way would be to carry the effect all the way through the chain to the main function, which in Haskell-land would be the only place where you could evaluate the IO type or the UUIDEff.

Does that make any sense?

[joneshf]

I apologize, you got caught out by my poor api design. runUUID really shouldn't exist. More accurately, it should be relegated to an Internal module with clear warning labels. So if you really do need to use it, you can. I can't predict all use cases, maybe it makes sense to have it used in pure code somewhere, or maybe you need to use it in some impure fashion. The point is that it's useful, but it breaks reasoning so it shouldn't be the norm.

As you mention, it allows you to poke holes in things. Also, you are correct that the proper way would be to ensure the uuid generation information is not lost. However, you as a user shouldn't have to think about that in the vast majority of the cases. You should be directed down the right path by default.

So the answer is that the api needs to be rethought. I also feel like this library could be done completely in ps. So I don't think there's much benefit in going too deep into a redesign. But I'd like this library to be useful, as some people may already be using node-uuid somewhere, and just want to access it from ps.

[passy]

Thanks so much for the answer, @joneshf. I'm glad that I wasn't completely barking up the wrong tree.

I agree that completely redesigning the API is probably not the best use of your time. Given that it's just a PureScript wrapper around an existing JS library it does a great job of integrating with the PS ecosystem.

Thanks again!

[joneshf]

I didn't mean to imply that nothing should be done about it. Just that I didn't want to put too much into it.

I'm probably just going to throw that one into an internal module.