schmmd/scala.github.com — comment on commit 60915aa8f77f688adb107c68cea44ddb5ff504b8
File: glossary/index.md line 105
By schmmd:

Hi Heather, I'll try to work something better out in the next few days.

I'm sure you agree that having an entry "for comprehension" that
mentions it's a synonym for the non-existent entry "for expression" is
not good.

The distinction of "for expression" encompassing "for comprehensions"
and "for loops" is useful (and differs from the skimpy entry that
exists in the glossary presently). It is not made in "Programming in
Scala 2ed".

> If you'd like to adjust this "blurb" of text, feel free to adjust it as a comment. When it's good to go, I can just pull this in and manually drop in the adjustment.

I don't understand. I should make a comment with the contents of the
"for expression" entry in the glossary? And you will manually put it
in the glossary index file? How do I make a comment?

Thanks for helping me--I'm new to this.
Peace. Michael

On Thu, Dec 8, 2011 at 3:08 PM, Heather Miller

wrote:
> Hi, thanks for your addition!
>
> I'd be happy to pull in a definition for "for expression", however, as it stands, this doesn't quite fit in with the other entries.
>
> The glossary is meant to be as straight-forward as possible. That said, the approach used mostly throughout is to (a) explain a concept as simply as possible (requiring the smallest number of "dependencies" on other concepts as possible for a user to understand), and (b) to immediately afterwards, provide a simple example.
>
> 1. While it does make sense to explain for expressions in terms of set comprehensions, it's not the simplest, most concise way to explain this concept. It's not the "path of least resistance" to the basic idea, and it would likely throw people off by involving a concept that many might not be familiar with. For that reason, it'd be better if this analogy was left out.
> 2. A for expression can be thought of as either a for loop or a for comprehension (a distinction made in the spec), meaning that it does not necessarily require a `yield`.
> 3. What a for comprehension is translated into is beyond the scope of a simple definition. When one looks up the definition of a for expression, the ideas that should be captured in the definition are the basic semantics and usage of a for expression, not necessarily implementation details. Regardless, for comprehensions also make use of `withFilter` in their translation, which was left out.
> 4. You say for expressions are "also known as" monad comprehensions in Haskell and LINQ in C#, which isn't completely true. These things aren't exactly equal. Regardless, for the same reasons brought up in point 1 above, it would be best if the analogy to monad comprehensions and LINQ was also left out.
>
> Maybe it would make the most sense, so as to communicate the concept as simply as possible, and so as to fit in with the style of the definitions throughout the rest of the glossary, to rephrase the first paragraph of "For Loops and For Comprehensions" in the spec into concise, natural language, perhaps with an example.
>
> If you'd like to work on this a bit, let me know :)
> If you'd like to adjust this "blurb" of text, feel free to adjust it as a comment. When it's good to go, I can just pull this in and manually drop in the adjustment.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/schmmd/scala.github.com/commit/60915aa8f77f688adb107c68cea44ddb5ff504b8#commitcomment-780481