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.
