Date: Sun, 31 Jan 2021 19:43:06 +0000
Am Sonntag, den 31.01.2021, 17:37 +0000 schrieb Niall Douglas via Liaison:
> On 30/01/2021 22:27, Uecker, Martin wrote:
...
> > If C++ rejects dependent types because C++ people "dislike" them
> > (as you said above), then your type system will remain limited in
> > what you could do with it. Of course, external tools could
> > always attach their own more powerful types to C++ terms, but
> > the C++ type system could not help.
>
> Thanks for all the exposition I didn't reply to in order to keep this
> reply short.
>
> Don't get me wrong here, other C "successors" went the dynamic runtime
> type route, Objective C being the most obvious, but C# is another famous
> one. Whilst there is nothing wrong with languages such as Objective C or
> C#, in my personal opinion I would say that their time has passed
> relative to better alternatives.
>
> I don't want to make too sweeping a statement, but in my experience
> dynamic runtime types never optimise well. If you write your Python with
> static types, Pyston will optimise the snot out of it. If you write your
> Python with dynamic types, Pyston gives up very easily.
>
> I'm not a language person, nor a compiler person, but it seems to me
> that dynamic runtime types do not easily produce bare metal execution
> performance. I think indirection of dynamic information whilst keeping
> the top level of the type system 100% static is a better design approach.
I think this is a bit of misunderstanding. What you have
been describing is that C++ is erasing the length from
the type and making it a run-time property. But this
allows for less static type analysis not for more.
A type like
std::span<T>
which is something like
template <typename T>
struct span {
size_t len;
T* ptr;
};
erases any information about the length from the type.
This more like dynamic languages with weak typing and
the opposite of what C is doing here.
A regular static array type like T[5] has the full length
information in the type. A VM type like T[N] in C also
has the length information as run-time property. But
it still has static information about this dependency
in the type. You know for example that T[N] and T[M]
are compatible iff N == M and you know this conditional
property statically.
You can easily read form the types, for example, that in
the following function *a and *b have compatible types:
void foo(int N, double (*a)[N], double (*b)[N])
{
}
In contrast, if you have
void foo(std::spawn<T> a, std::spawn<T> b)
{
}
you do not know this statically! So the C approach
has more information available at compile time - not
less.
Best,
Martin
> On 30/01/2021 22:27, Uecker, Martin wrote:
...
> > If C++ rejects dependent types because C++ people "dislike" them
> > (as you said above), then your type system will remain limited in
> > what you could do with it. Of course, external tools could
> > always attach their own more powerful types to C++ terms, but
> > the C++ type system could not help.
>
> Thanks for all the exposition I didn't reply to in order to keep this
> reply short.
>
> Don't get me wrong here, other C "successors" went the dynamic runtime
> type route, Objective C being the most obvious, but C# is another famous
> one. Whilst there is nothing wrong with languages such as Objective C or
> C#, in my personal opinion I would say that their time has passed
> relative to better alternatives.
>
> I don't want to make too sweeping a statement, but in my experience
> dynamic runtime types never optimise well. If you write your Python with
> static types, Pyston will optimise the snot out of it. If you write your
> Python with dynamic types, Pyston gives up very easily.
>
> I'm not a language person, nor a compiler person, but it seems to me
> that dynamic runtime types do not easily produce bare metal execution
> performance. I think indirection of dynamic information whilst keeping
> the top level of the type system 100% static is a better design approach.
I think this is a bit of misunderstanding. What you have
been describing is that C++ is erasing the length from
the type and making it a run-time property. But this
allows for less static type analysis not for more.
A type like
std::span<T>
which is something like
template <typename T>
struct span {
size_t len;
T* ptr;
};
erases any information about the length from the type.
This more like dynamic languages with weak typing and
the opposite of what C is doing here.
A regular static array type like T[5] has the full length
information in the type. A VM type like T[N] in C also
has the length information as run-time property. But
it still has static information about this dependency
in the type. You know for example that T[N] and T[M]
are compatible iff N == M and you know this conditional
property statically.
You can easily read form the types, for example, that in
the following function *a and *b have compatible types:
void foo(int N, double (*a)[N], double (*b)[N])
{
}
In contrast, if you have
void foo(std::spawn<T> a, std::spawn<T> b)
{
}
you do not know this statically! So the C approach
has more information available at compile time - not
less.
Best,
Martin
Received on 2021-01-31 13:43:13