[swift-evolution] Epic: Typesafe calculations

[Dave Abrahams]

on Wed Jan 20 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:

>> Am 20.01.2016 um 18:16 schrieb Dave Abrahams via swift-evolution <swift-evolution at swift.org>:
>> 
>> 
>> on Wed Jan 13 2016, Thorsten Seitz via swift-evolution
>> <swift-evolution-m3FHrko0VLzYtjvyW6yDsg-AT-public.gmane.org> wrote:
>
>> 
>>>> Am 13.01.2016 um 00:06 schrieb Dave Abrahams
>>>> <dabrahams at apple.com>:
>>>> 
>>>>> On Jan 7, 2016, at 10:46 AM, Thorsten Seitz
>>>>> <tseitz42 at icloud.com> wrote:
>>> 
>>>>> 
>>>>> Really great to hear that you are planning for Swift to be able to
>>>>> do these kinds of things!
>>>>> 
>>>>> I tried to see how far I could get (working from memory of a
>>>>> Haskell library; Boost.Units seems quite similar at first glance),
>>>>> but failed of course because of the missing parameterized recursive
>>>>> typealiases:
>>>> 
>>>> Sadly, the lack of the ability to define a pretty shorthand for
>>>> quantities is not what stands in the way, fundamentally.
>>> 
>>> I'm afraid I don't get your meaning here. Would you mind to explain a bit more?
>>> Thanks!
>> 
>> Typealiases are just about creating new names for existing types.  The
>> inability to even form the correct type when an an acceleration is
>> multiplied by a time is the more fundamental issue.  You need to add
>> corresponding powers of the fundamental dimensions.
>
> Ah, thanks for explaining what you meant!
> Actually that’s what the generic recursive typealiases Add and Sub I
> defined in my example are for: they effectively provide addition and
> subtraction for Peano numbers implemented in the type system (that’s
> the way it works in Haskell).

Yeah, I knew that's what you were doing.  If you extend typealiases
enough, I suppose, they become like class templates with partial
specialization, but supporting them throughout the language would
require fundamental changes to our type system that have nothing
intrinsically to do with typealiases.  That's all I'm saying.