www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Grammar question. TypeSuffix - what is [ AssignExpression ..

reply WB <witold.baryluk gmail.com> writes:
I am reading D grammar again

and spotted on https://dlang.org/spec/grammar.html#TypeSuffix and 
https://dlang.org/spec/type.html#grammar

Something weird

```
TypeSuffix:
     *
     [ ]
     [ AssignExpression ]
     [ AssignExpression .. AssignExpression ]
     [ Type ]
     delegate Parameters MemberFunctionAttributesopt
     function Parameters FunctionAttributesopt
```

1st - pointers, 2nd - dynamic arrays, 3rd - static arrays, 5th - 
associative arrays, 6/7 - delegate types.


The 4th production would mean this is legal (syntactically) 
variable definition:

```d
string[5 .. 9] x;
```


My random guess is that this for creating some kind of range 
checked arrays with non-zero start? I believe languages like 
Pascal and Ada had similar constructs.


Of course that does not work for any built in type. Nor I see how 
this could work for user defined type (maybe a static `opSlice` 
on a user type that creates a proxy object, but that I fails to 
see how exactly).



Any idea what is this `[ AssignExpression .. AssignExpression ]` 
production for actually?


Is it for some tuple / type sequence slicing? (I guess it is 
called AliasSeq in current Phobos)

However, in places like 
https://dlang.org/library/std/meta/alias_seq.html  I cannot see 
this being mentioned (second example kind of hints at it tho).

I also looked at 
https://dlang.org/spec/function.html#d_style_variadic_functions  
for D-style variadic functions, but I think it is not that.

So maybe https://dlang.org/spec/template.html#variadic-templates 
, where more specifically 
https://dlang.org/spec/template.html#seq-ops  mentions slicing 
operation on these sequences ?


Could we maybe improve a grammar a bit to make it a bit cleaner, 
by naming productions?

Something like this:

```
TypeSuffix:
     Pointer
     Array
     TypeSequenceSlice
     FunctionPointer
     Delegate
```

and move existing productions to these sub-rule there accordingly.

Or similar.
Sep 01
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Monday, 2 September 2024 at 00:16:14 UTC, WB wrote:

 I am reading D grammar again

 and spotted on https://dlang.org/spec/grammar.html#TypeSuffix 
 and https://dlang.org/spec/type.html#grammar

 Something weird

 ```
 TypeSuffix:
     *
     [ ]
     [ AssignExpression ]
     [ AssignExpression .. AssignExpression ]
     [ Type ]
     delegate Parameters MemberFunctionAttributesopt
     function Parameters FunctionAttributesopt
 ```

 1st - pointers, 2nd - dynamic arrays, 3rd - static arrays, 5th 
 - associative arrays, 6/7 - delegate types.


 The 4th production would mean this is legal (syntactically) 
 variable definition:

 ```d
 string[5 .. 9] x;
 ```


```d
import std.meta: AliasSeq;

alias MyTypes = AliasSeq!(int, double, string);

MyTypes[1 .. 3] myVars;
static assert(is(typeof(myVars[0]) == double));
static assert(is(typeof(myVars[1]) == string));
```
Sep 01
prev sibling next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 2 September 2024 at 00:16:14 UTC, WB wrote:

 
 Is it for some tuple / type sequence slicing? (I guess it is 
 called AliasSeq in current Phobos)

 However, in places like 
 https://dlang.org/library/std/meta/alias_seq.html  I cannot see 
 this being mentioned (second example kind of hints at it tho).


Good docs for what seq does, doesnt exist; period. You have to 
learn from trail and error.

That would be the correct place to link to something and Ive 
suggested that d3 std.meta links to the template book as a 
bandaid, but I dont think it will happen, nor do I think anyone 
is going to work on writing out the fundmental operations you 
have for seq's.
Sep 02
parent reply Nick Treleaven <nick geany.org> writes:
On Monday, 2 September 2024 at 16:35:11 UTC, monkyyy wrote:

 Good docs for what seq does, doesnt exist; period. You have to 
 learn from trail and error.


What's wrong with:


 So maybe 
 https://dlang.org/spec/template.html#variadic-templates , where 
 more specifically https://dlang.org/spec/template.html#seq-ops 
 mentions slicing operation on these sequences ?
Sep 04
next sibling parent user1234 <user1234 12.de> writes:
On Wednesday, 4 September 2024 at 17:31:53 UTC, Nick Treleaven 
wrote:

 On Monday, 2 September 2024 at 16:35:11 UTC, monkyyy wrote:

 Good docs for what seq does, doesnt exist; period. You have to 
 learn from trail and error.


 What's wrong with:


 So maybe 
 https://dlang.org/spec/template.html#variadic-templates , 
 where more specifically 
 https://dlang.org/spec/template.html#seq-ops mentions slicing 
 operation on these sequences ?




What OP wants (I believe) is that:

```
TypeNext:
     TypeStaticArray
     TypeStaticSlice
     TypeSequenceSlice
     ...
     BasicType

TypeStaticArray:
     TypeNext [ AssignExpression ]

TypeSlice:
     TypeNext [ ]


TypeSequenceSlice:
     TypeNext [ AssignExpression .. AssignExpression ]
```

So that the doc for https://dlang.org/spec/type.html could work 
similarly to
https://dlang.org/spec/declaration.html, i.e each construct can 
have its own grammar div. Actually types-docs feel a bit 
sub-standard compared to.
Sep 04
prev sibling next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Wednesday, 4 September 2024 at 17:31:53 UTC, Nick Treleaven 
wrote:

 On Monday, 2 September 2024 at 16:35:11 UTC, monkyyy wrote:

 Good docs for what seq does, doesnt exist; period. You have to 
 learn from trail and error.


 What's wrong with:


 So maybe 
 https://dlang.org/spec/template.html#variadic-templates , 
 where more specifically 
 https://dlang.org/spec/template.html#seq-ops mentions slicing 
 operation on these sequences ?




Seq's are builtin data types that need *more* explanations then 
aa's and slices, lets assume you realized that the spec is 
useless and went to the book for slices you get 3 pages worth of 
code examples for whats not that hard to understand. The spec 
only offers 3 code examples, none of which covers, oh, lets say 
static foreach of seq's, youd need to know to go to spec on 
foreach to look for it.

The template book should be "made cannon" and probably get some 
major updates(it is after all, 10 years out of date).
Sep 04
parent Nick Treleaven <nick geany.org> writes:
On Wednesday, 4 September 2024 at 19:21:21 UTC, monkyyy wrote:

 The spec only offers 3 code examples, none of which covers, oh, 
 lets say static foreach of seq's, youd need to know to go to 
 spec on foreach to look for it.


It's a spec, so it links to foreach on a sequence (which has 
examples):


 Sequences can 'unroll' code for each element using a foreach 
 statement.
Sep 04
prev sibling parent reply WB <witold.baryluk gmail.com> writes:
On Wednesday, 4 September 2024 at 17:31:53 UTC, Nick Treleaven 
wrote:

 On Monday, 2 September 2024 at 16:35:11 UTC, monkyyy wrote:

 Good docs for what seq does, doesnt exist; period. You have to 
 learn from trail and error.


 What's wrong with:


 So maybe 
 https://dlang.org/spec/template.html#variadic-templates , 
 where more specifically 
 https://dlang.org/spec/template.html#seq-ops mentions slicing 
 operation on these sequences ?




The problem is that these two places are not mentioned anywhere 
on the page where grammar rules are present for them ( 
https://dlang.org/spec/grammar.html#TypeSuffix and 
https://dlang.org/spec/type.html#grammar ), making it hard to 
discover / understand.
Sep 11
parent reply Nick Treleaven <nick geany.org> writes:
On Wednesday, 11 September 2024 at 18:49:52 UTC, WB wrote:

 The problem is that these two places are not mentioned anywhere 
 on the page where grammar rules are present for them ( 
 https://dlang.org/spec/grammar.html#TypeSuffix and


BTW that page is just auto-generated from the grammar sections in 
each part of the spec.


 https://dlang.org/spec/type.html#grammar ), making it hard to 
 discover / understand.


That was true, though when I read this thread I added a link to 
type sequences here:
https://dlang.org/spec/type.html#derived-data-types
Sep 13
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 13 September 2024 at 09:20:22 UTC, Nick Treleaven 
wrote:

 On Wednesday, 11 September 2024 at 18:49:52 UTC, WB wrote:

 The problem is that these two places are not mentioned 
 anywhere on the page where grammar rules are present for them 
 ( https://dlang.org/spec/grammar.html#TypeSuffix and


 BTW that page is just auto-generated from the grammar sections 
 in each part of the spec.


Which is why the spec is worthless for learning anything

The spec is only for bug report debates, which probaly shouldnt 
be such prominent a feature of dlang
Sep 13
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 9/13/24 13:00, monkyyy wrote:

 On Friday, 13 September 2024 at 09:20:22 UTC, Nick Treleaven wrote:

 On Wednesday, 11 September 2024 at 18:49:52 UTC, WB wrote:

 The problem is that these two places are not mentioned anywhere on 
 the page where grammar rules are present for them ( https:// 
 dlang.org/spec/grammar.html#TypeSuffix and


 BTW that page is just auto-generated from the grammar sections in each 
 part of the spec.


 
 Which is why the spec is worthless for learning anything
 
 The spec is only for bug report debates, which probaly shouldnt be such 
 prominent a feature of dlang


FWIW I learned the language by reading the spec.
Sep 13
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Friday, 13 September 2024 at 11:00:50 UTC, monkyyy wrote:

 On Friday, 13 September 2024 at 09:20:22 UTC, Nick Treleaven 
 wrote:

 BTW that page is just auto-generated from the grammar sections 
 in each part of the spec.


 Which is why the spec is worthless for learning anything


Why would you try to learn from a page only listing grammar, 
instead of reading the spec pages?
Sep 13
parent monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 13 September 2024 at 12:18:16 UTC, Nick Treleaven 
wrote:

 On Friday, 13 September 2024 at 11:00:50 UTC, monkyyy wrote:

 On Friday, 13 September 2024 at 09:20:22 UTC, Nick Treleaven 
 wrote:

 BTW that page is just auto-generated from the grammar 
 sections in each part of the spec.


 Which is why the spec is worthless for learning anything


 Why would you try to learn from a page only listing grammar, 
 instead of reading the spec pages?


I wouldnt and didnt read *any* part of the spec to learn 
anything, I mostly use it for the formal names of things and bug 
report debates; I dont consider it relivent at all.

There are at least *4* better ways to learn d, and one of them is 
"lol, just write code without anything"
Sep 13
prev sibling parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 2 September 2024 at 00:16:14 UTC, WB wrote:

 I am reading D grammar again

 and spotted on https://dlang.org/spec/grammar.html#TypeSuffix 
 and https://dlang.org/spec/type.html#grammar

 Something weird

 ```
 TypeSuffix:
     *
     [ ]
     [ AssignExpression ]
     [ AssignExpression .. AssignExpression ]
     [ Type ]
     delegate Parameters MemberFunctionAttributesopt
     function Parameters FunctionAttributesopt
 ```

 1st - pointers, 2nd - dynamic arrays, 3rd - static arrays, 5th 
 - associative arrays, 6/7 - delegate types.


Correct.


 The 4th production would mean this is legal (syntactically) 
 variable definition:

 ```d
 string[5 .. 9] x;
 ```


Valid syntactically, yes. Valid semantically, of course not.


 My random guess is that this for creating some kind of range 
 checked arrays with non-zero start? I believe languages like 
 Pascal and Ada had similar constructs.


No. If you have a compile-time sequence e.g. generated by 
`AliasSeq!(int, string, bool)`, this rule allows for a sequence 
of locals/parameters to be declared having types of a 
sub-sequence.


 Of course that does not work for any built in type. Nor I see 
 how this could work for user defined type (maybe a static 
 `opSlice` on a user type that creates a proxy object, but that 
 I fails to see how exactly).


It’s not supposed to be used on types, but sequences containing 
types. What comes before the `[l..u]` need not be a type 
semantically, it just must _parse_ as a `BasicType`.


 […]

 Could we maybe improve a grammar a bit to make it a bit 
 cleaner, by naming productions?

 Something like this:

 ```
 TypeSuffix:
     Pointer
     Array
     TypeSequenceSlice
     FunctionPointer
     Delegate
 ```

 and move existing productions to these sub-rule there 
 accordingly.

 Or similar.


No. Production rules that have only one sub-clause are pretty 
much useless. The complete grammar page is not useful for 
understanding the grammar, but for looking up stuff, as you need 
not know which sub-page it’s on. If you want to understand it, 
the specific sub-page should explain it. A grammar entity should 
be named in a meaningful , or at least non-misleading way. I 
changed many names. In fact, [it was me who named it 
`TypeSuffix`](https://github.com/dlang/dlang.org/pull/2873); 
before, it was `BasicType2X`. If we went the route you’re 
suggesting, it would look like this:
```
TypeSuffix:
     Pointer
     Slice
     StaticArray
     AssociativeArray
     SequenceSlice
     CallableSuffix

Pointer:
     *

Slice:
     []

StaticArray:
     [ AssignExpression ]

AssociativeArray:
     [ Type ]

SequenceSlice:
     [ AssignExpression .. AssignExpression ]

CallableSuffix:
     delegate Parameters MemberFunctionAttributes?
     function Parameters FunctionAttributes?
```

The reason for grouping callable suffixes together is that they 
have a lot of similarities. My DIP Draft to allow for `ref` 
returning function pointers and delegates has to single them out. 
The Draft contains a showcase grammar (not actually proposed) 
that does that, too. Now, back to the grammar above: It’s lengthy 
and not really insightful.

I think it’s best to leave some of the grammar to prose and 
explain what things mean in the section below the formal grammar 
box.
Sep 05
parent reply Nick Treleaven <nick geany.org> writes:
On Thursday, 5 September 2024 at 14:22:56 UTC, Quirin Schroll 
wrote:

 In fact, it was me who named it TypeSuffix; before, it was 
 BasicType2X


Thanks!


 StaticArray:
     [ AssignExpression ]


A type sequence can be indexed, so calling it StaticArray would 
be confusing.

...

 I think it’s best to leave some of the grammar to prose and 
 explain what things mean in the section below the formal 
 grammar box.


+1
Sep 05
next sibling parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Thursday, 5 September 2024 at 19:32:52 UTC, Nick Treleaven 
wrote:

 On Thursday, 5 September 2024 at 14:22:56 UTC, Quirin Schroll 
 wrote:

 In fact, it was me who named it TypeSuffix; before, it was 
 BasicType2X


 Thanks!


 StaticArray:
     [ AssignExpression ]


 A type sequence can be indexed, so calling it StaticArray would 
 be confusing.


Of course. I missed that. Another reason not to name it!
Sep 06
prev sibling parent user1234 <user1234 12.de> writes:
On Thursday, 5 September 2024 at 19:32:52 UTC, Nick Treleaven 
wrote:

 On Thursday, 5 September 2024 at 14:22:56 UTC, Quirin Schroll 
 wrote:

 In fact, it was me who named it TypeSuffix; before, it was 
 BasicType2X


 Thanks!


 StaticArray:
     [ AssignExpression ]


 A type sequence can be indexed, so calling it StaticArray would 
 be confusing.


That does not matter. What matters is how the construct is 
initially parsed then in the specs you define "if the StaticArray 
sub-type resolves to a  sequence then ... ". But then you also 
have to define types like exposed in 
https://forum.dlang.org/post/kabzzfxlwgyzoidpxcbe forum.dlang.org, i.e drop the
suffix idea and in favor of the recursive descent style.
Sep 06