[Haskell-cafe] Thoughts about redesigning "Num" type class
winterkoninkje at gmail.com
Tue Sep 15 11:58:28 UTC 2015
On Sat, Sep 12, 2015 at 5:12 AM, Jerzy Karczmarczuk
<jerzy.karczmarczuk at unicaen.fr> wrote:
> And whatever people say, e.g., Wren Romano:
>> There are far more objects which have
>> addition/multiplication without subtraction than there are objects
>> with addition/subtraction without multiplication.
> ... several simple-minded people (myself included) will find not so useful
> and/or clumsy the introduction of specific structures just to forbid the
> subtraction. Nobody will fight against these purists, it is simply a
> difficult issue.
I can assure you that there are numerous examples that even the most
"simple-minded" programmers are already intimately familiar with; cf.,
People use tropical, arctic, and Viterbi semirings all over the place:
e.g., almost every minimization/maximization problem where there's
some notion of gluing together subproblems. People use bounded
distributed lattices all the time: e.g., most everything in naive set
theory. People use regular languages/regexes all the time. All of
these are semirings, and none of them are rings.
Semirings are perfectly banal everyday things. The only difficulty is
in realizing how ubiquitous they are. This has nothing to do with
being a purist. I want semirings encoded as a type class because —as a
workaday programmer— I find myself almost daily wanting to
parameterize some algorithm to use a different semiring. All the
structure of linear algebra is far more complicated than what's going
on here. Most programmers ("simple-minded" or otherwise) do not
actually work with linear algebra; but almost every programmer has to
deal with sets, parsing/languages, minimizing/maximizing, not screwing
up array indices by going negative, etc etc.
 The salient min/max problems that don't fit that characterization
are the ones where we have two notions of gluing together sub
problems, in which case we generally want an ordered semiring— which
is just a generalization.
More information about the Haskell-Cafe