[throwawaymaths]

gleam's 1/0 = 0 is crazy just because the author doesn't want there to be any raises anywhere. problem is, in many real world scenarios 0 is used as a sentinel value that doesn't "just" mean 0. iirc reading somewhere (in a non gleam system where 1/0 = 0) there was a system where everyone woke up to having zero shares because a 0 share tx was posted to everyone's trading endpoint, and a zero share tx means "zero the account".

[Hasnep]

I think that's less likely to happen in Gleam because using 0 as a sentinel value would be unidiomatic, but I agree that's a very dangerous design choice.

[throwawaymaths]

luckily no gleam software ever has to interact with outside systems (software or otherwuse) that might make a choice unidiomatic to gleam.

in case it wasnt clear: a zero share tx being a tombstone is a stock accounting convention, not a choice of that particular software project.

[Hasnep]

You'd just do the same thing you do in any language, you parse the incoming data into a format that's more idiomatic, e.g. in Gleam

    type Record {
      NShares(n: Int)
      ZeroTheAccount()
    }
    
    fn parse_record(n: Int) -> Record {
      case n {
        0 -> ZeroTheAccount()
        _ -> NShares(n)
      }
    }

Then you don't have to worry about mixing up the two :)

[throwawaymaths]

no. you're mistaken. the error came about because the code calculated shares to give out as an average over certain set of values but in the particular business cycle there were no entries to average. a divide by zero error would have crashed and either triggered review or nothing would have happened. instead, dividing by zero was happily calculated as zero and everyone got a zero share disbursement, which meant "zero all the accounts". this is not an inbound data problem. this is a scenario where if someone had programmed it in gleam, gleam would have happily calculated an (incorrect) average of zero and everyone would have lost all their shares.

to wit: anything that calculates an average over non-fixed data cardinality for business logic is potentially at risk for a seroious logic error in gleam.

what's worse is this is a nonobvious error. llms will likely make it a lot. a code review is likely to miss it.

what's even worse is that the author refuses to acknowledge this and digs deeper in (because, well, its a "principled" choice that got made and now to change is breaking and it breaks a core "feature" of the language). 1/0 = 0 is fine for a language like idris which is used for theorem proving but never used for real world things. It's inappropriate for deploying when, for example, real money might be at stake.

[Hasnep]

Ah, I see my mistake. Yeah that's definitely the kind of thing that could happen in Gleam.