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