Restricting valid characters in infix operators

[Evan Czaplicki]

Context

In Elm 0.18, the following characters are valid:

• +-/*=.$<>:&|^?%#@~!
• Anything from Sm, Sc, Sk, and So thanks to using Haskell's isSymbol

With the new parser, I restricted the set of valid characters to:

• +-/*=.<>:&|^?%#~!
  

So that cuts out $, @, and all the unicode symbols.

Thoughts on Infix Operators

The official advice on infix operators is avoid infix operators. The big point here is that they are "siren" design choices in 99% of cases. They seem great until you find yourself reading someone else's code and it's all weird nonsense symbols.

I have found that the best symbols are ones that exactly mirror commonly known symbols. So + and / are nice because everyone knows them from math class. The (</>) and (<?>) operators from url-parser exactly mirror the / and ? symbols in URLs. (|>) also makes sense visually and matches pipes in unix which are somewhat known.

I regret many of the operators I have put in Elm, especially when the visual meaning is weak. That's why (<~) and (~) were removed, and I have mixed feelings about (!)

These thoughts are important in the following section.

Reasons for Restrictions

Unicode Symbols

I think it is crazy to allow all those unicode operators. Having crazy operators is bad enough, but it's even worse if you cannot even type them. I suspect most folks didn't know this was possible, and I have never seen them in use anywhere.

Dollar Sign

First, the concept of dollars has no compelling interpretation as an operator. It is not an operation like + in math or separator like / and ? in URLs. It just means dollars, so I don't feel it has a niche at all as an operator based on the prevailing cultural meaning. In fact, it's worse because you need to unlearn what it already means.

The $ symbol adds a ton of visual noise, unlike simpler symbols like < and +. So symbols that appear commonly in Haskell, like $ and <$>, not only reject the prevailing meaning of $, they are much more visually jarring. So <-> and <+> and <|> and |+| all look much nicer than anything with a dollar sign.

About Visual Noise: I suspect a programming audience to be skeptical of this concept, but it is a true observation that + is a simpler symbol than #. Mixing curves and lines, having intersecting lines, and having no relationship to normal shapes like circles or squares makes $ quite crazy. Learn about futura for a modern example of how mimicking geometry leads to nice results. This theory goes back to carved Roman characters, which also imitated squares, circles, and triangles. Platonic shapes!

At Sign

The @ sign is actually pretty commonly used in macro systems. You can see that in this survey of macro systems. So I think it makes sense to reserve such that the existing cultural meaning within programming is respected, even if it is never used by Elm.

It is also pretty visually noisy, especially in a monospaced font. Not as bad as $ though. (All curved lines, shaped like a circle, no weird intersections, but still lots of ink.)

More About Visual Noise: I also considered dropping % and # because of how noisy they are. But I think it's worth keeping (%) because it means mod in so many languages and I was kind of on the fence about #. It does not have any legitimate operator meaning I can think of though, and I don't know of any compelling uses in any language.

Conclusion

I'm pretty satisfied that the reasoning for each of these cases is sound, but I'm curious if folks have any practical or factual concerns that have not been addressed.

For the purpose of decision making, I am interested in your gut opinion only to the extent that I trust your design sense. That said, it is valuable to preview those emotions before this idea reaches a broader audience.

[Max Goldstein]

It may be remotely possible to use $ in a way related to actual currency, but it would be unary -- so yeah, I agree with you to leave it out. Also, it would be weird not to also allow the symbols for the pound, euro, yen, rupee, and so on.

The only meaning of # that I'd feel comfortable adopting is to start a comment (Ruby, Python, Bash, CoffeeScript, probably a few others). Adopting it over -- would mostly be change for change's sake at this point, though you could argue that -- invokes var-- from C-family languages. It would probably be the "least surprising" choice for comment symbol, but would break a lot of code. It might be feasible if elm-format could handle it automatically, but I'm still meh on the idea.

There's precedence within Elm for @ as a macro: @docs annotations, which insert documentation in a very macro-like way. I've never been a fan of @param and @return doc-ing everything, but if we were to do so, that's the symbol to use. Might as well keep it out of the code so it stands out in comments.

I guess my biggest objection is that this would be a breaking change, and should probably be called 0.19 instead of 0.18.1 (even though technically you can do whatever you want pre-1.0).

[Evan Czaplicki]

About the version, this change already needs to be major based on making ( + ) with spaces illegal. So independent of the operator restrictions, I think the only reasonable way to release this is to bundle the new parser with changes that more obviously justify 0.19. Let's not get into that more in this thread though.

Your comment inspired me to thing through # a bunch more, and I'm thinking it is probably better to get rid of it as well. It appears in SML and Clojure and Haskell, but it has no consistent meaning in those settings. It also means "hashtag" now for a lot of folks, so one could argue that it is a unary operator :P

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/1d0c94f3-e94b-47f5-87db-a9b1fcc13d11%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Hamburg]

Trivia: Oberon uses (used?) # as the inequality operator.

[Mark Hamburg]

The use for hash tags does suggest using # as an indexing operator for dictionaries but I don't know that it would read all that well.

One use case that it does work well for is that in Lua it is an unary operator giving the length of a table. (The fact that the Oberon usage came to me first says something about my caffeination level this morning.) Example usage includes:

for i = 1, #array do
print( array[ i ] )
end

array[ #array + 1 ] = x -- Lua indexes from 1

Whether these uses have a natural correspondence in Elm, I don't know and as noted above I'm probably insufficiently caffeinated to say at this point. The one thought this raises for me is that if Elm were to embrace arrays more fully as an alternative to lists, then having a standard append operator might be useful but I don't know that # would be the right choice.

Mark

[Maxime Dantec]

I've taken the liberty to \cc Bogdan Popa, I'm really fond of his parser library (and I believe I'm not the only one), so I guess it's up to him to defend the dollar if he still wants it in his parser library.

As a reminder, the change would deprecate that function:

http://package.elm-lang.org/packages/Bogdanp/elm-combine/3.1.1/Combine#<$>

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

[Yosuke Torii]

I've taken the liberty to \cc Bogdan Popa, I'm really fond of his parser library (and I believe I'm not the only one)

I agree. As far as I know, elm-combine is the best parser combinator library. I used it several times and the infix operators look so nicely. I personally don't think $ is very noisy, but if $ disappears, I'm curious what is the best alternative for it.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/a6c75f10-bece-432b-af12-87d511db7c1b%40googlegroups.com.

[John Watson]

I use Bogdan's parser extensively, and make very extensive use of the dollar operator, which is now an old friend.  I would not be happy to see it go.

[Thomas Weiser]

Evan, I follow your argument about the At sign, but not about the Dollar
sign.

As many others I use Bogdanp/elm-combine. A parser library is one the
the few cases, where infix operators are really useful. It's some way of
a DSL you have to learn anyway, with or without infix operators, but for
larger grammars it's nicer with infix notation.

I don't think it's worth to break code using <$> solely for typographic
arguments (that may not be followed by everyone).

On 19.12.2016 16:57, John Watson wrote:
> I use Bogdan's parser extensively, and make very extensive use of the
> dollar operator, which is now an old friend. I would not be happy to
> see it go.
>
> On Monday, 19 December 2016 15:24:14 UTC, Maxime Dantec wrote:
>
> I've taken the liberty to \cc Bogdan Popa, I'm really fond of his
> parser library (and I believe I'm not the only one), so I guess
> it's up to him to defend the dollar if he still wants it in his
> parser library.
>
> As a reminder, the change would deprecate that function:
> http://package.elm-lang.org/packages/Bogdanp/elm-combine/3.1.1/Combine#

> <http://package.elm-lang.org/packages/Bogdanp/elm-combine/3.1.1/Combine#><$>
>

[Evan Czaplicki]

Thank you Yosuke for providing a code example!

I would like to suggest some alternate operators that would simplify the set of operators in elm-combine quite significantly.

(|=) : Parser (a -> b) -> Parser a -> Parser b

(|.) : Parser a -> Parser b -> Parser a

These two operations would take the place of (<$>) and (<*>) and (<*) and (*>), so Yosuke's code would become the following:

property : Parser s AST

property =

  lazy <| \_ ->

    succeed Property

      |. spaces

      |= propertyKey

      |. spaces

      |. equal

      |. spaces

      |= expression

      |. spaces

The idea is that you take the things with an equals sign as an argument, and you ignore things with a dot. The visual theory is that (1) the vertical bar creates a nice visual grouping, (2) both operators should be the same width, and (3) the "keep" operator should be more visually noisy so it is easy to pick out.

I personally think this code is a lot nicer than the (<$>) and (<*>) code that is typical in Haskell. I never know the precedence of (<*) and (*>) so I avoid those. Now that problem doesn't exist.

Now, I am not suggesting these two symbols for immediate use! The point is merely that whether we have the dollar sign or not is not such a big deal, and I think we can do a better job than Haskell if we take their decisions as a data point, not revealed truth.

Do not start changing libraries on account of this discussion yet! I would like to let these ideas sit and percolate for a while. Maybe we can come up with something better. The release of the new parser will be the forcing point when decisions must be final, and I don't think any libraries should change until that time.

Note: I think it'd also be good to lose some other operators in elm-combine. If you check out the new parser code in the compiler, you will see that (<|>) and (<?>) do not exist at all. Instead, you say things like this:

expecting "literal" (oneOf [ string, char, number ])

I think this much easier to read and refactor. If you have big chunks in the oneOf, the multiline list still is nice to read. I also like that there are no precedence riddles with this approach. For example, adding (<?>) to a single entry vs the whole thing leads to very different error messages.

Between these two suggestions, the library would go from 9 operators to ~3, and I think that'd be good.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/d7a2aef9-04d3-6092-2068-e6e4715bc52b%40thomasweiser.de.

[Fedor Nezhivoi]

Sorry if I am missing something, but why not just skip infix operators entirely in this case? Can't we just have Parser.ignore and Parser.keep (names could be better ofc) and use them with |> operator?

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/d7a2aef9-04d3-6092-2068-e6e4715bc52b%40thomasweiser.de.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAF7GuPH9PeTB7F_Bgq1tsNbM5ujkDjSHXD6PA8hawPXTu%3DmrYQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Best regards,

Fedor Nezhivoi

[Evan Czaplicki]

Fedor, yeah, that's another way to go! More in the style of elm-decode-pipeline, which is quite nice. I'd take that as another data point that $ can actually lead folks away from nicer designs.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/d7a2aef9-04d3-6092-2068-e6e4715bc52b%40thomasweiser.de.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAF7GuPH9PeTB7F_Bgq1tsNbM5ujkDjSHXD6PA8hawPXTu%3DmrYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Best regards,

Fedor Nezhivoi

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAL91TZgq-_dfGD7tGQvpOaQdGAJuDXUNE5tpnEw_z6mTzBEMAw%40mail.gmail.com.

[Bogdan Popa]

They seem great until you find yourself reading someone else's code and it's all weird nonsense symbols.

At which point you go ahead and read the documentation (or look it up using your favorite editor -- Emacs does this reasonably well *wink wink nudge nudge*) and learn what those "weird nonsense symbols" do.  Better yet, those "weird nonsense symbols" are likely to be a part of a conventional set of symbols because library authors tend to borrow from each other so once you learn what <$> does in library A you'll probably know how to use it in library B if it's present. You also have the option of not using said library.

First, the concept of dollars has no compelling interpretation as an operator. It is not an operation like + in math or separator like / and ? in URLs. It just means dollars, so I don't feel it has a niche at all as an operator based on the prevailing cultural meaning. In fact, it's worse because you need to unlearn what it already means. 

Abstract symbols take on the meaning we assign to them. + has no inherent meaning but we give it one in algebra. / and ? do have specific meanings (though, again, not inherent) in English (and in Maths in the case of /).  Are these two somehow special? Why don't they need to be unlearned? You keep making this argument, but I've yet to see any evidence in favor of it. In my experience people (that includes beginners!) are not nearly as stupid as you make them out to be.

The $ symbol adds a ton of visual noise, unlike simpler symbols like < and +. So symbols that appear commonly in Haskell, like $ and <$>, not only reject the prevailing meaning of $, they are much more visually jarring. So <-> and <+> and <|> and |+| all look much nicer than anything with a dollar sign.

Are you seriously trying to pass this off as objective reasoning? What about &? By this argument & is also as visually jarring as $ if not more (let's not even begin to talk about *). Why not drop & in favor of an and keyword if you're seriously going to push this particular argument? Do that and I might believe that you're not just searching for reasons to purge operators you don't like from the language.

I'm pretty satisfied that the reasoning for each of these cases is sound, but I'm curious if folks have any practical or factual concerns that have not been addressed.

All subjective reasoning can appear sound given a particular bias. Practically speaking, these operators

• are seeing real world use,
  
• form a consistent algebra,
• are effin' nice to use (your proposed replacements don't even come close to being as expressive or convenient despite being just as abstract).

I have yet to receive a single complaint that these operators are somehow too complicated and elm-combine is one of the most popular operator-heavy Elm libraries. OTOH, what I have received from people is praise and thanks.

For the purpose of decision making, I am interested in your gut opinion only to the extent that I trust your design sense. 

This is a spectacularly arrogant statement, but I'm glad you've finally come out and said it since it falls in line with what I've previously said about these decisions of yours.

Lastly, I know sounding like a broken record but your effort to continually make the language better for beginners is actively hurting intermediate and advanced users. People don't like breaking changes in genera. They especially don't like breaking changes that are made on a whim and with no clear benefit.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/d7a2aef9-04d3-6092-2068-e6e4715bc52b%40thomasweiser.de.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAF7GuPH9PeTB7F_Bgq1tsNbM5ujkDjSHXD6PA8hawPXTu%3DmrYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Best regards,

Fedor Nezhivoi

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

[Maxime Dantec]

Just to be clear, I wasn't aware of any tension and I wasn't trying to put oil on fire. At the end of the day we all want the same thing :) 

I feel for both of you. It must be exhausting for Evan to have dramas every time he wants to push some changes, no matter how insignificant it is. And it can also be exhausting for Bogdan to maintain libraries when there are several breaking changes on each version, no matter how easy the upgrade can be.

I have no solution. From my perspective, elm-combine being the first package on the website might be a little confusing for beginners and it probably shouldn't, but it's really not that complicated, and if $ is removed then Bogdan will probably switch operators but it will not change much for beginners.

[Bogdan Popa]

Don't feel bad! I'm subscribed to elm-dev and had seen this yesterday before you cc'd me but didn't have time to reply. :)

I wouldn't call this drama as I think some level of pushback on breaking changes is to be expected given the time that some of us have invested in the language. My tone was perhaps overly dramatic but that's, frankly, because I'm annoyed at the ease with which these types of decisions keep getting made and I find the reasoning behind this change in particular to be extremely weak.

We gain nothing if <$>, <$ and $> are renamed to, say, <_>, <_ and _> and if we drop them entirely we lose expressivity.

[Max Goldstein]

First, Maxime, thank you for responding in a cool-headed and conciliatory fashion.

 

Learn what those "weird nonsense symbols" do.  Better yet, those "weird nonsense symbols" are likely to be a part of a conventional set of symbols because library authors tend to borrow from each other so once you learn what <$> does in library A you'll probably know how to use it in library B if it's present.

This is a very Haskell viewpoint. I'm not making a value judgement, just pointing out the influence. I disagree with it, but I'd like to explain why instead of naysaying on sight. Haskell front-loads its learning curve so that you have to learn about its type classes and infix ops before you can do anything really useful.

Elm tries to make it so that you "only pay for what you use", in a conceptual load sense. For example, the refactoring of Http to avoid Tasks in the common case.

Abstract symbols take on the meaning we assign to them.

 Your question, paraphrased, is "how is + different from <$> ?". The answer is that everyone learns about + in school but <$> and its "algebra" (a technically correct, but hardly common, use of the term!) are unique to Haskell and closely related languages. The problem with <$> isn't that it like all glyphs is abstract, but rather that it remains abstract after -- it is not assigned meaning by -- elementary mathematics or basic computer science.

When no such symbol is available in the realm of widely-known symbols (from a web developer's perspective!), we try to pick the best words. For example, "andThen" implies something about a chained callback, and "bind"  does not. Parsers are kind of unique in that they use a lot of operators because they are very logic-dense.

That's not to say that we can't invent or even misuse symbols: |> and <| are loosely, but not exactly, inspired by the unix pipe but they're insanely useful. << and >> abuse bitshifting notation, and were chosen over (.) which resembles mathematical function composition (but also record access etc). We use /= instead of != and ^ instead of **, both of which are more mathy and less cs-y, but still intelligible.

So, there's not a clear bright line here. It's more that the other operators kind of resemble something already known, and they also do useful things: high benefit, could-do-worse cost, so a high cost-benefit ratio. The somewhat subjective feeling on <$> is that it has high cost for someone not familiar with Haskell, and -- my comment about parsers being unusual notwithstanding -- are low benefit for most users.

[Roland Kuhn]

Another datapoint is that operators can always be misused: the implicit assumptions of associativity and commutativity invoked by the + operator (as taught in basic math classes) are easily violated, see for example string concatenation in most languages. Should it not be the misuse that is to be discouraged instead of banning certain characters completely? To me this looks more like a social issue than something that can be fixed by grammar rules.

Regards,

Roland

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/95de74d4-4eda-4b13-8ec2-26f1b7da9151%40googlegroups.com.

[Richard Feldman]

For the purpose of decision making, I am interested in your gut opinion only to the extent that I trust your design sense. 

This is a spectacularly arrogant statement, but I'm glad you've finally come out and said it since it falls in line with what I've previously said about these decisions of yours.

Lastly, I know sounding like a broken record but your effort to continually make the language better for beginners is actively hurting intermediate and advanced users. People don't like breaking changes in genera. They especially don't like breaking changes that are made on a whim and with no clear benefit.

Please don't presume to speak for the intermediate and advanced Elm community.

I'm a member of that community and I disagree strongly with pretty much everything you've said in this post. Simplicity and usability do not just benefit beginners, they benefit all of us. There is no hard-and-fast rule for which short-term breaking changes will make for a nicer long-term experience, but this one seems worth it to me.

In general, I think the breaking changes Evan has made to Elm have improved the language, and I've felt they were worth the cost of changing my code. His rationale for removing these symbols makes more sense to me than "if you find these symbols too arcane then RTFM," which I don't think is how we as library authors should treat our users.

tl;dr As a member of the intermediate/advanced Elm community, I am very much on board with these breaking syntax changes, and I hope Evan continues to make more of them. :)

[Mark Hamburg]

Once Richard's book comes out on paper, that will probably slow the rate of changes in the language. Dead trees tend to do that because the books stick around and people get frustrated when the material in them doesn't work — possibly with no clear mapping to the current version. Breaking widely available tutorial material makes things harder for beginners. That said, this seems to happen more with languages than with other software.

Mark

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAORaYgawsKTy-37mSxOjKvmMAiK1%2Bt88-ASv%3DSgzrb8%3DS48ocA%40mail.gmail.com.

[Max Goldstein]

To cue on Richard's point, my previous post said a lot of things along the lines of "Elm does it this way". Although I tried to give specific examples, of course I don't speak for anyone but myself so please read the post accordingly.

[Bogdan Popa]

I think the "these are my own opinions" disclaimer is implied with every post one makes so it goes without saying that I am not, in fact, speaking for anyone but myself. My opinion as someone who is also a part of that community (or is this the part you disagree with?) is as stated.

"if you find these symbols too arcane then RTFM,"

 

I think you are taking my position here to the extreme. Put simply what I said was that, if put in that position (and I have been), I would look up the documentation which I believe many others would as well and I don't believe this is limited to operators either.

[Richard Feldman]

Fair enough. :)

[Evan Czaplicki]

I agree that meaning is made up at some point, but the prevalence of that meaning is important. To put it another way:

43 75 6c 74 75 72 61 6c 20 63 6f 6e 76 65 6e 74 69

6f 6e 73 20 61 72 65 20 61 20 76 65 72 79 20 75 73

65 66 75 6c 20 64 65 73 69 67 6e 20 74 6f 6f 6c 21

If that's not clear at first, you can look it up really easily. And once you learn the ASCII hex codes, you can use them in all your emails.

Then this whole community can write emails in hex to each other and wonder why people feel alienated by our objectively reasonable conventions.

On Tue, Dec 20, 2016 at 11:46 AM, Richard Feldman <richard....@gmail.com> wrote:

Fair enough. :)

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/b89997e6-1207-450a-911a-f0ebdff1b941%40googlegroups.com.

[John Watson]

reductio ad absurdum

On Tuesday, 20 December 2016 18:37:22 UTC, Evan Czaplicki wrote:

I agree that meaning is made up at some point, but the prevalence of that meaning is important. To put it another way:

43 75 6c 74 75 72 61 6c 20 63 6f 6e 76 65 6e 74 69

6f 6e 73 20 61 72 65 20 61 20 76 65 72 79 20 75 73

65 66 75 6c 20 64 65 73 69 67 6e 20 74 6f 6f 6c 21

If that's not clear at first, you can look it up really easily. And once you learn the ASCII hex codes, you can use them in all your emails.

Then this whole community can write emails in hex to each other and wonder why people feel alienated by our objectively reasonable conventions.

On Tue, Dec 20, 2016 at 11:46 AM, Richard Feldman <richard....@gmail.com> wrote:

Fair enough. :)

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

[Jakub Hampl]

On the other side of the debate: I think operators shouldn't really be a third party thing at all. Or perhaps should be with native and effect managers in the category of: feel free to do this with your own code but you can basically forget about getting into the package repo. If someone perchance comes up with a particularly genius operator - there is always a whitelist.

[Michael Niessner]

  If I understand correctly, the case against operators is that everyone unknown concept that we encounter requires effort. Associating a symbol with a concept adds additional effort. If the symbol is not used frequently, we will forget the meaning and need to look it up. To make something as beginner friendly as possible, never use symbols.

  While the case for operators is that if you spend an extensive amount of time in a particular domain, you may want a more concise way to represent concepts that appear frequently. For instance 3 + 2 instead of Number.add 3 2.

  To me this would indicate that in order to help make elm be as beginner friendly as possible, the language and core libraries should minimize the use of operators. This allows beginners to face as little resistance as possible.

  For operators introduced by the language and core libraries, it seems wise to question how intuitive an operator is. Operators like + and - make sense to everyone from 1st grade on. Operators like * and / are understood by almost anyone with previous programming experience. Additionally these operators are frequent enough to be used. Operators like >> , |>, and <| are foreign to most programmers, but have shapes that imply direction and help make them feel intuitive.

  However, I'm not sure I understand how limiting additional operators like $, in non core libraries will reduce beginner friendliness. Think about the language of math. Everybody understands + and -. Great operators since everybody understand them, right? What about the integral ∫. Does the fact that only a subset of the population has taken calculus make it less useful? Would mathematics be easier to understand if every usage of ∫ was replaced with "the integral from x to y of ..."? Imagine if math's language creator and he said "I don't see any intuitive use for this curvy line thing ∫. In fact it kind of looks like an S, so I'm going to limit the symbols we can use to +, -, Σ, and any combination of those." Would ΣΣ make any more sense for the integral than ∫ does?

  Is the real goal, just so that no matter what library someone is using they don't encounter an operator they are unfamiliar with? If so why bother allowing any custom operators?

[Joey Eremondi]

Think about the language of math

Math is hardly something to aspire to in terms of readability and accessibility.

the case against operators is that everyone unknown concept that we encounter requires effor

That's one case against operators. There are others, which have been outlined in the past. Difficulty to find in documentation (they are basically un-google-abl) is another.

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/09f2f38d-31bd-4f96-a7cd-b71d09d083eb%40googlegroups.com.

[Richard Feldman]

What about the integral ∫. Does the fact that only a subset of the population has taken calculus make it less useful?

Yeah I'd say so. I took several semesters of calculus and then never used it again, so I actually didn't remember that ∫ was the symbol for integration. If you hadn't said what it was using the English word, I would have had to look it up.

Of course if I'm using ∫ all the time, then sure, I appreciate the conciseness. But trying to build on existing intuitions is worthwhile. Another math symbol I haven't used in over a decade is ℝ, but without Googling it I was able to remember that it represents the set of ℝeal Numbers. There's a reason I was able to remember that one and not what ∫ stood for.

What symbols look like makes a difference in usability. For reals.

(Pun intended.)

I agree that it's best to avoid infix operators, and I wrote decode-pipeline in an effort to patch my previous mistake of introducing the |: operator to json-extra. (I also agree that the decode-pipeline style seems like a good fit here as well.)

But if you're going to use an infix operator, it is clear to me that some are easier to use than others. Evan's statement that "The $ symbol adds a ton of visual noise, unlike simpler symbols like < and +" intuitively rings true to me.

Visual complexity aside, $ is singularly deserving of a ban because it is overloaded for a $comically = "large $quantity of" $.purposes() in different <$> languages and librarie$, besides being $1st and foremost $0.01 currency.$

[Joey Eremondi]

Another note regarding the math analogy is that, in math, notation *absolutely matters* for the adoption of concepts. The classic example is calculus: Newton invented it first, but we kept Liebniz notation because it was comparatively better than Newton's.

And, math us burdened with years of backwards compatibility. We write things a certain way because we have always done so. Part of Elm's raison d'etre is to break free from that, from the "we've always done this" of both Web Dev and Functional Programming, and to start fresh in some ways.

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/4e0a8e4c-c110-497e-8284-8fad9a59593e%40googlegroups.com.

[Evan Czaplicki]

I like the question "why allow custom infix operators in packages at all?"

Based on the parsing work I have done, I feel that special syntax of some sort goes a long way. I guess that'd include URL parsers as well. So I am sympathetic to this particular case based on my experiences, but that may just be a lack of creativity.

I'd say special operations for adding vectors is fringe enough that it's not such a compelling argument for custom operators in Elm. That case is very nicely addressed in Julia which goes a totally different direction, so I don't expect "custom infix ops" to be the ideal solution there.

So maybe having a whitelist for infix operators in packages is not crazy. I'll have to think about this more though!

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CADT%2BLxqR7qH2stdc1o-ZFWkS1M9QoUYzWXfi5-4sQoVj6gKXNQ%40mail.gmail.com.

[Max Goldstein]

The one operator I've found useful is (:::), as analogous to the standard (::). It's defined by lazy-list and my mgold/elm-nonempty-list. Trying to do the right thing, I defined the fixity of this operator using the little-known syntax. Which then came back to bite me because the compiler handles those declarations globally and would reject using nonempty lists with lazy lists, even if they were both only dependencies. So I removed the declaration.

Point being: I've been burned by even the most innocuous and seemingly-useful operator!

[Michael Niessner]

I guess when I look at:

  Package.someFunction value

    |> Package.something alpha

    |> Package.something bravo

    |> Package.something charlie

  Package.someFunction value 

    |. alpha 

    |. bravo 

    |. charlie

  Package.someFunction value |. alpha |. bravo |. charlie

  Package.someFunction value $ alpha $ bravo $ charlie

I don't find the $ operator to be terribly distracting. Granted, I don't know what it does. But I also don't know what "something" or |. does either.

Michael

[Janis Voigtländer]

Max, that point seems moot, being caused by a compiler bug (that seems to be fixed now anyway).

> Am 21.12.2016 um 01:46 schrieb Max Goldstein <maxgol...@gmail.com>:
>
> The one operator I've found useful is (:::), as analogous to the standard (::). It's defined by lazy-list and my mgold/elm-nonempty-list. Trying to do the right thing, I defined the fixity of this operator using the little-known syntax. Which then came back to bite me because the compiler handles those declarations globally and would reject using nonempty lists with lazy lists, even if they were both only dependencies. So I removed the declaration.
>
> Point being: I've been burned by even the most innocuous and seemingly-useful operator!
>

> --
> You received this message because you are subscribed to the Google Groups "elm-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/6667d749-a4da-4e5f-b657-a297b2c4ad87%40googlegroups.com.

[Dave Keen]

Just to chime in about infix operators that can have visual "meaning", I use `:>` extensively in my code (http://package.elm-lang.org/packages/ccapndave/elm-update-extra/2.3.1/Update-Extra-Infix).  This would be allowed by the new parser anyway, but I find this symbol particular easy to grok as:

a) it looks like |> so it instinctively feels like some kind of pipe

b) it has two dots instead of the line so it looks like two things (Model & Cmd) flowing through the update pipeline

[Mike MacDonald]

I liked the Unicode characters for the wiz-bang factor, although I definitely would not use them without providing a typeable alias. They will not be a tragic loss, though.

From your linked article, I do not see many languages using @ for macros, Dart's metadata and Python's decorators are similar, but much less powerful constructs. Also, @ seems a natural operator for index retrieval (even to laymen, it's pronounced "at"), or for working with email addresses.

I understand you don't like $'s (type)face, but it is used to great effect in e. g. elm-combine, which is a joy to work with!

I definitely understand losing standalone . as an operator because of the record field access shorthand.

[Zachary Kessin]

I would say that having too many infix operators can not just make things hard on people new to elm but also makes it hard to read code that you are not familiar with. The Haskell lens library has over 100 and while it is very powerful it makes trying to jump into a code base a real challenge. I like the fact that elm code tends to be easy to read and I think we should keep that as a goal

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/588952e1-ab33-4cc5-8b7d-b01c083c22c7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Zach Kessin

SquareTarget

Twitter: @zkessin

Skype: zachkessin

[fun...@gmail.com]

# is often used for instance methods in Javascript documentation.

e.g. Example.prototype.method would be written Example#method

Le lundi 19 décembre 2016 16:14:58 UTC+1, Mark Hamburg a écrit :

The use for hash tags does suggest using # as an indexing operator for dictionaries but I don't know that it would read all that well.

One use case that it does work well for is that in Lua it is an unary operator giving the length of a table. (The fact that the Oberon usage came to me first says something about my caffeination level this morning.) Example usage includes:

    for i = 1, #array do
        print( array[ i ] )
    end

    array[ #array + 1 ] = x -- Lua indexes from 1

Whether these uses have a natural correspondence in Elm, I don't know and as noted above I'm probably insufficiently caffeinated to say at this point. The one thought this raises for me is that if Elm were to embrace arrays more fully as an alternative to lists, then having a standard append operator might be useful but I don't know that # would be the right choice.

Mark

> On Dec 18, 2016, at 8:44 PM, Evan Czaplicki <eva...@gmail.com> wrote:
>
> Your comment inspired me to thing through # a bunch more, and I'm thinking it is probably better to get rid of it as well. It appears in SML and Clojure and Haskell, but it has no consistent meaning in those settings. It also means "hashtag" now for a lot of folks, so one could argue that it is a unary operator :P