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.

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

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.

And it is very easy to write spaghetti-code which looks totally harmless.
We are throwing the programmers intuition away if we go the "make-a-lanugauge" road.

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

On 2017-07-28 12:30, Russel Winder via Digitalmars-d wrote:

> This was arguably the most talked about keynote in ACCU history. I had to
> close the questions after 75 minutes, and even then it went on longer.
Quite unfortunate that the questions did not appear in the video.

-- 
/Jacob Carlborg

On 2017-07-28 09:49, Yuxuan Shui wrote:
> Someone made an interesting proposal to C++: https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf
> 
> Thoughts?

Since no one else has mentioned it yet, I'm going to: it looks 	
suspiciously like AST macros :).

-- 
/Jacob Carlborg

On Friday, 28 July 2017 at 18:24:02 UTC, H. S. Teoh wrote:
> On Fri, Jul 28, 2017 at 05:38:10PM +0000, Stefan Koch via Digitalmars-d wrote:
>> [...]
>
> 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..
>
> [...]

Reading through the dlang documentation, I can't find a way to enforce a certain code standard using mixins _traits ctfe.
For example you have a custom allocator and you forbid using c malloc in functions and class constructor, and you create the @noMalloc to achieve this. To me that what's currently missing in D. To enforce certain code standards in projects to prevent developers accidentally using a certain function/class that is forbid by the custom attribute and that is not covered by the current attributes(safe, nogc, etc).

Imo it's very beneficial to have coding standards enforce by compile time.

On Friday, 28 July 2017 at 07:49:02 UTC, Yuxuan Shui wrote:
> Someone made an interesting proposal to C++: https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf
>
> Thoughts?

Looks like a hybrid between imperative and declarative macros. It's natural for C++ to add lots of syntax, but declarative additions don't look very valuable, because imperative macros are already turing-complete and can do any job. With this C++ will have 3 macro systems: imperative, declarative and preprocessor.
ps CTFE and AST DOM API naturally make minimalistic and versatile AST macros.

On Friday, 28 July 2017 at 15:41:28 UTC, 12345swordy wrote:
> ... That's not what I consider to be "simple" (Hard to read IMO).

struct DblRep
{
  mixin(bitfieldString([
    BitFieldDesc(Type.Ulong, "fraction", 23),
    BitFieldDesc(Type.Ushort, "exponent", 8),
    BitFieldDesc(Type.Bool, "sign", 1)
  ]));
}

With macros would look like

struct DblRep
{
  @BitFields
  struct
  {
    @23 ulong fraction;
    @8 ushort exponent;
    @1 bool sign;
  }
}

On Friday, 28 July 2017 at 22:12:32 UTC, Kagamin wrote:
> On Friday, 28 July 2017 at 15:41:28 UTC, 12345swordy wrote:
>> ... That's not what I consider to be "simple" (Hard to read IMO).
>
> struct DblRep
> {
>   mixin(bitfieldString([
>     BitFieldDesc(Type.Ulong, "fraction", 23),
>     BitFieldDesc(Type.Ushort, "exponent", 8),
>     BitFieldDesc(Type.Bool, "sign", 1)
>   ]));
> }
>
> With macros would look like
>
> struct DblRep
> {
>   @BitFields
>   struct
>   {
>     @23 ulong fraction;
>     @8 ushort exponent;
>     @1 bool sign;
>   }
> }

The great thing about string-mixins is that you can explain easily and they have an understandable representation which you can dump out easily.

Whereas with AST macros you need to understand the macro and can not as easily dump the output.

On Friday, 28 July 2017 at 22:12:32 UTC, Kagamin wrote:
> On Friday, 28 July 2017 at 15:41:28 UTC, 12345swordy wrote:
>> ... That's not what I consider to be "simple" (Hard to read IMO).
>
> struct DblRep
> {
>   mixin(bitfieldString([
>     BitFieldDesc(Type.Ulong, "fraction", 23),
>     BitFieldDesc(Type.Ushort, "exponent", 8),
>     BitFieldDesc(Type.Bool, "sign", 1)
>   ]));
> }
>
> With macros would look like
>
> struct DblRep
> {
>   @BitFields
>   struct
>   {
>     @23 ulong fraction;
>     @8 ushort exponent;
>     @1 bool sign;
>   }
> }

There is no reason you can't reflect on DblRep and generate the bit fields, see Stevens recent talk. https://forum.dlang.org/thread/ojai9r$se7$1@digitalmars.com

On 28 July 2017 at 21:20, 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, 28 July 2017 at 18:24:02 UTC, H. S. Teoh wrote:
>>
>> On Fri, Jul 28, 2017 at 05:38:10PM +0000, Stefan Koch via Digitalmars-d wrote:
>>>
>>> [...]
>>
>>
>> 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..
>>
>> [...]
>
>
> Reading through the dlang documentation, I can't find a way to enforce a
> certain code standard using mixins _traits ctfe.
> For example you have a custom allocator and you forbid using c malloc in
> functions and class constructor, and you create the @noMalloc to achieve
> this. To me that what's currently missing in D. To enforce certain code
> standards in projects to prevent developers accidentally using a certain
> function/class that is forbid by the custom attribute and that is not
> covered by the current attributes(safe, nogc, etc).
>
> Imo it's very beneficial to have coding standards enforce by compile time.

Sounds an awful lot like how people use UDAs and compile-time introspection to me.