Chapter 6: Underscore notation for property accessors used without previously being introduced

[shaunplee]

The Functional Dependencies section of Chapter 6 uses underscore notation for an accessor to the tail property of a Stream:

genericTail xs = map _.tail (uncons xs)

Grepping the text of the book, this appears to be the only place where this syntax is ever used (there's a match in Chapter 1 with the JavaScript example of _.chain(_.range(1000)), but that's not the same thing).

While the syntax is infrequently used in the book, readers may encounter it in other code, and it might be helpful to introduce this syntax when discussing Records in Chapter 3, specifically in after the section on how fields of Records can be accessed using a dot.

An additional suggestion would be to modify findEntryByStreet exercise (or add a follow up exercise) to suggest that the predicate supplied to filter could be expressed as the composition of an accessor function using the underscore notation and a test for equality, like:

(==) street <<< _.address.street

[milesfrain]

it might be helpful to introduce this syntax when discussing Records in Chapter 3

That sounds good. We could also link to the reference docs for readers to learn more about how to interact with records. https://github.com/purescript/documentation/blob/master/language/Syntax.md#property-accessors

modify findEntryByStreet exercise (or add a follow up exercise)

This sounds good too.

I notice we don't cover operator sections shorthand either. I actually thought _. for records was just a special case of this technique, but they appear to be separate concepts. This could be a nicer way to introduce flip. Shared a proposal in #260 (comment) .

I think a general dilemma is how much content should be duplicated across the different learning materials. I'd ideally like to just have one comprehensive description of syntax in our language reference that we focus our efforts on, which the book can point to as necessary. But we don't want the language reference to inconvenience experienced users with long-winded explanations tailored for beginner audiences. I think there's a way we could achieve both though with a brief summary, followed by further elaboration and examples.