Create a section/wiki page for unfamiliar or potentially confusing notation

[danbernier]

Thank you for putting this together! I've been studying functional programming on and off for years, and this has reinforced some of the concepts I've learned, clarified others, and taught me new ones. Very nice work.

As I was reading, I came across two notation idioms that confused me, that I'm pretty sure have nothing to do with FP:

• The symbol ≍ (which is a black box on my Android, fwiw). From googling, I think it means either logical equivalence, or just equivalence. Not being a mathematician, I'm not sure which it is, and what, specifically, the differences between those are. I can guess why it's preferred over = (which means assignment), but I'm not completely sure why it's different from === (I'm also not a JavaScript expert).
• This pattern: ;[1] I'm guessing it means: here's a plain value? and that it's written that way, because of the linter?

Anyway, these details can confuse, and like I said, they're not about FP, so I was thinking it might be nice to have a section, or a wiki page, for them - almost like the sections at the front of many programming books, where they explain how code sections are formatted, that kind of thing. I'm happy to create a wiki page, but I don't know the explanations for either ≍ or ;[1].

[FlorianWendelborn]

@danbernier ;[1] is most likely due to not using semicolons. Browsers won't automatically detect that the line ended when you start it with [.

[danbernier]

Thanks @dodekeract! That's exactly the kind of useful info I'm looking to collect.

[jethrolarson]

=== or == aren't correct since they both deal with reference equality. Mathematically two lists are equal if they contain the same items in the same order. However two arrays may be equivalent even though they're different references. You're right to point out that we don't explain the symbol. Would you rather we explain the symbol or use english? E.g. `xs.map(x => f(g(x)))` is equivalent to `xs.map(g).map(f)`

…

On Sun, Jan 1, 2017, 10:14 AM Dan Bernier ***@***.***> wrote: Thanks @dodekeract <https://github.com/dodekeract>! That's exactly the kind of useful info I'm looking to collect. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#135 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB-4LKafv2IEBUtgbsS8frg6Sa76Cc5ks5rN-0EgaJpZM4LYvWZ> .

[danbernier]

I'm all for using the symbol, since it expands the language by standing in for a specific, precise notion. But let's explain that notion somewhere, for those who are unfamiliar with it. ~ This message was made with 100% thumbs.

…

On Jan 1, 2017 9:27 PM, "Jethro Larson" ***@***.***> wrote: === or == aren't correct since they both deal with reference equality. Mathematically two lists are equal if they contain the same items in the same order. However two arrays may be equivalent even though they're different references. You're right to point out that we don't explain the symbol. Would you rather we explain the symbol or use english? E.g. `xs.map(x => f(g(x)))` is equivalent to `xs.map(g).map(f)` On Sun, Jan 1, 2017, 10:14 AM Dan Bernier ***@***.***> wrote: > Thanks @dodekeract <https://github.com/dodekeract>! That's exactly the > kind of useful info I'm looking to collect. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/hemanth/functional-programming-jargon/ issues/135#issuecomment-269913277>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAB- 4LKafv2IEBUtgbsS8frg6Sa76Cc5ks5rN-0EgaJpZM4LYvWZ> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#135 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAzFTbjFoc55Ctz57zheiocFbr-hzwLks5rOGCZgaJpZM4LYvWZ> .

[danbernier]

I found issue #46, which seems to speak to the equality question; linking it here for completeness' sake.

Would still love to see a section for this.