Skip to content

Rewrote higher-order-functions #699

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

Merged
merged 5 commits into from
Dec 12, 2017

Conversation

travissarles
Copy link
Contributor

No description provided.


Higher order functions take other functions as parameters or return a function as
a result. This is possible because functions are first-class values in Scala.
One of the most common examples is the higher-order
Copy link
Contributor

Choose a reason for hiding this comment

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

examples (without “s”).
Or, I would just say “A common example …”

Choose a reason for hiding this comment

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

Hmm.. maybe I'm missing something but just so it's clear One of the most common examples with the s is the correct English.

That said, you can certainly say A common example...

Since the Scala compiler already knows the type of the parameters (a single Int),
you just need to provide the right side of the function. The only
caveat is that you need to use `_` in place of a parameter name (it was `x` in
the previous example).
Copy link
Contributor

@julienrf julienrf Feb 16, 2017

Choose a reason for hiding this comment

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

Why is this a “caveat”?

Maybe a more intuitive way to describe the _ * 2 syntax is to say that _ means “a hole”, thus the expression _ * 2 means “something (that has to be filled in), multiplied by two”

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've heard the hole metaphor used before and I don't think it's used outside of Scala documentation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But yes, it should be reworded.

Copy link

Choose a reason for hiding this comment

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

Just use "difference" instead of "caveat".
If you want to make it more clear, you could also add Julien's explanation but call it a "slot" that has to be filled.

[7]

The new function, `promotion`, takes the salaries plus a function of type `Double => Double`
(i.e. a function that takes a Double and returns a Double) and returns the product.
Copy link
Contributor

Choose a reason for hiding this comment

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

What do you mean by “returns the product”?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it returns the product of the current salary multiplied by a factor. I guess it could be clearer to say it returns the new salary.

```tut
object SalaryRaiser {

private def promotion(salaries: List[Double], promotionFunction: Double => Double): List[Double] =
Copy link

Choose a reason for hiding this comment

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

This is a poor example because the resulting code is more verbose and harder to follow. Abstraction in examples should lead to a very clear win to help motivate the feature.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Ichoran I agree with that point. Can you think of a better example?

Copy link

Choose a reason for hiding this comment

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

Maybe do something with case class Point(x: Double, y: Double) and def closestBy(points: List[Point], target: Point, metric: (Point, Point) => Double? Then you can have closestByDistance(points: List[Point], target: Point) = closestBy(points, target, (p, q) => (p.x - q.x)*(p.x - q.x) + (p.y - q.y)*(p.y - q.y) and for closestByBlock math.abs(p.x - q.x) + math.abs(p.y-q.y) and so on.

Whatever you choose, the key should be that the work of the common function shouldn't be completely trivial (i.e. it should be more than just one other method call!).

Copy link
Contributor

@julienrf julienrf Feb 22, 2017

Choose a reason for hiding this comment

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

@Ichoran Yeah, nice example! @travis032654 Maybe we can also mention that this is an application of the Strategy design pattern, do you think that would help enterprise programmers to get it?

of a method that returns a function.

```tut
def urlBuilder(ssl: Boolean, domainName: String): (String, String) => String = {
Copy link

Choose a reason for hiding this comment

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

This is not a good example because you would almost never see this. Instead, you'd just write urlBuilder(ssl: Boolean, domainName: String): String and get the function above with urlBuilder _.

@travissarles travissarles mentioned this pull request Mar 17, 2017
33 tasks
@travissarles travissarles self-assigned this May 10, 2017
@SethTisue SethTisue merged commit ffe9959 into scala:master Dec 12, 2017
@SethTisue
Copy link
Member

There was some good feedback on this that never got addressed, but it's still an improvement, as-is, so I figure hitting "merge" is better than just letting it languish forever. I invite anyone watching the repo to submit a followup PR with further improvements, whether suggested by reviewers here or otherwise.

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.

6 participants