[OT] Generative C++

[H. S. Teoh via Digitalmars-d]

On Fri, Jul 28, 2017 at 05:38:10PM +0000, Stefan Koch via Digitalmars-d wrote:
> On Friday, 28 July 2017 at 17:18:35 UTC, H. S. Teoh wrote:
> > 
> > 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.
> 
> One significant problem with this is that, you loose alot of static
> introspection and reasoning capabilities.

Not necessarily.  Perhaps "IR" is the wrong term to use, as in compiler
parlance it means something very close to machine code, but the idea is
that the core language should provide enough semantics that you can
still introspect and reason about it meaningfully.  To use the C++
example, it would provide semantic notions like access permissions, so
that you can still meaninfully introspect whether a method is public,
private, protected, etc..


> As you need not only understand the core concepts of the language but
> also the specific dialect written by user-code.

But this already happens in today's large projects.  Every project has
its own way of doing certain things, and in order to understand what the
code is actually doing, you have to understand what is effectively its
own dialect of the language.  Not following the project's way of doing
things is usually what leads to problems later on -- e.g., the project
may require you always allocate with customMalloc, but as a new person
to the project you write malloc instead, and it blows up because the
rest of the code assumes things that are not true when you don't use
customMalloc.


> Also while it may look like a reduction of complexity we compiler guys
> have to me even more on our guard if the users can manipulate asts too
> freely.

No, this is not about manipulating ASTs. Well at least, if properly
designed, it wouldn't let you perform arbitrary transformations to
arbitrary parts of the AST.  A proper design would have to be such that
any such user-defined behaviours must be properly-contained and
encapsulated so that it won't result in an explosion of complexity that
affects things outside.


> And it is very easy to write spaghetti-code which looks totally
> harmless.

It's already possible to write spaghetti code today. :-D  Looking
totally harmless is just icing on the cake. :-D  As Larry Wall once
said, "Real Programmers can write assembly code in any language. :-)".


> We are throwing the programmers intuition away if we go the
> "make-a-lanugauge" road.

Actually, this is about *keeping* programmer intuition rather than
throwing it away.  Every now and then we get someone popping into the
forum asking why D operator overloading is so constricted compared to
C++, and how to work around that.  Andrei's standard answer is always
"write your own DSL", since CTFE lets you parse your DSL at
compile-time.  I don't think it's fair to say that DSLs are throwing
programmers' intuition away, even though it *is*, essentially, something
along the "make-a-language" road.

So the key thing here is a proper design that encapsulates such DSLs or
user-defined dialects, so that it's clearly contained in its own thing
rather than polluting the global syntax-space. If we wanted the latter,
C macros already allows us to do this (e.g., see any IOCCC entry :-D).
C++ metaclasses are encapsulated because the customization only exists
in the namespace of that metaclass; you can't arbitrarily modify the
semantics of classes outside of that metaclass.  D DSLs are also
encapsulated because they are (possibly compile-time) string arguments
that don't directly interact with "normal" D syntax.  Similarly, a
proper design of a meta-language like what I'm describing should also
ensure that things are properly encapsulated so that code with custom
behaviour is clearly different from code with "default" behaviour, even
if they are at some level symmetric w.r.t. each other.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze