Please, how is Pos not a Monoid

[Anton-Latukha]

If function has a switch to include region or not, or if function counts a number of regions to compose-accumulate them into SrcSpan region:

f =
  SrcSpan r1 <> r2 <>
    (maybe
      mempty
      id
      mRegion
    )

SrcSpan is Semigroup, it is not Monoid, because Megaparsec: Pos prevents it from being Monoid, mkPos constructor prevents Pos from being 0, and so making impossible to declare a Monoid for any types that contain it.

Is it possible to allow Pos 0, so the Monoids can be created above (at least I mean in dependent projects code)?

Maybe, at lease it is possible to provide a side-builder, {mempty,zero}Pos, that yealds Pos 0?
Or maybe I do something wrong and there is much more effective way?

Question originally derived from:
https://github.com/haskell-nix/hnix/blob/9f873ca115a32d462b6c0cfec771ecbf1d292c6c/src/Nix/Expr/Types/Annotated.hs#L142-L146

[mrkkrp]

Pos is a wrapper for positive integers because line and column numbers start from 1, not 0. Since the operation we are considering is addition, it doesn't have mempty by definition.

It's up to you if you want to reuse the type in your programs. For the particular problem you show you could simply do a conditional function application:

if <something>
  then r1 <> r2
  else r1 <> r2 <> ...

[Anton-Latukha]

Not percieved a mathematical argumentation there. Addition of course forms a Monoid with 0.
If to evaluate material arguments: if one gets a sheet of checkered paper - ther is a corner there, and one can ask to step 3 lines from it and then 0.
How one gets 1 Line, is it gets counted from somewhere?

Concept of positioning embodies 0 as "not moving". Parser should not allow to parse at (0, 0), but condition that does not mean that I should be unable to move some (N Linues, N Column) position to (+0 Line, +1 Column) or (+1 Line, +0 Column) in the parser when doing (deltaLine, deltaColumn).

Since Pos does not allow to do deltas - then Pos probably conceptually should be treated as absolute position, where "only (1 Line, Column 1) exists" argument fits in, but that of course deprecates addition, since absolute positions can not be added.

Just not wanted to invent own code.

My idea was that Monoid allowed to ensure reuse of expressions for GHC and preserve the Stack and in some places have partial application possibilties by deduplicing the code.

Of course the question also can be solved by more code.

This question is an old one in parsers. Of course I consider those are a silly arguments, and you probably know the question better.

Well. Discussion seems was established into a dead end. Ok then. I would go either way.

Was worth a shot. Thank you for correspondence.