<?> clashes with use of <?> in Bogdanp/combine

[sporto]

While trying to upgrade an app to 0.18 I am getting this error:

Problem in dependency evancz/url-parser 2.0.0

The elm-package.json constraints of 'evancz/url-parser' are probably
letting too much stuff through. Definitely open an issue on the relevant github
repo to get this fixed and save other people from this pain.

In the meantime, take a look through the direct dependencies of the broken
package and see if any of them have had releases recently. If you find the new
thing that is causing problems, you can artificially constrain things by adding
some extra constraints to your elm-package.json as a stopgap measure.

Detected errors in 1 module.

I'm unclear what this means and how to fix it.

[icidasset]

I have this problem as well, the json report I get from elm-make tells me this:

[{"tag":"INFIX OVERLAP","overview":"The infix declarations for (<?>) must be removed.","subregion":null,"details":"The precedence and associativity of a particular operator can only be set in one\nplace in a code base, and (<?>) has already been set somewhere else.","region":{"start":{"line":282,"column":1},"end":{"line":282,"column":13}},"type":"error","file":"elm-stuff/packages/evancz/url-parser/2.0.0/src/UrlParser.elm"}]

And it gives me this error because <?> is already defined in Bogdanp/elm-combine (I found this by using Elm Search).

I'm guessing you probably have the same issue? You can get more info about the error by running elm-make --report=json.

[evancz]

@sporto, I need more information. Can you get it down to an http://sscce.org/ that demonstrates the problem?

[sporto]

@evancz this repository demonstrate the issue with a minimum example https://github.com/sporto/url-parser-deps

When I remove the dep Bogdanp/elm-time it compiles fine.

[sporto]

When using --report=json I see exactly the same issue that @icidasset pasted

[evancz]

The root problem https://github.com/elm-lang/elm-compiler/issues/1096 is tracked in https://github.com/elm-lang/elm-compiler/issues/1375. Until that is different, it will not be possible to build these things together. If someone has to give up <?> it seems like a URL parser has a better claim. The visual correspondence to ? in URLs is quite clear, whereas having a question mark for errors seems more dubious. I know it has history in Haskell parsers, but I think that's a weaker argument than the fact that ? is actually directly what is used in URLs.

[Bogdanp]

If someone has to give up <?> it seems like a URL parser has a better claim

url-parser is the newer library here and it's likely that fewer things are directly dependent on its <?> operator since it was only introduced recently. elm-combine has had it from the beginning and, like you said, the operator has history. On top of that, neither library needs to give up the operator, one (or both) just has to drop its fixity annotation: you've declared <?> to be infixl 8 in your code, if you remove that declaration then its fixity will be infixl 9 (per this) and it will become possible to compile the two libraries together.

[Bogdanp]

I've removed the fixity annotation from elm-combine. Hopefully that fixes things.

[sporto]

@Bogdanp that change you did in elm-combine fixed things for me, our app compiles now. Should we close this issue?

[evancz]

In my Haskell parsers, I prefer to use expecting : String -> Parser a -> Parser a over (<?>) : Parser a -> String -> Parser a so I would recommend going that route in any parsing library. I also prefer using oneOf over (<|>). So my code would look like this:

literal =
  expecting "a literal like 4 or True"  <|
    oneOf
      [ numberLiteral
      , stringLiteral
      , boolLiteral
      ]

I think this is better than using the infix operators. You are not adding tons of parens when things get more complicated. You are just using simple functions, so it is easy to search for everything. You have no mystery operators where you have to intuit that (<?>) has something to do with error messages and (<|>) is supposed to look like "or" from the grammar syntax that very few people use outside of programming language papers.

[Bogdanp]

In my Haskell parsers, I prefer to use expecting : String -> Parser a -> Parser a over (<?>) : Parser a -> String -> Parser a so I would recommend going that route in any parsing library. I also prefer using oneOf over (<|>). So my code would look like this:

That's fair, although going by the code here I think you underestimate (or perhaps intentionally misrepresent) your own usage of these operators. I prefer <?> over expecting and oneOf (or choice in combine) over <|> (in most cases), but the reality is I will use all of them if and when it makes sense to. The wonderful thing about having a type system is you don't have to rely on intuition when it comes to figuring out what most functions do, be they operators or not. Especifally when it comes to functions as simple as the operators in combine.

If people can figure out what <| (re your example) does then they can figure out what <?> does just as easily.

[evancz]

The parser is some of the oldest code in the compiler, so it has a lot of code where I just trusted how the Haskell people said to do things. So there are definitely legacy uses of the old style, and I'm slowly trying to convert things. I think it has some of the ugliest code in the whole ecosystem, and I prefer using expecting and choice.

If people can figure out what <| (re your example) does then they can figure out what <?> does just as easily.

The <| operator is used quite a lot in Elm. Enough that I think it's safe to assume that by the time folks are writing parsers, they know what it is. So you are essentially arguing that learning 1 thing is just as easy as learning 0 things. Learning 0 things is definitely easier. Is it super difficult? Not really. But is it necessary to learn? No. Does it make code clearer for new readers? No.

So my point is more that if I got to start from scratch or had a team writing code around this, our style guide would say to avoid operators like these.

You can do what you want of course, but I just wanted to share my perspective!