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

Symbols Glossary #1094

Closed
wants to merge 21 commits into from
Closed

Symbols Glossary #1094

wants to merge 21 commits into from

Conversation

zainab-ali
Copy link
Contributor

A first cut of the symbols glossary.
There are still many symbols and links to be added.

@codecov-io
Copy link

codecov-io commented Jun 7, 2016

Current coverage is 88.77%

Merging #1094 into master will not change coverage

@@             master      #1094   diff @@
==========================================
  Files           228        228          
  Lines          3012       3012          
  Methods        2962       2962          
  Messages          0          0          
  Branches         47         47          
==========================================
  Hits           2674       2674          
  Misses          338        338          
  Partials          0          0          

Sunburst

Powered by Codecov. Last updated by 8f94d13...84c5a34

| Symbol | Name | Typeclass | Import | Source |
| ------ | ---------------------- | ------------ | -------------------------- | ------------------------------------------------- |
| `<*>` | apply | `Apply` | TBA | core/src/main/scala/cats/Apply.scala |
| `|@|` | Cartesian builder | `Cartesian` | `cats.syntax.cartesian._` | core/src/main/scala/cats/Cartesian.scala |
Copy link
Member

Choose a reason for hiding this comment

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

Maybe the source location for this should be the generated source file in src_managed?

Copy link
Contributor

@non non Jun 7, 2016

Choose a reason for hiding this comment

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

I also think we could leave out the source location and do pretty well. I'd rather have a column that relates the syntax to the type class, if possible. E.g.

| Symbol  | Name       | Typeclass | Definition | Import |
|---------|------------|----|------------------|----------------|
| x =!= y | not equals | Eq | Eq[A].neqv(x, y) | cats.syntax.eq |

Copy link
Contributor

Choose a reason for hiding this comment

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

I also have mixed feelings about the imports. It is nice to let people know where things are, but I worry that this is encouraging people to use the piecemeal imports, which are often a source of frustration.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@non I agree with getting rid of the imports and having an example usage.

I'm undecided about what to do with the source file. People often want to know where a symbol is defined, but because most of them use simulacrum or macro expansions, there isn't a straightforward location. @DavidGregory084 wouldn't references to src_managed confuse people, as it isn't present on GitHub? Perhaps a link to the source file or syntax file would be better.
I'm leaning towards:

|Symbol    | Name       | Typeclass                                             | Definition |
| -------   | --------  | ------------------------------------------------------ | ------------- |
|  x =!= y  |  not equals  | [cats.kernel.Eq](../../../../cats/kernel/Eq.scala)  | Eq[A].neqv(x, y) |

Copy link
Contributor

Choose a reason for hiding this comment

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

OK, I'm fine with links to the files. In the case of generated sources, maybe we should italicize the name instead of linkifying it, and then putting a note at the bottom that italicized names are from generated source?

Copy link
Contributor

Choose a reason for hiding this comment

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

Would it make sense to link to the scaladoc instead of the source? That should have the generated methods, and it contains a link to the source in the non-generated case.

@zainab-ali zainab-ali changed the title Symbols Glossary - Do not merge yet Symbols Glossary Jun 10, 2016
@zainab-ali
Copy link
Contributor Author

Right, I've added all the symbols I could find. Some points to note:

  1. The links point to the typeclass file, not the syntax file. I thought this would be more clear alongside the function definitions.
  2. Some function definitions differ from the ones in the cats codebase, because the functions in the codebase are on Ops classes. followedBy is an example of this.
  3. I changed the definitions to include argument types and a return type
  4. Not all of the symbols I expected to see were present in the codebase. The <*> on the Applicative is missing, as are the Arrow symbols

I'm also fairly new to functional programming in general, so I may have made some mistakes with the symbol names.

@ceedubs
Copy link
Contributor

ceedubs commented Jun 11, 2016

Thanks for putting so much work into this @zainab-ali! I know symbols can often be a barrier for people, so I really like the idea of trying to clear them up.

I think it'd be really neat if we could somehow inject this data into the symbols scaladoc page -- then we could be sure that it never goes out of date. I don't know if that's actually possible though. Are you aware of that page? It looks like there might be a couple of items on there that aren't in here.

| `x === y` | equals | [`Eq[A]`](../../../../kernel/src/main/scala/cats/kernel/Eq.scala) | `eqv(x: A, y: A): Boolean` |
| `x =!= y` | not equals | [`Eq[A]`](../../../../kernel/src/main/scala/cats/kernel/Eq.scala) | `neqv(x: A, y: A): Boolean` |
| `fa >>= f` | flatMap | [`FlatMap[F[_]]`](../../../../core/src/main/scala/cats/syntax/flatMap.scala) | `flatMap(fa: F[A])(f: A => F[B]): F[B]`|
| `fa >> fb` | followed by | [`FlatMap[F[_]]`](../../../../core/src/main/scala/cats/syntax/flatMap.scala) | `followedBy(fa: F[A])(fb: F[B]): F[B]` |
Copy link
Contributor

Choose a reason for hiding this comment

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

Should these two links go to the FlatMap type class instead of syntax?

@zainab-ali
Copy link
Contributor Author

zainab-ali commented Jun 12, 2016

@ceedubs the symbols scaladoc page looks really useful! I hadn't heard of it before - perhaps it needs to be publicized a bit more? It would certainly be good to put this information there, if possible.

EDIT: It seems to be inbaked in scaladoc itself. Thanks for showing me the existence of such a page! I'll research the possibilities of adding to it.

@zainab-ali
Copy link
Contributor Author

I've hunted around, but I don't think it's possible to inject the data into the scaladoc page. Nevertheless, I've added a link to it.

@non
Copy link
Contributor

non commented Jun 15, 2016

This is great! 👍 Thanks!

@ceedubs
Copy link
Contributor

ceedubs commented Jun 15, 2016

Does anyone have thoughts on #1094 (comment) ?

This has a pretty messy git history (33 commits) for a fairly isolated change. This isn't really the standard procedure, but it might be nice to squash commits here.

@non
Copy link
Contributor

non commented Jun 15, 2016

I'd be fine with squashing the commits. Or not. Either way.

@zainab-ali
Copy link
Contributor Author

Squashing the commits is proving difficult because of the merges in between.
I've created another branch, and am tackling this in PR #1136.

@zainab-ali zainab-ali closed this Jun 16, 2016
@zainab-ali zainab-ali deleted the symbols branch June 17, 2016 22:28
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.

5 participants