On Friday, 17 March 2017 at 14:27:25 UTC, Adam D. Ruppe wrote:
On Friday, 17 March 2017 at 13:53:58 UTC, Hussien wrote:
Yes, but you have a nested foreach loop. One runtime and one
compile time. The break goes with the runtime loop... but
NORMAL programming logic tells us that the break goes with the
loop that it exists in.
It did. It broke the loop counting the numbers, but continued
the loop of strings normally.
People have requested a `static foreach` before, but that
request has not yet been granted.
They are going to expect them to continue or break out of the
inner most loop that they are called from.
That is exactly what they do, and exactly what happened in all
the examples posted.
You're failing to see what I am talking about. I understand the
compiled code is correct and functions as it should.
What I am talking about is
how the statement
static if (x) continue;
pragma(msg, "called");
vs
static if (x) { } else
pragma(msg, "not called");
They are both semantically equivalent
e.g.,
if (x) continue; foo();
vs
if (x) {} else { foo(); }
Both do the same thing in loops when used in the context I
originally gave. e.g., using a continue to skip over elements of
an interation. Works great in normally programming!
BUT in static programming, the continue FUNCTIONS as a runtime
component... just as you say. BUT that is not how one interprets
it on the static level.
The logic for
if (x) continue; foo();
vs
if (x) {} else { foo(); }
and the logic for
static if (x) continue; foo();
vs
static if (x) {} else { foo(); }
should be identical. Just because we are programming on two
different levels doesn't change the logic(or shouldn't).
The problem, of course, is the continue does exactly what you
claim it does.
But when I am meta programming I am thinking in terms of meta
programming. I program exactly the same way as I do in runtime
programming except for the obvious shifts that are required. But
foreach is a foreach. In runtime it works on runtime stuff and at
compile time it works on compile time stuff.
Effectively I have
runtime_foreach and static_foreach in my head and I magically
disambiguate when required.
But there is no such concept for continue. It is impossible to
"continue" or even "break" a static for each loop. That is what I
am addressing.
SO, because I had a mental glitch and I used continue "thinking"
it would work for the static case, e.g., I assumed it was a
static_continue... when no such thing exists, the code compiled
and did something I did not expect!
YES, It was my fault! BUT the point is that D has that ambiguity.
AND because the flow structures for runtime and compile time are
virtually identical, the mistake is easy to make! Even if not, if
the mistake does occur, it will be a difficult thing to track
down in real world cases that are complex. That is the only point
I am making! It has nothing to do with what D actually does, but
how it does it.
A continue or break should create a warning when used in the
context of a static foreach. OR change the freaken syntax of
static semantics vs runtime. Making them identical is
ridiculously and only leads to these kinds of problems. Sure, it
works in 99% of the cases, but so will a new syntax.
My point is not what D does specifically in compiling source
code, or that it does it right or wrong. I am talking about the
interpretation by a human of the code.
$@#$@($*%**%*#(@(@!)@$_@%%#$#$@#@($!* is some code to some yet to
be created programming language... but it doesn't mean that
humans will be able to interpret it properly. I am talking about
how humans interpret things.
Do you really think that a non-D programmer that sees the code
foreach(x; [1,2,3])
foreach(y; aliasSeqOf![1,2,3])
static if (y == 1) continue;
pragma(msg, y)
is going to be able to interpret the code correctly?
Because if they use a rewrite rule, which is GENERALLY VALID in
all programming languages:
foreach(x; [1,2,3])
foreach(y; aliasSeqOf![1,2,3])
static if (y == 1) {} else
{
pragma(msg, y)
}
(again, this should be the same as the first case, because we can
do that at runtime and it is valid... people write code like that)
Yet one gets a different result.
Hence, if they are programming some NASA rocket, and make that
mistake and the rocket goes left instead of dropping it's
boosters, then what? Who's fault? Is it D's fault for creating
ambiguity between static and runtime programming? Of course it
is, because It sets the foundation for what is to come.
Again, my point is not about D compiling the above code, but
about the syntax/grammar/language issue it creates conceptually.
You may not have that problem because you are familiar enough
with D's meta programming but to someone that isn't, they have to
go on what they know, and there is a problem conceptually they
will have to learn about. It shouldn't be that way. It is a
problem of D treating apples as oranges. foreach != foreach...
does that make sense? Sure, if you already learned, but if you
are learning or have a brain fart, too bad for you...
This is D's approach: "Meta programming - The same as
programming... well almost". The almost part is what gets people
killed.
