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:
>>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 [email protected]
<mailto:[email protected]>.
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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/556bda1e-a680-4a87-aeb4-7b023c8d9714o%40googlegroups.com
<https://groups.google.com/d/msgid/ats-lang-users/556bda1e-a680-4a87-aeb4-7b023c8d9714o%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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/85fc11e8-e137-a0a8-42d3-739a204fc097%40bejocama.de.
