On 1/7/2024 8:00 PM, H. S. Teoh wrote:
> [...]

Over the years, again and again, I've seen published benchmarks (including ones posted in this forum) that purport to benchmark a section of code, yet never realizing that there was a printf and they were just benchmarking printf.

Borland made a very smart move back in the day with TurboC. The Borland C compiler generated rather poor code. So Borland hired a guy who coded their printf implementation in highly optimized assembler. With a fast printf, people tended to not notice the generated C code was slow.

On 1/8/2024 11:44 AM, Bruce Carneal wrote:
> I'm not saying we should drop specs of course, in fact I consider them a requirement at this level, rather that we should understand their limitations and the benefits provided by working code with examples.

I agree, and that's why specifications usually include examples. Examples in the spec should be specific and minimal. A reader should not need to be familiar with SQL code in order to understand string interpolation.

Anyhow, this is now moot, see my new thread topic "Interpolated strings and SQL".

On Mon, Jan 08, 2024 at 03:37:22PM -0800, Walter Bright via Digitalmars-d wrote:
> On 1/7/2024 8:00 PM, H. S. Teoh wrote:
> > [...]
> 
> Over the years, again and again, I've seen published benchmarks (including ones posted in this forum) that purport to benchmark a section of code, yet never realizing that there was a printf and they were just benchmarking printf.

On the other extreme, there were also benchmarks that were actually measuring background noise instead of the function it's purportedly benchmarking, because the optimizer has elided the entire function call after realizing that the return value is never used.  LDC has a tendency to do this. :-P  It also has the tendency of executing simple functions at compile-time and replacing the function call with an instruction that loads the answer.


> Borland made a very smart move back in the day with TurboC. The Borland C compiler generated rather poor code. So Borland hired a guy who coded their printf implementation in highly optimized assembler. With a fast printf, people tended to not notice the generated C code was slow.

:-D


T

-- 
It won't be covered in the book. The source code has to be useful for something, after all. -- Larry Wall

On 1/8/2024 4:51 PM, H. S. Teoh wrote:
> On the other extreme, there were also benchmarks that were actually
> measuring background noise instead of the function it's purportedly
> benchmarking, because the optimizer has elided the entire function call
> after realizing that the return value is never used.

I'm painfully aware of this. My compiler (Datalight C) was the first PC compiler to sport a data flow analysis optimizer. It determined that the benchmark code didn't do anything useful, and so deleted it.

The reviewer never contacted me about this, he just wrote the benchmark roundup article saying that the Datalight compiler was buggy because it didn't execute the benchmark code.

About a year later, other compilers had implemented DFA, and of course this time the reporter got it right.

I'm still mad about that :-/

On 09/01/2024 12:09 PM, Walter Bright wrote:
> On 1/8/2024 8:18 AM, Max Samukha wrote:
>> I don't know why they opted for $$. \ is used for any other escape sequence in D.
> 
> The trouble is \ is already used and consumed when lexing the string. That is why printf uses %%.

It makes no difference.

You would simply be replacing: https://github.com/dlang/dmd/blob/c04ae03765bb1d4da8e6b3d0087d6bc46c5c3789/compiler/src/dmd/lexer.d#L1940

with a check in:

https://github.com/dlang/dmd/blob/c04ae03765bb1d4da8e6b3d0087d6bc46c5c3789/compiler/src/dmd/lexer.d#L1954

Works:

``i"\n"``
``i"\$"``

(with this proposed change)
``i"$$"``

Does not work:

``i"$(\n)``
``i"$(\$)``
``i"$($$)"``

So what behavior are you attributing to this escape, that requires it to not be consistent with double quoted strings?

On 09/01/2024 4:57 PM, Richard (Rikki) Andrew Cattermole wrote:
> |i"$(\n)| |i"$(\$)| |i"$($$)"|

Meant to be:

``i"$(\n)"``

``i"$(\$)"``

``i"$($$)"``

On 1/8/2024 7:57 PM, Richard (Rikki) Andrew Cattermole wrote:
> So what behavior are you attributing to this escape, that requires it to not be consistent with double quoted strings?

At least in DIP1027, the istring is lexed the same as regular strings. The \ is removed.

On 1/8/2024 7:49 PM, Bruce Carneal wrote:
> I don't think we should require an implementation to accompany a proposal.

We don't. We just require an accurate description (i.e. a specification), rather than suggesting reviewers reverse engineer the implementation. Implementations do a lot more than just be a specification - they manage memory, have optimizations, have workarounds for language problems, manage error handling, deal with the operating system, deal with configuration switches, and on and on.


> I do think, however, that proposals that have them will be easier to evaluate properly and deserving of expedited review.

That's true.

On 09/01/2024 5:07 PM, Walter Bright wrote:
> On 1/8/2024 7:57 PM, Richard (Rikki) Andrew Cattermole wrote:
>> So what behavior are you attributing to this escape, that requires it to not be consistent with double quoted strings?
> 
> At least in DIP1027, the istring is lexed the same as regular strings. The \ is removed.

In 1036e they are handled with the same functions that handle string literal escapes. There is no distinction.

Once you are in the expression, the interpolated string handling becomes a parser calling ``scan`` to get tokens where it is doing brace counting.

Essentially the lexer is splitting:

``i"prefix$(Identifier1 3.2)suffix"``

Into:

``"prefix"``

Identifier1

3.2

``"suffix"``