Re: Making sense of predicates

["Dan'l Miller" <optikos@verizon.net>]

On Tuesday, October 22, 2013 2:26:28 PM UTC-5, Dmitry A. Kazakov wrote:
> On Tue, 22 Oct 2013 10:15:13 -0700 (PDT), Dan'l Miller wrote:
> > Ahhhh, you seek effectively the C++ vision,
>
> No idea what makes you think so.

And that is unfortunate, because I told you above.  I reiterate:  The A#1 mantra of major sectors of the C++ community (e.g., Boost) is to perform functionality in libraries whenever possible instead of in the core C++ language.  You seek that a substantially-similar goal, but perhaps via a different (unspecified by you, hinted at by me) style of programming than Boost's MTP via Boost.MPL or via Loki.

> >  What you seek is a better way of layering the compiler and extending the compiler,
>
> I seek a better types system because of problems the current one causes,
> like overuse of generics and run-time checks. I, as a programmer, need more
> static checks, more reuse, far less debugging.

Dmitry, please take a hint:  your type goals would be satisfied as a mere library by-product of accomplishing a much much MUCH more difficult goal of taming the beast of layered compilers that accomplish multistage programming, so that you don't travel the wicked C++ MTP path and merely port Boost's MTP-based templates to Ada somehow.  Writing that typing-system library will be the easy part once a language designer solves the layered-compiler problem for a multistage(-or-whatever) extensible compiler.

What is the demonstrable evidence that is the layered extensible compilation technology more difficult than the elegant typing-system building blocks usable to build higher-order type-safe libraries?  Such evidence is in C++ today, which has accomplished portions of the latter (quite contortedly, not backward compatibly), but has entirely failed on the former.  Note that Boost (and the subsequent C++ TRs) have largely provided a "library"-based approach to rich compile-time type-enforced semantics.  But the cost has been deleterious to numerous other valuable aspects of the C++ language, or any programming language for that matter:
1) deep nesting of arcane error messages within error messages within ... within error messages that often don't give even the slightest clue of what is wrong where,
2) excessive compile time,
3) fragility of the library,
4) fragility of app-domain code using the library,
5) fragmentation of the community between different incompatible (or barely not-incompatible) type-forests:  Qt, Boost, TR, homebrew, and so forth.
6) elaborate template-idiom syntax for historically implicit or trivial type semantics, where these template-idioms do not resemble (nor are backwards compatible with) the analogous historical C/C++ language's constructs.

These do not need to be the outcome.  It is merely the cascading ramification of the unwise path that C++ chose.