Bug in D!!!

[EntangledQuanta via Digitalmars-d-learn]

On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner 
wrote:
> On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta 
> wrote:
>> On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner 
>> wrote:
>>> On Saturday, 2 September 2017 at 23:12:35 UTC, 
>>> EntangledQuanta wrote:
>>>> [...]
>>>
>>> The contexts being independent of each other doesn't change 
>>> that we would still be overloading the same keyword with 
>>> three vastly different meanings. Two is already bad enough 
>>> imho (and if I had a good idea with what to replace the "in" 
>>> for AA's I'd propose removing that meaning).
>>
>> Why? Don't you realize that the contexts matters and [...]
>
> Because instead of seeing the keyword and knowing its one 
> meaning you also have to consider the context it appears in. 
> That is intrinsically more work (though the difference may be 
> very small) and thus harder.
>
> ...

Yes, In an absolute sense, it will take more time to have to 
parse the context. But that sounds like a case of 
"pre-optimization". If we are worried about saving time then what 
about the tooling? compiler speed? IDE startup time? etc? All 
these take time too and optimizing one single aspect, as you 
know, won't necessarily save much time.

Maybe the language itself should be designed so there are no 
ambiguities at all? A single simple for each function? A new 
keyboard design should be implemented(ultimately a direct brain 
to editor interface for the fastest time, excluding the time for 
development and learning)?

So, in this case I have to go with the practical of saying that 
it may be theoretically slower, but it is such an insignificant 
cost that it is an over optimization. I think you would agree, at 
least in this case. Again, the exact syntax is not import to me. 
If you really think it matters that much to you and it does(you 
are not tricking yourself), then use a different keyword.

When I see something I try to see it at once rather than reading 
it left to right. It is how music is read properly, for example. 
One can't read left to right and process the notes in real time 
fast enough. You must "see at once" a large chunk.

When I see foo(A in B)() I see it at once, not in parts or 
sub-symbols(subconsciously that may be what happens, but it 
either is so quick or my brain has learned to see differently 
that I do not feel it to be any slower).

that is, I do not read it like f, o, o (, A,  , i,...

but just like how one sees an image. Sure, there are clustering 
such as foo and (...), and I do sub-parse those at some point, 
but the context is derived very quickly. Now, of course, I do 
make assumptions to be able to do that. Obviously I have to sorta 
assume I'm reading D code and that the expression is a templated 
function, etc. But that is required regardless.

It's like seeing a picture of an ocean. You can see the global 
characteristics immediately without getting bogged down in the 
details until you need it. You can determine the approximate time 
of day(morning, noon, evening, night) relatively instantaneously 
without even knowing much else.

To really counter your argument: What about parenthesis? They too 
have the same problem with in. They have perceived ambiguity... 
but they are not ambiguity. So your argument should be said about 
them too and you should be against them also, but are you? [To be 
clear here: foo()() and (3+4) have 3 different use cases of 
()'s... The first is templated arguments, the second is function 
arguments, and the third is expression grouping]

If you are, then you are being logical and consistent, If you are 
not, then you are not being logical nor consistent. If you fall 
in the latter case, I suggest you re-evaluate the way you think 
about such things because you are picking and choosing.

Now, if you are just stating a mathematical fast that it takes 
longer, then I can't really deny that, although I can't 
technically prove it either as you can't because we would require 
knowing exactly how the brain processes the information.





>
>>
>>
>>>> [...]
>>>
>>> Well, yes, as I wrote, I think it is unambiguous (and can 
>>> thus be used), I just think it shouldn't be used.
>>
>> Yes, but you have only given the reason that it shouldn't be 
>> used because you believe that one shouldn't overload keywords 
>> because it makes it harder to parse the meaning. My rebuttal, 
>> as I have said, is that it is not harder, so your argument is 
>> not valid. All you could do is claim that it is hard and we 
>> would have to find out who is more right.
>
> As I countered that in the above, I don't think your rebuttal 
> is valid.

Well, hopefully I countered that in my rebuttal of your rebuttal 
of my rebuttal ;) Again, you don't actually know how the brain 
processes information(no one does, it is all educated guesses). 
You use the concept that the more information one has to process 
the more time it takes... which seems logical, but it is not 
necessarily applicable directly to the interpretation of written 
symbols. Think of an image. We can process a ton of information 
nearly instantly, and if the logic applied, we would expect 
images to take much longer to "read" than the written word, yet 
it is exactly the opposite... and yet, symbols are just 
images(with a specific order we must follow to make sense of 
them).

Have you ever thought of a programming language that was based on 
images? Maybe that would be a much quicker way and much faster to 
"read" the source? Of course, some might claim that all life is 
is source code and "real life" is just the most natural 
representation of code.

>>
>> I have a logical argument against your absolute restriction 
>> though... in that it causes one to have to use more symbols. I 
>> would imagine you are against stuff like using "in1", "in2", 
>> etc because they visibly are to close to each other.
>
> It's not an absolute restriction, it's an absolute position 
> from which I argue against including such overloading on 
> principle.
> If it can be overcome by demonstrating that it can't sensibly 
> be done without more overloading and that it adds enough value 
> to be worth the increases overloading, I'd be fine with 
> inclusion.

My feeling is though you are actually just making principles 
based on whim rather than a true logical basis, I could be wrong. 
Depending on how you answer my questions above will let me know 
better.

To simplify it down: Do you have the sample problems with all the 
ambiguities that already exist in almost all programming 
languages that everyone is ok with on a practical level on a 
daily basis?


>>
>>>> [...]

>>
>> If that is the case then go for it ;) It is not a concern of 
>> mine. You tell me the syntax and I will use it. (I'd have no 
>> choice, of course, but if it's short and sweet then I won't 
>> have any problem).
>
> I'm discussing this as a matter of theory, I don't have a use 
> for it.

Ok, I do, which is what led me to the problem, as all my 
"enhancements" do. I try something I think is an "elegant" way to 
simplify complexity in my program(from the user of the code's 
perspective, which will generally be me)... I run in to a wall, I 
post a message, and I usually get shot down immediately with "It 
can't be done"... then I have to find a way to do it. I find the 
way[usually using string mixins, thank god for them]. Post it... 
someone else then usually comes along with a better or simpler 
way. Usually when I say something like "This should be in the 
compiler", I immediately get shot down again with "It adds 
complexity to the compiler". In which case I try to to explain 
that everything adds complexity and this solution would add very 
little complexity since one can already do it in the library in a 
simple way... Usually the library solution is not robust and 
hence not good(I only worked it out enough for my use cases). 
...and so the wheel goes around and around. But the logic is 
usually the same. "we can't do that".... which I eventually just 
interpret as "we don't wanna do that because we have better 
things to do", which is fine if at least that was admitted in the 
first place instead of wasting my time trying to explain that it 
can be done, coming up with a solution, etc. (of course, it's 
ultimately my fault since I am the one in control of my time, I 
mainly do it because it could help others in the same position 
that I was in)



>>
>>>> [...]
>>>
>>> Quoting a certain person (you know who you are) from DConf 
>>> 2017: "Write a DIP".
>>> I'm quite happy to discuss this idea, but at the end of the 
>>> day, as it's not an insignificant change to the language 
>>> someone will to do the work and write a proposal.
>>>
>>
>> My main issues with going through the trouble is that 
>> basically I have more important things to do. If I were going 
>> to try to get D to do all the changes I actually wanted, I'd 
>> be better off writing my own language the way I envision it 
>> and want it... but I don't have 10+ years to invest in such a 
>> beast and to do it right would require my full attention, 
>> which I'm not willing to give, because again, I have better 
>> things to do(things I really enjoy).
>>
>> So, all I can do is hopefully stoke the fire enough to get 
>> someone else interested in the feature and have them do the 
>> work. If they don't, then they don't, that is fine. But I feel 
>> like I've done something to try to right a wrong.
>
> That could happen, though historically speaking, usually things 
> have gotten included in D only when the major proponent of 
> something like this does the hard work (otherwise they seem to 
> just fizzle out).

Yes. Because things take time and we only have so much. I am fine 
with that. I'm fine with a great idea going no where because no 
one has the time to invest in it. It's unfortunate but life is 
life... it's only when people ultimately are trying to deceive 
that or are just truly ignorant when I start to have a problem 
with them.

>
>>
>>>> [...]
>>>
>>> AFAIK the difference between syntax sugar and enabling syntax 
>>> in PLs usually comes down to the former allowing you to 
>>> express concepts already representable by other constructs in 
>>> the PL; when encountered, the syntax sugar could be lowered 
>>> by the compiler to the more verbose syntax and still be both 
>>> valid in the PL and recognizable as the concept (while this 
>>> is vague, a prominent example would be lambdas in Java 8).
>>
>> Yes, but everything is "lowered" it's just how you define it.
>
> Yes and w.r.t to my initial point, I did define it as "within 
> the PL itself, preserving the concept".
>
>>
>>
>>>> [...]
>>>
>>> Why do you think that? Less than ten people have participated 
>>> in this thread so far.
>>
>> I am not talking about just this thread, I am talking about in 
>> all threads and all things in which humans attempt to 
>> determine the use of something. [...]
>
> Fair enough, though personally I'd need to see empirical proof 
> of those general claims about human behaviour before I could 
> share that position.

Lol, you should have plenty of proof. Just look around. Just look 
at your own experiences in your life. I don't know much about you 
but I imagine that you have all the proof you need. Look how 
businesses are ran. Look how people "solve" problems. Look at the 
state of the world. You can make claims that it's this and that, 
as I can... but there is a common denominator among it all.

Also just think about how humans are able to judge things. Surely 
they can only judge it based on what they know? How can we judge 
things based on what we don't know? Seems impossible, right? Take 
someone you know that makes constantly makes bad decisions... 
why? Are they geniuses or idiots? I think it's pretty provable 
that the more intelligent a person is the better they are able to 
make decisions about something... and this is general. A 
programmer is surely able to make better decisions about coding 
than a non-programmer? Look at all the business people in the 
world who know absolutely nothing about technological factors but 
make such decisions about them on a daily basis... and the 
ramifications of those decisions are easily seen.

I'm not saying it's a simple problem, but there are relatively 
simple overarching rules involved. The more a person knows about 
life the more they can make better decisions about life. (but the 
life thing is the complex part, I don't disagree)

To make this tie in to what we are talking about: If someone 
never used templated functions in D, how can they make decisions 
on whether templated functions are useful or not? Should be 
obvious. The complexity comes in with they actually have used 
them... but then we have to know "How much do they use them", 
"How do they use them", "What other things do they know about 
that influence there usage of them", etc?

Most people are satisfies with just stopping at some arbitrary 
point when they get tired and have to go to bed... I'm not one of 
those people(for better or worse).


>
>>>> [...]
>>>
>>> Why do you assume that? I've not seen anyone here claiming 
>>> template parameter specialization to one of n types (which is 
>>> the idea I replied to) couldn't be done in theory, only that 
>>> it can't be done right now (the only claim as to that it 
>>> can't be done I noticed was w.r.t. (unspecialized) templates 
>>> and virtual functions, which is correct due to D supporting 
>>> separate compilation; specialized templates, however, should 
>>> work in theory).
>>
>> Let me quote the first two responses:
>>
>> "It can't work this way. You can try std.variant."
>
> That is a reply to your mixing (unspecialized) templates and 
> virtual functions, not to your idea of generalizing specialized 
> templates.

That might have been the reply, and it may be valid in a certain 
context, and may actually be the correct reply in the context I 
gave(I could have done a better job, I admit),

BUT, if D already implemented such a specialization feature, a 
different response would have occurred such as: "You need to 
limit T to be in a finite set", which I would have merrily moved 
along.

But it tries to force me to in a solution that is not acceptable.

In fact, I was using specialization as `T` could only be from a 
finite set... but, again, D does not allow me any way to specify 
that, so how could I properly formulate a solution that would 
make sense without going in to a lot of detail... a lot of 
details that I actually don't know because I'm not a full time D 
aficionado.

The code I posted was a simplification, possibly an 
oversimplification, of my real code in which I tried to express 
something I wanted to do, knew that there should be no real 
technical limitations(in what I wanted, not in how D does it), 
and thought that D should be able to D it in some way(mainly 
because it can do just about anything in some way due to it's 
rich feature set).

>>
>> and
>>
>> "It is not possible to have a function be both virtual and 
>> templated. A function template generates a new function 
>> definition every time that it's a called with a new set of 
>> template arguments. [...]"
>
> Same here.

But it's not true... unless you mean that "it is not possible 
currently in D to do this.

Neither of those statements are logically valid, because it is 
possible(Only with a restricted number of template parameter 
values). It is only true about an  infinite number, which didn't 
apply to me since I had a finite number.

Basically an absolute statement is made: something like "All 
numbers are odd", which is absolute false even if it is partially 
true. "All odd numbers are odd" is obviously true. One should 
even clarify, if the context isn't clear so no confusion arise.

"It is not possible to have a function be both virtual and 
templated."

Surely you disagree with that statement? While there is some 
ambiguity, since templated functions are actually syntactic sugar 
while virtual functions are actually coded, we can obviously have 
a virtual templated function. (Not in D currently, but there is 
no theoretical reason why it can't exist, we've already discussed 
on that)

"It is not possible to have a function be both virtual and 
[arbitrarily] templated." Would, I believe, be a true statement.

while

"It is not possible to have a function be both virtual and 
[finitely] templated." would be a false statement.

In fact, I bet if you asked Jonathan, what he believed when he 
wrote that, that he believed it to be true for all cases(finite 
or not, as he probably never even thought about the finite case 
enough to realize it matters).

Anyways, we've beat this horse to death! I think we basically 
agree on the bulk of things, so it's not a big deal.  Most of the 
issue with communication is the lack of clarity and the ambiguity 
in things(wars have been started and millions of people have died 
over such things as have many personal relationships destroyed).

I'd like to see such a feature implemented in D one day, but I 
doubt it will for whatever reasons. Luckily D is powerful enough 
to still get at a solid solution.. unlike some languages, and I 
think that is what most of us here realize about D and why we 
even bother with it.