[OT] Generative C++

[H. S. Teoh via Digitalmars-d]

On Fri, Jul 28, 2017 at 07:49:02AM +0000, Yuxuan Shui via Digitalmars-d wrote:
> Someone made an interesting proposal to C++:
> https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf
> 
> Thoughts?

This is very interesting, both as a subject in and of itself, and also
in terms of the enthusiastic response it's receiving.

It goes along the same lines of thought I've had for a while now,
starting from Andrei's observations way back when in TDPL, that
programmers tend to dislike special cases and "magical" behaviour, i.e.,
special behaviour enjoyed by native types that cannot be emulated by
user-defined types.  IOW, we programmers want to be able to "get under
the hood" when we need to, and not be locked out by the black box of the
language implementation. Black boxes are nice and good when they work,
but as we're beginning to realize, no black box is completely
satisfactory all the time -- there will always be times when you need to
get under the hood.  And it's very frustrating when you're not allowed
to, even when it's clear that a tiny tweak to the way things are done
would greatly improve your code.

At a deeper level, what we're fundamentally looking for is symmetry --
and I mean that in the mathematical sense of "unchanged under some
operation X" (or some set of such operations).  In this particular case,
we're looking for symmetry between the language implementation --
default behaviour of built-in types -- and user power -- the ability to
change this default behaviour, as exemplified by Meyer's diagram where
you're given the ability to modify how the compiler transforms to the
source code to the "effective" source code.

This can also be viewed as symmetry between built-in types and
user-defined types: it should be possible to write a user-defined type
that behaves as though it were a built-in type (the symmetry operation
here is commuting baked-in behaviour with user-defined behaviour, or one
may say, symmetry between the ability of the language authors and the
language users: if the language authors can make the language behave a
certain way, the user ought to be able to do the same).

Another instance of symmetry can be found in the principles Meyer set
forth at the beginning of his paper: no special syntax should be
required for metaclasses; you should be able to employ normal class
definition syntax.  IOW, syntax should be symmetric under the operation
that exchanges "metaclass definition" with "normal class definition".

An example of *asymmetry* is in C++ template syntax, where the foreign
<> syntax is asymmetric w.r.t. non-template syntax (esp. because it
clashes with normal uses of the symbols '<' and '>'), and as a result
causes readability issues and parsing difficulties.  D template syntax
is closer to "normal" syntax, and the higher degree of symmetry makes it
easier to use, easier to parse, and have less pathological corner cases.

Metaclasses are only the first step, however.

If we were to take symmetry between baked-in behaviour with user-defined
behaviour to the logical conclusion, we would have a language where, at
least in theory, *every* language behaviour can be specified in the
language itself. I.e., in some sense, the language becomes its own
meta-language.

Or, to put that in more concrete terms, the language is formed of two
parts: a standardized IR (that forms part of the language spec), and a
set of default, higher-level abstractions that the user usually employs
as-is, but with the ability to specify new behaviour in terms of the IR
and have it available at the higher-level of abstraction.  You could
think of the IR as the "core" language that higher-level constructs are
lowered to (D already does some of this, to a small extent).  You'd
usually use the higher-level constructs, but the IR is directly
available to the user, and is standardized so that it works with every
language implementation.

Coming back to the topic of metaclasses, the IR would let you specify
things like the default access permissions of a class, the default
methods, and so on.  The high-level default simply specifies "private"
as the default access permission, and implicit ctors, copy ctors, etc.,
as the default methods.  But since the IR is directly available to the
user, he can easily define his own kind of types, maybe call them
publicSerializableClass's, where the default permission is "public" and
the default methods include a serialize() method.

But having a standardized IR that's available at the language level
gives you much, much, more possibilities than merely metaclasses.  You
would be able to define foreach loops for ranges without baked-in
compiler support, for example. And foreach loops for other kinds of
aggregates, and you wouldn't even need opApply.


T

-- 
Life is complex. It consists of real and imaginary parts. -- YHL