Re: RFC to: my need for 'static switch' and CT 'static variables'

[Alexey via Digitalmars-d-learn]

On Friday, 26 November 2021 at 00:41:34 UTC, Elronnd wrote:

you are right. thanks

Re: RFC to: my need for 'static switch' and CT 'static variables'

[Elronnd via Digitalmars-d-learn]

static if (...) {
} else static if (...) {
} else {
static assert(0);
}

Re: RFC to: my need for 'static switch' and CT 'static variables'

[Alexey via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 22:00:15 UTC, Alexey wrote:

I would want an static 'switch here',


I mean something like
```D
static switch (v.mode)
{
default:
   static assert(false, "v.mode" is invalid)
case "gs_w_d":
 // etc...
}
```

RFC to: my need for 'static switch' and CT 'static variables'

[Alexey via Digitalmars-d-learn]

for example, I have the code (code in sample generates different 
types of Properties dependingly on struct's mode value):

```D
struct PropSetting
{
string mode;
string type;
string var_name;
string title_name;
string default_value;
}

mixin template mixin_install_multiple_properties(PropSetting[] 
settings)

{
import std.format;

static foreach (v; settings)
{
static if (v.mode == "gs_w_d")
{
mixin(
q{
private {
mixin Property_%1$s!(%2$s, "%3$s", %5$s);
}

mixin Property_forwarding!(%2$s, %3$s, 
"%4$s");


}.format(
v.mode,
v.type,
v.var_name,
v.title_name,
v.default_value,
)
);
}

static if (v.mode == "gsu" || v.mode == "gs" || v.mode == 
"gsun")

{
mixin(
q{
private {
mixin Property_%1$s!(%2$s, "%3$s");
}

mixin Property_forwarding!(%2$s, %3$s, 
"%4$s");


}.format(
v.mode,
v.type,
v.var_name,
v.title_name,
)
);
}

}
}
```
currently it works kind of ok. but what it's missing is check on 
what none of [static if]s have worked. Ideally, I would want an 
static 'switch here', so I could make `static assert(false)` in 
it. and/or I'd like some sort of [compile time variable] to 
change it if  [static if]s have worked and check such [compile 
time variable] later.

Re: What is pure used for?

[Paul Backus via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 07:26:48 UTC, sclytrack wrote:

int * pureFunction()

1) the pointer needs to be the same.
2) the value that the pointer points to needs to be the same. I 
call this the "value

of interest" with relation to pure. The pointer doesn't matter.
3) both the pointer and the value the pointer is pointing too 
needs to be the same.


pureCalloc() satisfies (2)
pureMalloc() violates everything.


There is a special case in the language spec to allow functions 
like `pureMalloc`. They are called "pure factory functions":


A *pure factory function* is a strongly pure function that 
returns a result that has mutable indirections. All mutable 
memory returned by the call may not be referenced by any other 
part of the program, i.e. it is newly allocated by the 
function. Nor may the mutable references of the result refer to 
any object that existed before the function call.


Source:  
(scroll down)



Does the D compiler do any optimizations?


Yes, but those optimizations may result in implementation-defined 
behavior:


**Implementation Defined:** An implementation may assume that a 
strongly pure function that returns a result without mutable 
indirections will have the same effect for all invocations with 
equivalent arguments. It is allowed to memoize the result of 
the function under the assumption that equivalent parameters 
always produce equivalent results. [...] An implementation is 
currently not required to enforce validity of memoization in 
all cases.


The term "equivalent" is not explicitly defined, but as far as I 
can tell it means something like item (2) in your list.

Re: Attributes (lexical)

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 12:16:50 UTC, rumbu wrote:
I try to base my reasoning on specification, dmd is not always 
a good source of information, the lexer is polluted by old 
features or right now by the ImportC feature, trying to lex D 
an C in the same time.


Alright. I haven't looked at it after the ```importC``` feature 
was started on.


(The lexer code takes a bit of browsing to get used to, but it 
isn't all that challenging once you are into it.)

Re: Attributes (lexical)

[Dennis via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 12:09:55 UTC, Dennis wrote:

This should also be fixed in the spec.


Filed as:

Issue 22543 - [spec] grammar blocks use unspecified notation:
https://issues.dlang.org/show_bug.cgi?id=22543

Issue 22544 - [spec] C++ and Objective-C are not single tokens
https://issues.dlang.org/show_bug.cgi?id=22544

Re: Attributes (lexical)

[rumbu via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 11:25:49 UTC, Ola Fosheim 
Grøstad wrote:

On Thursday, 25 November 2021 at 10:41:05 UTC, Rumbu wrote:
I am not asking this questions out of thin air, I am trying to 
write a conforming lexer and this is one of the ambiguities.


I think it is easier to just look at the lexer in the dmd 
source. The D language does not really have a proper spec, it 
is more like an effort to document the implementation.


I try to base my reasoning on specification, dmd is not always a 
good source of information, the lexer is polluted by old features 
or right now by the ImportC feature, trying to lex D an C in the 
same time.


DMD skips the new line if the file was not specified, that's why 
the "filename" is unexpected on a new line:

https://github.com/dlang/dmd/blob/d374003a572fe0c64da4aa4dcc55d894c648514b/src/dmd/lexer.d#L2838

libdparse completely ignores the contents after #line skipping 
everything until EOL, even a EOF/NUL marker which should end the 
lexing:

https://github.com/dlang-community/libdparse/blob/7112880dae3f25553d96dae53a445c16261de7f9/src/dparse/lexer.d#L1100

Re: Attributes (lexical)

[zjh via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 08:06:27 UTC, rumbu wrote:


#

//this works

line


I hate `#`.

Re: Attributes (lexical)

[Dennis via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 10:41:05 UTC, Rumbu wrote:

Well:

```
#line IntegerLiteral Filespec? EndOfLine
```

Having EndOfLine at the end means for me that there are no 
other EOLs between, otherwise this syntax should pass but it's 
not (DMD last):


```d
#line 12
"source.d"
```


The lexical grammar section starts with:

The source text is decoded from its source representation into 
Unicode Characters. The Characters are further divided into: 
WhiteSpace, EndOfLine, Comments, SpecialTokenSequences, and 
Tokens, with the source terminated by an EndOfFile.


What it's failing to mention is how in the lexical grammar rules, 
spaces denote 'immediate concatenation' of the characters/rules 
before and after it, e.g.:

```
DecimalDigits:
DecimalDigit
DecimalDigit DecimalDigits
```
`3 1  4` is not a single `IntegerLiteral`, it needs to be `314`.

Now in the parsing grammar, it should mention that spaces denote 
immediate concatenation of *Tokens*, with arbitrary *Comments* 
and *WhiteSpace* inbetween. So the rule:

```
AtAttribute:
@ nogc
```
Means: an @ token, followed by arbitrary comments and whitespace, 
followed by an identifier token that equals "nogc". That explains 
your first example.


Regarding this lexical rule:
```
#line IntegerLiteral Filespec? EndOfLine
```
This is wrong already from a lexical standpoint, it would suggest 
a SpecialTokenSequence looks like this:

```
#line10"file"
```

The implementation actually looks for a # token, skips 
*WhiteSpace* and *Comment*s, looks for an identifier token 
("line"), and then it goes into a custom loop that allows 
separation by *WhiteSpace* but not *Comment*, and also the first 
'\n' will be assumed to be the final *EndOfLine*, which is why 
this fails:

```
#line 12
"source.d"
```
It thinks it's done after "12".

In conclusion the specification should:
- define the notation used in lexical / parsing grammar blocks
- clearly distinguish lexical / parsing blocks
- fix up the `SpecialTokenSequence` definition (and maybe change 
dmd as well)


By the way, the parsing grammar defines:
```
LinkageType:
C
C++
D
Windows
System
Objective-C
```
C++ and Objective-C cannot be single tokens currently, so they 
are actually 2/3, which is why these are allowed:


```D
extern(C
   ++)
void f() {}

extern(Objective
   -
   C)
void g() {}
```
This should also be fixed in the spec.

I am not asking this questions out of thin air, I am trying to 
write a conforming lexer and this is one of the ambiguities.


That's cool! Are you writing an editor plugin?

Re: Include .def definition file information for the linker into a .d source file

[Imperatorn via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 09:47:50 UTC, Stanislav Blinov 
wrote:

On Thursday, 25 November 2021 at 09:00:52 UTC, Imperatorn wrote:

What most ppl do in that case is to just provide a script, for 
example build.cmd that just does what it needs. The user just 
clicks the script and it does everything for them.


"How can I make it so that I don't need an extra file written 
in another language?"

"Just add yet another file written in yet another language".

Nice going there :)

Build scripts never have been scalable. A good language shall 
only require a compiler and source file(s). No extra voodoo 
mumbojumbo. This is why we have all those pragmas and the -i 
switch.


Scalable or not it's a pretty common pattern. The build script is 
modular.


I wouldn't call the linker "mumbojumbo". Voodo maybe, yes.

Re: Attributes (lexical)

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 10:41:05 UTC, Rumbu wrote:
I am not asking this questions out of thin air, I am trying to 
write a conforming lexer and this is one of the ambiguities.


I think it is easier to just look at the lexer in the dmd source. 
The D language does not really have a proper spec, it is more 
like an effort to document the implementation.

Re: Attributes (lexical)

[Rumbu via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 10:10:25 UTC, Dennis wrote:

On Thursday, 25 November 2021 at 08:06:27 UTC, rumbu wrote:
Also, this works also for #line, even if the specification 
tells us that all tokens must be on the same line


Where does it say that?


Well:

```
#line IntegerLiteral Filespec? EndOfLine
```

Having EndOfLine at the end means for me that there are no other 
EOLs between, otherwise this syntax should pass but it's not (DMD 
last):


```d
#line 12
"source.d"
```

I am not asking this questions out of thin air, I am trying to 
write a conforming lexer and this is one of the ambiguities.

Re: Attributes (lexical)

[Dennis via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 08:06:27 UTC, rumbu wrote:
Also, this works also for #line, even if the specification 
tells us that all tokens must be on the same line


Where does it say that?

Re: Include .def definition file information for the linker into a .d source file

[Stanislav Blinov via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 09:00:52 UTC, Imperatorn wrote:

What most ppl do in that case is to just provide a script, for 
example build.cmd that just does what it needs. The user just 
clicks the script and it does everything for them.


"How can I make it so that I don't need an extra file written in 
another language?"

"Just add yet another file written in yet another language".

Nice going there :)

Build scripts never have been scalable. A good language shall 
only require a compiler and source file(s). No extra voodoo 
mumbojumbo. This is why we have all those pragmas and the -i 
switch.

Re: Attributes (lexical)

[Elronnd via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 08:06:27 UTC, rumbu wrote:

Is that ok or it's a lexer bug?


@ (12) does exactly what I would expect.  @nogc I always assumed 
was a single token, but the spec says otherwise.  I suppose that 
makes sense.


#line is dicier as it is not part of the grammar proper; however 
the spec describes it as a 'special token sequence', and comments 
are not tokens, so I think the current behaviour is correct.

Re: Include .def definition file information for the linker into a .d source file

[zjh via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 06:56:38 UTC, BoQsc wrote:


In other words: as simple as possible to use.


`dmd -i`,no need `one big file`.

Re: Include .def definition file information for the linker into a .d source file

[Imperatorn via Digitalmars-d-learn]

On Wednesday, 24 November 2021 at 17:06:21 UTC, BoQsc wrote:
I'm not sure if I have sucessfully achieved something like this 
before or is it even possible right now, but there is a sample 
file that comes with DMD compiler: `D\dmd2\samples\d\winsamp.d`


**The problem:** `winsamp.d` have to be compiled with `.def` 
file.

```
/+ Compile with:
 +  dmd winsamp winsamp.def
 + or:
 +  dmd winsamp -L-Subsystem:Windows
 +
 + 64 bit version:
 +  dmd -m64 winsamp -L-Subsystem:Windows user32.lib
 +/
```

This is how the `.def` file looks like
(`D\dmd2\samples\d\winsamp.def`):
```
EXETYPE NT
SUBSYSTEM WINDOWS

```

**The question:** Is there a way to include the `.def` file 
instructions inside `.d` file, so that there won't be a need 
for additional `.def` file when compiling. (`dmd winsamp`)


What most ppl do in that case is to just provide a script, for 
example build.cmd that just does what it needs. The user just 
clicks the script and it does everything for them.

Re: What is pure used for?

[zjh via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 07:26:48 UTC, sclytrack wrote:
My understanding is that pure is used for compiler optimization 
in loops and expressions. It leaves out multiple calls if it 
figures out it is not needed.




[one 
link](https://klickverbot.at/blog/2012/05/purity-in-d/#indirections-in-the-return-type) and [another](https://theartofmachinery.com/2016/03/28/dirtying_pure_functions_can_be_useful.html)

Re: What is pure used for?

[Imperatorn via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 07:26:48 UTC, sclytrack wrote:
My understanding is that pure is used for compiler optimization 
in loops and expressions. It leaves out multiple calls if it 
figures out it is not needed.


Is pure used for anything else?


int * pureFunction()

1) the pointer needs to be the same.
2) the value that the pointer points to needs to be the same. I 
call this the "value

of interest" with relation to pure. The pointer doesn't matter.
3) both the pointer and the value the pointer is pointing too 
needs to be the same.


pureCalloc() satisfies (2)
pureMalloc() violates everything.

Does the D compiler do any optimizations?


https://dlang.org/spec/function.html#pure-functions

Re: Attributes (lexical)

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Thursday, 25 November 2021 at 08:06:27 UTC, rumbu wrote:

Is that ok or it's a lexer bug?


Yes. The lexer just eats whitespace and the parser accepts way 
too much.

Attributes (lexical)

[rumbu via Digitalmars-d-learn]

Just playing around with attributes.

This is valid D code:

```d

@


nogc: //yes, this is @nogc in fact, even some lines are between


@

/* i can put some comments
*/

/** even some documentation
*/

// single line comments also

(12)

// yes, comments and newlines are allowed between attribute and 
declaration



int x; //@(12) is attached to declaration
```

Is that ok or it's a lexer bug?


Also, this works also for #line, even if the specification tells 
us that all tokens must be on the same line



```d

#

//this works

line

/* this too */

12

//this is #line 12


```