www.digitalmars.com         C & C++   DMDScript  

digitalmars.dip.ideas - New syntax for comma expression

reply Richard (Rikki) Andrew Cattermole <richard cattermole.co.nz> writes:
During semantic analysis, some code gets lowered to the comma 
expression.

New'ing anonymous classes are a good example of this.

Right now if hdrgen were to emit it, it looks like this (-vcg-ast 
to get it):

```
__anonclass1 foo = Object, LeInterface
{
	void* this;
}
, foo = new __anonclass1;
```

Proposed grammar:

```diff
CommaExpression:
+   "class" ConstructorArgs|opt AnonBaseClassList|opt 
AggregateBody
+   "__commaExpr" '(' CommaExpression ')'
```

This would not break code, nor would it affect tuples. No new AST 
nodes or semantic behaviour. Just hooking an existing language 
feature to be fully expressable in syntax.

Ideally, this would be able to bypass the DIP process, due to the 
bug-fixing nature of it.
Nov 20
parent reply Paul Backus <snarwin gmail.com> writes:
On Wednesday, 20 November 2024 at 23:11:37 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 During semantic analysis, some code gets lowered to the comma 
 expression.

 [...]

 Proposed grammar:

 ```diff
 CommaExpression:
 +   "class" ConstructorArgs|opt AnonBaseClassList|opt 
 AggregateBody
 +   "__commaExpr" '(' CommaExpression ')'
 ```


As a general rule, I don't think we should be adding new syntax 
to D because it's easier for the compiler to generate than the 
existing syntax.

If there's something in D's semantics that the existing syntax 
*can't express*, then there's a discussion to be had. But I don't 
think this qualifies.
Nov 20
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 21/11/2024 2:59 PM, Paul Backus wrote:

 On Wednesday, 20 November 2024 at 23:11:37 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 During semantic analysis, some code gets lowered to the comma expression.

 [...]

 Proposed grammar:

 ```diff
 CommaExpression:
 +   "class" ConstructorArgs|opt AnonBaseClassList|opt AggregateBody
 +   "__commaExpr" '(' CommaExpression ')'
 ```


 
 As a general rule, I don't think we should be adding new syntax to D 
 because it's easier for the compiler to generate than the existing syntax.


This is not an ease of use situation.

There is nothing for the lowering to map to in the syntax.

I.e.

```d
void main() {
     bool b;
	auto v = b ? (
         new class LeClass, LeInterface {}
         ) : (
         new class LeClass, LeInterface {}
         );
}

```

```
void main()
{
	bool b = false;
	LeClass v = b ? LeClass, LeInterface
	{
		void* this;
		 system this()
		{
			super.this();
			return this;
		}
	}
	 , new __anonclass2 : (LeClass, LeInterface
	{
		void* this;
		 system this()
		{
			super.this();
			return this;
		}
	}
	 , new __anonclass3);
	return 0;
}
```

Can't go and mess around with statement insertion for something like 
this. Of course feel free to try ;)


 If there's something in D's semantics that the existing syntax *can't 
 express*, then there's a discussion to be had. But I don't think this 
 qualifies.


Yup, there is plenty unfortunately.

https://github.com/search?q=repo%3Adlang%2Fdmd+%22new+CommaExp%22&type=code
Nov 20
parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 21 November 2024 at 02:09:14 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 21/11/2024 2:59 PM, Paul Backus wrote:

 As a general rule, I don't think we should be adding new 
 syntax to D because it's easier for the compiler to generate 
 than the existing syntax.


 This is not an ease of use situation.

 There is nothing for the lowering to map to in the syntax.


Why does the lowering have to map to anything? It's an 
implementation detail of the compiler.
Nov 20
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 21/11/2024 3:26 PM, Paul Backus wrote:

 On Thursday, 21 November 2024 at 02:09:14 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 On 21/11/2024 2:59 PM, Paul Backus wrote:

 As a general rule, I don't think we should be adding new syntax to D 
 because it's easier for the compiler to generate than the existing 
 syntax.


 This is not an ease of use situation.

 There is nothing for the lowering to map to in the syntax.


 
 Why does the lowering have to map to anything? It's an implementation 
 detail of the compiler.


It's not an implementation detail of the compiler.

The comma expression is in the language. But because of tuples its on 
the way out and so it doesn't support everything that it needs to.

Regardless the .di generator is broken for D code. That means errors are 
not emitting correct code either. This affects a lot more than just a 
couple of switches.

A simple parser change that won't break code and which has the chance to 
fix some hard problems should be an easy win.

If you think this can be fixed another way, please prove me wrong. I'd 
love for the .di generator to be functional regardless of who or what 
approach is taken to achieve it.
Nov 20
parent reply Nick Treleaven <nick geany.org> writes:
On Thursday, 21 November 2024 at 02:40:15 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 The comma expression is in the language. But because of tuples 
 its on the way out and so it doesn't support everything that it 
 needs to.


When we have tuples: `(e1, e2, e3)[$-1]` instead of `(e1, e2, 
e3)` in C.


 Regardless the .di generator is broken for D code. That means 
 errors are not emitting correct code either. This affects a lot 
 more than just a couple of switches.

 A simple parser change that won't break code and which has the 
 chance to fix some hard problems should be an easy win.

 If you think this can be fixed another way, please prove me 
 wrong. I'd love for the .di generator to be functional 
 regardless of who or what approach is taken to achieve it.


Maybe:
```d
(){
	class __anonclass1 : BaseClassList
	{
		void* this;
	}
	return new __anonclass1 args; }()
```
Could that work correctly with the context pointer?

Otherwise to generally fix it, there would need to be a way of 
declaring inline types in an expression. (We also might want 
inline template syntax).
Nov 21
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 22/11/2024 6:56 AM, Nick Treleaven wrote:

 Maybe:
 
 |(){ class __anonclass1 : BaseClassList { void* this; } return new 
 __anonclass1 args; }() |
 
 Could that work correctly with the context pointer?


Context pointer is irrelevant, it won't work.

```d
     bool b;
	auto v = b ? (
         new class LeClass, LeInterface {}
         ) : (
         new class LeClass, LeInterface {}
         );
```

```
	bool b = false;
	LeClass v = b ? LeClass, LeInterface
	{
		void* this;
		 system this()
		{
			super.this();
			return this;
		}
	}
	 , new __anonclass2 : (LeClass, LeInterface
	{
		void* this;
		 system this()
		{
			super.this();
			return this;
		}
	}
	 , new __anonclass3);
```

The joys of expressions being a tree.


 Otherwise to generally fix it, there would need to be a way of declaring 
 inline types in an expression. (We also might want inline template syntax).


The only type we need to declare inline is classes, as far as I'm aware, 
which I did add to the grammar (but may have forgotten the class name 
identifier *sigh*).
Nov 21