>>I would say traits are type properties
I like your description :)
######
Let me use some pseudo code to illustrate a kind of support for traits
that can be quickly implemented for ATS3.
Say we have a template:
#extern
fun
<a:type>
foo(x: a): void
And we have two different implementations for foo:
impltmp
{a}
foo(x) = (* first *)
impltmp
<a>
foo(x) = (* second *)
Now we have two instances of foo in our code:
val () = foo<int>(100)
val () = foo<string>("100")
Say that the first instance should use the first implementation of foo
and the second instance should use the second implementation of foo.
To achieve this, we could introduce a trait called FOO2 for the second
implementation:
impltmp
<a>
FOO2(a) => foo(x) = (* second *) // the pseudo syntax means that this
implementation is guarded by FOO2(a)
Let FOO2 be given the following implementations:
impltmp
{a:type}
FOO2<a> = true
impltmp
FOO2<int> = false
To compile the instance foo<int>, the second implementation is first
picked; but the guard FOO2<int> is false;
so this implementation is skipped and the first implementation is picked
next.
######
Using traits for constructing guards is a low-hanging fruit. We could
certainly think of ways for traits to be used to
guide template resolution in a more profound manner.
--Hongwei
On Friday, July 3, 2020 at 4:29:29 PM UTC-4, Matthias Wolff wrote:
>
> C++ Term Traits:
>
> I would say traits are type properties
>
> struct oracle;
>
> struct postgres;
>
> template<typename T>
> void print_database(T t /* value only for type deduction -- avoiding
> explicit <>*/)
> {
> /*Type resolution: database is unknown at this stage, database is a
> dependend type, but type dependend */
>
> if constexpr (is_same<typename T::database,oracle>::value) { cout <<
> "oracle" << endl; return; }
>
> else if constexpr (is_same<typename T::database,postgres>::value) {
> cout << "postgres" << endl; return;}
>
> else { static_assert("Unsupported type"); }
> }
>
> struct abc
> {
> };
>
> struct def
> {
> };
>
> template<typename T>
> struct db_traits;
>
> template<>
> struct db_traits<abc>
> {
> using database = oracle;
> };
>
> template<>
> struct db_traits<def>
> {
> using database = postgres;
> };
>
> template<typename T>
> struct something
> {
> using database = typename T::database;
> };
>
> int main()
> {
> something<abc> s;
>
> print_database(s);
>
> return 0;
>
> }
>
> Typetraits are lightweight information because the implementations of the
> types/structs/classes
> are not of interest. Types are only names in this context.
>
> Remark: Generic programming is like any abstraction if only one example is
> available.
> It makes things more complicated. But looking on universal properties it's
> clear it needs
> a bunch of examples to get a benefit. So many developers can live without
> it. But everyone
> will try it - the "feature" effect.
>
> C++ term concepts:
>
> It's relatively new, available since C++-20. It an improvement in the area
> specification of
> templated constructions. Typically, in the C++ world it's forbidden to use
> a mathematical
> vocabulary. Make better specifications seems to be the goal. I have no
> personal experiences.
>
> Remark2: C++ concepts is an additional feature but not a concept. The
> world of C++ scientists
> is restricted by C++. It's more a (distinct) feeling: replace concepts by
> ats-proofing.
>
> Be sure, other c++ developers will tell you other things.
> Am 03.07.20 um 20:10 schrieb gmhwxi:
>
>
> Traits:
>
> Based on my understanding, traits in C++ can be implemented in a more or
> less
> straightforward manner. To me, traits are an template-based approach for
> generating
> ifdef-guards used in C.
>
> However, I would prefer to take a deeper look at the template resolution
> algorithm. Traits are
> a bit like band-aid used at surface. One can expect to achieve a lot more
> if there is a logical way
> to affect the manner in which template code is replaced with non-template
> code.
>
> Concepts:
>
> It is a feature mainly for statically debugging templates. I am looking
> into it. Debugging templates
> statically is a big thing; I prefer something with clearer semantics.
> Let's wait and see.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ats-lang-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ats-lang-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ats-lang-users/337ff3b2-40ed-43cc-9e0f-d62cfa6e4a42o%40googlegroups.com
>
> <https://groups.google.com/d/msgid/ats-lang-users/337ff3b2-40ed-43cc-9e0f-d62cfa6e4a42o%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
--
You received this message because you are subscribed to the Google Groups
"ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ats-lang-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/556bda1e-a680-4a87-aeb4-7b023c8d9714o%40googlegroups.com.
