Thoughts about "Compile-time types" talk

[Alex]

On Friday, 17 May 2019 at 08:47:19 UTC, NaN wrote:
> On Thursday, 16 May 2019 at 09:35:16 UTC, Alex wrote:
>> On Thursday, 16 May 2019 at 08:12:49 UTC, NaN wrote:
>>
>> No, you don't get it.
>
> Unsurprisingly I feel that neither do you, at least you dont 
> get what Im saying, or rather you think Im saying something 
> that Im not.
>
>
>> We are talking about a hypothetical compiler that doesn't have 
>> to have different contexts. In D, the contexts arbitrarily 
>> separated in the language...
>
> I don't see how it can not have different contexts, it runs at 
> compile time, produces a binary and that runs at runtime. You 
> can hide that fact, make it so code looks and works the same in 
> each context as much as possible. But you cant not have that be 
> what actually happens.
>
>
>> What we are ultimately talking about here is that CT and RT is 
>> not two different concepts but one concept with some very 
>> minute distinction for RT.
>
> Yes, exactly my point, there will be differences. Andrei did a 
> talk on why C++s static if was next to useless because it 
> introduces a new scope. That's all I was pointing out, regular 
> if and static if behave differently in D. And with good reason.
>
>
>> As a programmer you shouldn't care if something is CT or RT 
>> and hence you shouldn't even know there is a difference.
>
> Like most things that "just work" you dont care until you do.
>
>
>> What are you saying is that you have one if and two contexts. 
>> What I'm saying is  hat you have one if and one context. That 
>> the CT programming and runtime programming are NOT treated as 
>> being two different universes with some overlap but the same 
>> universe with a slight boundary.
>
> 100% it'd be great if RT/CT were "same rules apply", but i was 
> just pointing out one of the "boundaries" where that is 
> currently not the case.
>
>
>> enum x = 4;
>> and
>> int y = 4;
>>
>> That is explicitly two different programming contexts. On CT 
>> and the other RT. But that is the fallacy. They are EXACTLY 
>> identical programmatically.
>
> static if (x) {}
> and
> if (y) {}
>
> Are currently not identical grammatically. One introduces a new 
> scope and one does not.
>
>
>> Only when y is modified at some point later in the code does 
>> things potentially change. enum says we will never change x at 
>> CT... but why can't the compiler figure that out automatically 
>> rather than forcing us to play by it's rules and have a 
>> separate context?
>
> Defining a constant is not you informing the compiler you wont 
> change the value, it's you telling the compiler to make sure 
> that you dont. That cant be inferred by the compiler because 
> the act of modifying it would destroy the inference that it 
> should not be modified. It's catch 22.

There is a different between what the D compiler does, what it 
should do and what all compilers should do. Compilers must evolve 
and it requires changes. The reason why static if does not create 
a new scope is because one cannot create variables inside a 
normal if and them be seen outside. This is a limitation of if, 
not the other way around.

For example, if D had two types of scoping, say [] and {} then 
would not need static if.

if (x) [ ] <- does not create a scope for variable creation
if (x) { } <- standard

Many times we have to declare the variable outside of an if 
statement just to get things to work. Now, of course this is not 
great practice because the variable may not be created but used 
afterwards. static if already has that issue though.


The point is that you are trying to explain the issues that make 
it hard for D to do certain things when I'm talking about what D 
should do as if it didn't have the issues.

D was designed with flaws in it... that has to be accepted. But 
if you take those flaws as set in stone then there is never any 
point of making D better. You basically assume that it has no 
flaws(if you assume they can't be changed then you are 
effectively assuming it is perfect).

You need to learn to think about side the box a little more... 
thinking inside the box is easy. Everyone knows what D does and 
it's flaws(more or less, but flaws are generally easy to spot).

But if you can't imagine what D could be without the flaws then 
really, you don't see the flaws.

To truly see the flaws in something requires that you also see 
beyond those flaws, as if D existed in an alternate universe and 
didn't have them. From there one can work on fixing those flaws 
and making D better.

So, yes, D has issues. We have static if and if and CT and RT 
boundaries. Just arbitrarily trying to combine them will be 
impossible in D as we know it. That should be obvious(that is why 
the distinction exists and why we are talking about it. If it 
didn't have these issues we would be talking about other issues 
or none at all).

But the question is, how to fix these issues in the right way? 
First, are they fixable? Well, everything is fixable because one 
can just throw it away and start afresh. Is it worth fixing? That 
is up to the beholder.

Generally though, people that want something better(to fix a 
flaw) work towards a solution first by trying to quantify the 
flaw and think outside the box. By thinking about what they flaw 
is a flaw. This requires moving past what is and towards what 
could be. You are stuck in the IS part of the equation. I am 
stuck in the COULD BE. But why you are wrong is that you don't 
seem to realize this is a COULD BE thread. It's true that in some 
sense one ultimately has to deal with the practical issues of IS, 
but one has to get the order right. First one has to know where 
to go(the could be) before they actually start the travel(the IS).

So, yes, everything you have said, in the context of what IS, is 
true. But it is not helpful. The whole discussion is about the 
flaw in what IS and how to get beyond it. In the context of COULD 
BE you are wrong, because you are staying at home not going 
anywhere(you are focusing on the flaw and letting the flaw stay a 
flaw by not thinking beyond it).

Your thinking pattern probably invades every aspect of your life. 
You focus on more practical rather than theoretical aspects of 
stuff. Hence it's hard for you to think outside the box but you 
can think inside the box well. You get in to arguments with 
people because what they say doesn't make sense in your box. You 
fail to realize there are many boxes... many different levels to 
view, and understand. I too have a similar problem, completely 
opposite in some sense. I am an outside thinker. I tend to forget 
that some people are inside thinkers. I can think inside the box, 
but it is not my preferred medium(it's very limiting to me). I 
think you should ask yourself if you can think outside the box. 
If not then it is a flaw you have and you should work on fixing 
it as it will make you a much more balanced and powerful human. 
If it's just your preference then just try to keep in mind that 
you will interact with other types of thinkers in the world. (and 
try to parse which box people are thinking in based on context)

[And the fact is everyone thinks in different boxes and there 
tends to be a lot of confusion the world because "every" assumes 
everyone else thinks in the same box]