[swift-evolution] protocol-oriented integers (take 2)

[Xiaodi Wu]

I can't speak to the core team's motivations, but what I'm hoping for
personally is a solution to this problem:

Currently, there are a bunch of protocols to which integer types conform.
However, they aren't very useful (not really usable) for generic
programming. One example: As an exercise, I tried to port a binary greatest
common denominator function to Swift, generic over SignedNumber. However, I
can't bit shift. I have to divide by two. Because << isn't required or
implemented for two SignedNumber values. This proposal arranges the cascade
of protocols to which integer types conform, and their requirements, so
that useful generic algorithms that use integers can be written without
retroactively conforming them to one's own made-up protocols every time.
Every so often one or two minor new facilities are thrown in that complete
the picture, but the biggest part of this proposal is the rearranging.

I don't read this proposal as having as a goal the implementation of
advanced math in the standard library. However, note that it is not
possible to retroactively use an existing protocol in the standard library
to refine your own protocol in another project. So, what's important is
that the protocols here don't gratuitously preclude (preclude for no
technically justifiable reason) the "plugging in" (conforming) of
third-party numeric types to standard library protocols, so that where
these types have the semantics required they too can be used with
algorithms written to be generic over types conforming to standard library
protocols.

I think the key question about "naming things" that's left over here is:
since our modeling of sets of infinitely many things (e.g. integers) is
necessarily imperfect on a machine with finite memory, is it wise to use
terms from mathematics that describe those infinitely many things for our
imperfect, finite models? For now, the proposal chooses deliberately less
"mathy" terms so that Swift doesn't (a) make these protocols impenetrable
to the average user; and (b) it doesn't overpromise and say that our
imperfect model of something is _the_ way to model that thing. Nonetheless,
these mathy terms describe some attributes of integers, real numbers, etc.,
that apply as much to the algorithms we may want to write in Swift as they
do to math. Therefore, I think we want to ensure that even as we don't
insist on "mathy" names, we absorb as avidly as we can the insights about
integer semantics that the mathematicians have worked out, in the hopes of
making our protocols maximally useful.

But you're precisely right that a laudable aim is to help, not hinder,
third-party library design.


On Mon, Jan 16, 2017 at 20:25 Jay Abbott via swift-evolution <
swift-evolution at swift.org> wrote:

> I barely understand any of this thread, so these might be silly questions,
> or based on a total misunderstanding the goals here, but it seems to be
> about: a) clever/advanced mathsy things; b) naming things; and c) the
> standard library... my questions are:
>
> Do specialised clever advanced mathsy libraries all work exactly the
>
> same, or do they have slightly different behaviours or conventions or
>
> semantics in different fields of study?
>
> Is the the goal here to define a common/shared
>
> sub-set of specialised maths libraries, but in the standard library? Would
> that be useful by itself?
>
> Could it be possible that "naming things" in the standard library would
> trample all over possible uses in external libraries, making it harder
> rather than easier for specialised maths libraries to construct their
> interfaces in a non-confusing way?
>
>
> On Tue, 17 Jan 2017 at 01:39 Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
>
>
> on Mon Jan 16 2017, Xiaodi Wu <swift-evolution at swift.org> wrote:
>
>
>
>
>
> > Strideable? I didn't think Strideable itself was going away. I'd be sad
> if
>
>
> > it did; for one, all the Unsafe*Pointers are Strideable and that has its
>
>
> > uses.
>
>
>
>
>
> Nobody's proposing to remove Strideable.
>
>
>
>
>
> --
>
>
> -Dave
>
>
>
>
>
> _______________________________________________
>
>
> swift-evolution mailing list
>
>
> swift-evolution at swift.org
>
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
>
> swift-evolution mailing list
>
> swift-evolution at swift.org
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170117/802ea283/attachment.html>