Will Traits and Concepts be supported in ATS3?

[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.

[Matthias Wolff]

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:

--
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-user...@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.

[gmhwxi]

>>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

To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-users+unsubscribe@googlegroups.com.

[Matthias Wolff]

First a correction: we get the database information via the configuration or the db_traits.

template<typename T>
struct something
{

    using database = typename db_traits<T>::database;
};

Second the implementation guard idea: I need more time for a feedback.

I hesitate to say this or that is on my wishlist, because the degree of
importance isn't clear enough for me. Perhaps I can help to avoid an
"ex falso quodlibet" effect regarding the interpretation of c++ features.

Regards, matthias

Am 04.07.20 um 00:15 schrieb gmhwxi:

To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-user...@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.

[Matthias Wolff]

Hi,

concerning the type traits I think a problem description is better than
trying to say what it is.

The more features a compiler provides so more time will be needed to
produce an object. Projects become bigger and bigger and the compile
time increases up to an hour and more.

Analyzing the problem shows that beside the slowdown of the compiler
the dependencies among the headers (sats staload) are a big problem.
Including dats files (staload) can also be a problem and if it is possible in
sats files, it must be forbidden. That says the analyzing expert.

An important measure is to introduce more forwardings in the sats, that
means introducing more abstypes and moving implementations - only c++ -
to the cpp files.

Sidenote: In c++ class forwardings make it necessary to use pointers or
references in the function declarations. Also worth to mention that the
object oriented aspect of member data increases the danger of couplings.
In ats a pointer forwarding has the shape - abst@ype abc = ptr. So it's not
necessary to rewrite the function.

But writing only - abst@ype abc - leads later to the include of one dats into
another dats. That means potential recompilation because of dats
dependencies (fortunately patsopt is able to produce dep-files).

Now it's time we remove the sats include. But it is not as easy as it could
be because the removed sats file may contain more information related to
the newly introduces abstype, which will be needed.

One class of such information could be defines. Defines can be separated
and included separately. There may be other problem classes to be
considered. Perhaps there exists a problem class in ats that motivates to
introduce traits. But it is difficult to say, if the problem classes of coupling
are the same as in c++ (need more practise).

It's import to separate the developers in two categories. Standard library
developers and normal application developers. I don't think that more
than 10% percent of all c++ developers have an ideas what traits are
and even they know it, the motivation is low to use it. This may be totally
different regarding the standard library developers.

Therefore the flexibility of the compiler design to be able to follow
the requirements coming from active developers will be the key.

I press it into this posting:

A) implementation guard: from the optics -
    It looks like context related implementation selection.
    Type classes?

B) Mappings - datatype (constructor selection by index / perhaps breaks ML traditions)
     abst@ype circle = ptr
     abs@ype rectangle = ptr

     datatype shape(t@ype) = shape(circle) of ... | shape(rectangle) of ...

     instead of

     datatype shape = cons_circle(circle) ....

C) Mappings - datasort (index support like B))

Currently I'm completely satisfied with ATS2. Still enough to learn.

Sorry for the length.

Regards, Matthias

Am 04.07.20 um 00:15 schrieb gmhwxi:

To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-user...@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.

[Hongwei Xi]

Thanks for the writing!

I feel that I have now acquired a pretty clear picture as to how C++ templates

are implemented. Not the details. Just the big picture. I will put into a post what

I have learned and then outline what kind problem I am trying to address with a

trait-like feature in ATS3. In any case, there is currently NO plan to implement such

a feature. Just food for thought.

To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-user...@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.

--
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-user...@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.

--
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-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/85fc11e8-e137-a0a8-42d3-739a204fc097%40bejocama.de.