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

Add section on record puns and type synonyms for records #330

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

milesfrain
Copy link
Contributor

No description provided.

Comment on lines +23 to +31
Type synonyms for record types are created with the `type` keyword:

```purs
type Point =
{ x :: Number
, y :: Number
}
```

Copy link
Member

Choose a reason for hiding this comment

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

This is covered later in this documentation, but I suppose it's information worth stating right away. Why not stick with the existing example in this section, though?

It is common to use type synonyms to for records via the type keyword:

type Author = { name :: String, interests :: Array String }

author :: Author
author = { name: "Phil", interests: ["Functional Programming", "JavaScript"] }

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wanted to define Point, since it's used in later examples.

language/Records.md Outdated Show resolved Hide resolved
language/Records.md Outdated Show resolved Hide resolved
@@ -79,6 +88,65 @@ A record update function can also be defined by using an `_` inplace of the reco
_ { fieldName = newValue }
```

## Record Puns
Copy link
Member

Choose a reason for hiding this comment

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

I like this section, but there's some overlap with the language syntax documentation:
https://github.com/purescript/documentation/blob/837ec4ff3a956cdeda31997bf5f697ee738295b6/language/Syntax.md#additional-forms-with-records

I think we should merge that content into this file and then update the language syntax file to link here. It makes more sense for that content to be in this section and just a link be in that file.

Copy link
Member

Choose a reason for hiding this comment

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

I think that file has good content and it could be used to inform what you've written here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

there's some overlap with the language syntax

I'm not seeing any "Record Pun" examples in Syntax.md, but I agree that there are duplicated themes across Records.md, Syntax,md, and Pattern-Matching.md.

Whether this should be reorganized seems like a bigger discussion. Maybe something to tackle as part of #344

So for now, I'm thinking we should hold-off on making changes across multiple files.

language/Records.md Outdated Show resolved Hide resolved
@thomashoneyman
Copy link
Member

As a side note, I think the Kinds section in here could use a little extra clarity. Specifically, I'm thinking of something like:


{ ... } is syntactic sugar for the Record type constructor. This type constructor is parameterized by a row of types:

-- these types are equivalent
type Language = { language :: String }
type Language' = Record ( language :: String )

A Record is constructed from a row type and represents a product type in which all fields in the row type are present. Using kind notation, Record has the kind # Type -> Type -- that is, it takes a row of types and produces a type.

Because ( language :: String ) denotes a row of types (and therefore has the kind # Type), it can be passed to the Record constructor or to the { ... } syntax for Record to construct a type:

type LanguageRow = ( language :: String ) -- has kind # Type

-- these are equivalent
type Language = Record LanguageRow
type Language' = { | LanguageRow }

@milesfrain
Copy link
Contributor Author

Applied all suggestions except for moving content from Syntax.md to Records.md. I think that would still be good to do as a separate PR. Opened #368 to follow-up.

@JordanMartinez
Copy link
Contributor

This PR hasn't been merged because this is likely useful, but has a few additions that are undesirable / repetitive

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