Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove array allocation and local array ffi from the Show instance for records #299

Merged
merged 3 commits into from
Aug 17, 2022

Conversation

ajnsit
Copy link
Contributor

@ajnsit ajnsit commented Aug 16, 2022

Description of the change

Removes array allocation from the implementation of show for records, and also consequently, removes the need for local ffi implementations of array functions just to show records.


Checklist:

  • Added the change to the changelog's "Unreleased" section with a reference to this PR (e.g. "- Made a change (#0000)")
  • Linked any existing issues or proposals that this pull request should close
  • Updated or added relevant documentation
  • Added a test for the contribution (if applicable)

@ajnsit ajnsit changed the title Don't allocate an array to show a record Remove array allocation and local array ffi from the Show instance for records Aug 16, 2022
Copy link
Contributor

@JordanMartinez JordanMartinez left a comment

Choose a reason for hiding this comment

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

Correct me if I'm wrong, but can't this code...

show record = case showRecordFields (Proxy :: Proxy ls) record of
  "" -> "{}"
  r -> "{ " <> r <> " }"

be simplified to just

show record = "{" <> showRecordFields (Proxy :: Proxy ls) record) <> "}"

if the implementation is updated to the following?

Copy link
Member

@garyb garyb left a comment

Choose a reason for hiding this comment

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

Nice 👍

@@ -20,6 +23,9 @@ import Type.Proxy (Proxy(..))
class Show a where
show :: a -> String

instance showUnit :: Show Unit where
show _ = "unit"

Copy link
Contributor

Choose a reason for hiding this comment

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

Could you clarify why this change was also made? And I guess the question is, should it be made?

Copy link
Member

Choose a reason for hiding this comment

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

Same question for Void actually - maybe an earlier iteration of this change needed these in scope for its implementation?

Since all this is in the same library I guess it doesn't matter too much, but the general principle I used years ago when we split the Prelude into modules, was that only instances for Prim types or those that were unavoidably depended upon are introduced in the class module, otherwise they were introduced with the type.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was needed to avoid cycles in the import tree. I needed the semigroup instance for strings inside the show module, but Data.Semigroup depends on Data.Void and Data.Unit, which in turn depended on Data.Show for defining their show instance.

The rationale for why I resolved the cyclic imports this way is - by removing typeclass dependencies from "core" data structures like Unit and Void, we can trivially ensure they never cause cyclical imports and any typeclasses can always import the data structures. This way we only need to organise and resolve potential cyclical imports between typeclass modules like Data.Show and Data.Semigroup.

Copy link
Contributor

Choose a reason for hiding this comment

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

Gotcha. Thanks for clarifying!

@JordanMartinez JordanMartinez merged commit 916e009 into purescript:master Aug 17, 2022
@ajnsit ajnsit deleted the aj/optimise-show-record branch August 17, 2022 14:43
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.

3 participants