[swift-evolution] [Proposal draft] Enhanced floating-point protocols

[Dave Abrahams]

on Thu Apr 21 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:

> I totally agree with you. 
>
> But I think that the suggested Summable with zero fits the bill of
> your citation quite nicely as it actually is a very generic concept
> which is widely useful.

Sure, that's Monoid.  My main objection is to adding a "Multiplicative"
that doesn't actually have two operations with the right relationships.

I'm trying to explain general principles here, not pick on Summable
specifically.  The main reason not to add Summable is that once you
attach numeric semantics to the operation of Monoid, there are no useful
models I know of that can't also satisfy some much richer protocols such
as Arithmetic.

> FWIW I had chosen the name Summable instead of Monoid for two reasons: (1) there
> has been reluctance by some people on this list to add algebraic types to the
> standard library

Yeah, we're reluctant because we want to do it right and that's hard.

> and (2) Summable is one concrete instance of Monoid for numbers (with
> respect to addition) just as my other suggestion Multiplicative is
> another instance of Monoid for numbers (with respect to
> multiplication).

Yeah... having a system where some things conform to the same protocol
in multiple ways is a whole 'nother kettle of fish that needs its own
language features
(c.f. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2098.pdf)

> If we want to add Monoid (and other algebraic types) to the standard
> library (I would welcome that), you are certainly right that we should
> design this well.  

We should design it well even if we're going to stick to numerical
subsets of Monoid ;^)

> The above actually suggests that summable and multiplicative instances
> for numbers might just be that: (singleton?)  instances of Monoid with
> an associated type of Number (instead of protocols) so that they can
> be passed around more easily.  

I don't know what you have in mind here.

> On the other hand we could borrow some ideas from Eiffel to solve the
> (semantic) diamond problem via renaming and choosing defaults. Like
> the early work about generics you found, 

I don't mean to be a pedant, but what I pointed you about is not about
generics, which is a collection language features.  Generics had been
around for years in Ada and C++ when that was written.  That paper is
about *generic programming*, which I won't define here because the paper
does a much better job than I can.

> Eiffel's solution sadly is ignored in most language designs (and
> interfaces thought of as a solution of the diamond problem... they are
> not). Not too long ago I wrote a lenghty mail on this list about that
> in the Mixin thread IIRC.
>
>     I'm not sure I'm adding anything by saying this, but one problem with
>     creating protocols that satisfy the absolute minimum requirements for a
>     particular algorithm is that you end up without any meaningful
>     abstractions.
>
> I think Dave Sweeris' example is not about creating Addable a.k.a
> Summable just because it satisfies the algorithm but rather it happens
> that Monoid *is* such a useful abstraction that it naturally pops up
> in many algorithms.

Why do you think that?  It seemed pretty well focused around addition to
me.

-- 
Dave