Skip to content

Conversation

i-am-tom
Copy link

@i-am-tom i-am-tom commented Apr 9, 2017

Hello!

This is the Number equivalent of Data.Int.fromString. Hope this is ok! I've added tests to the suite, too.

PS: I looked at the process of re-uploading packages, and, while I think I probably can do it, it would result in me being registered as the package uploader. Not quite sure what the repercussions are, so I'm going to run away and leave it to you. Probably being silly, but best to be safe.

The Data.Int.fromString equivalent for Number. Tests have been provided,
as well as code documentation.
@sharkdp
Copy link
Collaborator

sharkdp commented Apr 15, 2017

Thanks you very much!

This looks very good. I'll add a few inline comments.

-> Maybe Number


-- | Attempt to parse a Number from a String using JavaScript's parseFloat.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably specify when to expect a Nothing result here.

return function (string) {
var result = parseFloat(string);

return isNaN(result) ? nothing
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe isNaN is not enough here, because parseFloat can also return Infinity (for inputs like 1e1000). isFinite would be a better choice, I think.

Thinking about this, it would be very cool to have isNaN and isFinite available in purescript-numbers. Then, fromString could also be implemented in PureScript.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed on Infinity, will amend now. Interestingly, PureScript's core libraries tend to take the stance that NaN/Infinity is "undefined" behaviour. I wonder what @paf31 would think of isNaN and isFinite existing in PS.

test "invalid number string" do
assert "invalid strings are not coerced" $
fromMaybe true $ false <$ fromString "bad string"

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding tests, too! Could you also add a test for an input like 1e1000?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, will do :)

@i-am-tom
Copy link
Author

Going to close this PR as I think that, aside from the edge checks, this is all already implemented in Global. Now that I've seen Global, this kinda feels like duplication of effort :(

@i-am-tom i-am-tom closed this Apr 15, 2017
@sharkdp
Copy link
Collaborator

sharkdp commented Apr 15, 2017

Going to close this PR as I think that, aside from the edge checks, this is all already implemented in Global.

I knew that, but I thought that your version was still very useful.. precisely due to the checks. Something similar was also asked for in purescript-deprecated/purescript-globals#5

Now that I've seen Global, this kinda feels like duplication of effort :(

Hm, .. we could still use the unsafe readFloat from Global.

Interestingly, PureScript's core libraries tend to take the stance that NaN/Infinity is "undefined" behaviour.

Yes, but there are situations where we cannot avoid getting NaN or Infinity if we are calculating with the bare Number type (division by zero, out of bound errors in Math functions, ..). Therefore, I believe that having isNaN or isFinite would still be very useful. What do you think?

@sharkdp
Copy link
Collaborator

sharkdp commented Apr 15, 2017

See purescript/purescript-integers#17 for another related discussion.

@sharkdp sharkdp reopened this Apr 15, 2017
@sharkdp sharkdp merged commit b879e9e into purescript:master Apr 16, 2017
@sharkdp
Copy link
Collaborator

sharkdp commented Apr 16, 2017

I went ahead, merged this and re-implemented it using the methods in Global.

Again, thank you very much!

@i-am-tom
Copy link
Author

Oh, wow! Sorry, I'd gone to bed, hah! No problem - thank you very much, too!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants