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.
On Sun, Jul 5, 2020 at 12:42 PM Matthias Wolff <matthias.wo...@bejocama.de> wrote: > 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 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 > <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 ats-lang-users+unsubscr...@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 > <https://groups.google.com/d/msgid/ats-lang-users/85fc11e8-e137-a0a8-42d3-739a204fc097%40bejocama.de?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/CAPPSPLpWBHZ_1He7j2u_XyDOWa2bNZ7cR1R2sryCN06gE8gxfQ%40mail.gmail.com.