Bug in D!!!

[EntangledQuanta via Digitalmars-d-learn]

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:
>> On Saturday, 2 September 2017 at 21:19:31 UTC, Moritz Maxeiner 
>> wrote:
>>> On Saturday, 2 September 2017 at 00:00:43 UTC, 
>>> EntangledQuanta wrote:
>>>> On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips 
>>>> wrote:
>>>>> I've love being able to inherit and override generic 
>>>>> functions in C#. Unfortunately C# doesn't use templates and 
>>>>> I hit so many other issues where Generics just suck.
>>>>>
>>>>> I don't think it is appropriate to dismiss the need for the 
>>>>> compiler to generate a virtual function for every 
>>>>> instantiated T, after all, the compiler can't know you have 
>>>>> a finite known set of T unless you tell it.
>>>>>
>>>>> But lets assume we've told the compiler that it is 
>>>>> compiling all the source code and it does not need to 
>>>>> compile for future linking.
>>>>>
>>>>> First the compiler will need to make sure all virtual 
>>>>> functions can be generated for the derived classes. In this 
>>>>> case the compiler must note the template function and 
>>>>> validate all derived classes include it. That was easy.
>>>>>
>>>>> Next up each instantiation of the function needs a new 
>>>>> v-table entry in all derived classes. Current compiler 
>>>>> implementation will compile each module independently of 
>>>>> each other; so this feature could be specified to work 
>>>>> within the same module or new semantics can be written up 
>>>>> of how the compiler modifies already compiled modules and 
>>>>> those which reference the compiled modules (the object 
>>>>> sizes would be changing due to the v-table modifications)
>>>>>
>>>>> With those three simple changes to the language I think 
>>>>> that this feature will work for every T.
>>>>
>>>> Specifying that there will be no further linkage is the same 
>>>> as making T finite. T must be finite.
>>>>
>>>> C# uses generics/IR/CLR so it can do things at run time that 
>>>> is effectively compile time for D.
>>>>
>>>> By simply extending the grammar slightly in an intuitive 
>>>> way, we can get the explicit finite case, which is easy:
>>>>
>>>> foo(T in [A,B,C])()
>>>>
>>>> and possibly for your case
>>>>
>>>> foo(T in <module>)() would work
>>>>
>>>> or
>>>>
>>>> foo(T in <program>)()
>>>>
>>>> the `in` keyword makes sense here and is not used nor 
>>>> ambiguous, I believe.
>>>
>>> While I agree that `in` does make sense for the semantics 
>>> involved, it is already used to do a failable key lookup 
>>> (return pointer to value or null if not present) into an 
>>> associative array [1] and input contracts. It wouldn't be 
>>> ambiguous AFAICT, but having a keyword mean three different 
>>> things depending on context would make the language even more 
>>> complex (to read).
>>
>> Yes, but they are independent, are they not? Maybe not.
>>
>> foo(T in Typelist)()
>>
>> in, as used here is not a input contract and completely 
>> independent. I suppose for arrays it could be ambiguous.
>
> 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 it's what 
separates the meaning? In truly unambiguous contexts, it 
shouldn't matter. It may require one to decipher the context, 
which takes time, but there is nothing inherently wrong with it 
and we are limited to how many symbols we use(unfortunately we 
are generally stuck with the querty keyboard design, else we 
could use symbols out the ying yang and make things much clearer, 
but even mathematics, which is a near perfect language, 
"overloads" symbols meanings).

You have to do this sort of thing when you limit the number of 
keywords you use. Again, ultimately it doesn't matter. A symbol 
is just a symbol. For me, as long as the context is clear, I 
don't see what kind of harm it can cause. You say it is bad, but 
you don't give the reasons why it is bad. If you like to think of 
`in` has having only one definition then the question is why? You 
are limiting yourself. The natural languages are abound with such 
multi-definitions. Usually in an ambiguous way and it can cause a 
lot of problems, but for computer languages, it can't(else we 
couldn't actually compile the programs). Context sensitive 
grammars are provably more expressive than context free.

https://en.wikipedia.org/wiki/Context-sensitive_grammar

Again, I'm not necessarily arguing for them, just saying that one 
shouldn't avoid them just to avoid them.


>
>>
>> For me, and this is just me, I do not find it ambiguous. I 
>> don't find different meanings ambiguous unless the context 
>> overlaps. Perceived ambiguity is not ambiguity, it's just 
>> ignorance... which can be overcome through learning. Hell, D 
>> has many cases where there are perceived ambiguities... as do 
>> most things.
>
> It's not about ambiguity for me, it's about readability. The 
> more significantly different meanings you overload some keyword 
> - or symbol, for that matter - with, the harder it becomes to 
> read.

I don't think that is true. Everything is hard to read. It's 
about experience. The more you experience something the more 
clear it becomes. Only with true  ambiguity is something 
impossible. I realize that in one can design a language to be 
hard to parse due to apparent ambiguities, but am I am talking 
about cases where they can be resolved immediately(at most a few 
milliseconds).

You are making general statements, and it is not that I disagree, 
but it depends on context(everything does). In this specific 
case, I think it is extremely clear what in means, so it is 
effectively like using a different token. Again, everyone is 
different though and have different experiences that help them 
parse things more naturally. I'm sure there are things that you 
might find easy that I would find hard. But that shouldn't stop 
me from learning about them. It makes me "smarter", to simplify 
the discussion.


>>
>> But in any case, I could care less about the exact syntax. 
>> It's just a suggestion that makes the most logical sense with 
>> regard to the standard usage of in. If it is truly unambiguous 
>> then it can be used.
>
> 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.

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.  If you want 
"maximum" readability you are going to have to mathematically 
define that in a precise way then could up with a grammar that 
expresses it. I think you'll find that the grammar will depend on 
each individual person. At best you could then take an average 
which satisfies most people up to some threshold... in which 
case, at some point in time later, that average will shift and 
your grammar will no longer be valid(it will no longer satisfy 
the average).

Again, it's not that I completely disagree with you on a 
practical level. Lines have to be drawn, but it's about where to 
precisely draw that line. Drawing it in the wrong place leads to 
certain solutions that are generally problematic. That's how we 
know they are wrong, we draw a line and later realize it cause a 
bunch of problems then we say "oh that was the wrong way to do 
it". Only with drawing a bunch of wrong lines can we determine 
which ones are the best and use that info to predict better 
locations.

>>
>> Another alternative is
>>
>> foo(T of Typelist)
>>
>> which, AFAIK, of is not used in D and even most programming 
>> languages. Another could be
>>
>> foo(T -> Typelist)
>>
>> or even
>>
>> foo(T from Typelist)
>
> I would much rather see it as a generalization of existing 
> template specialization syntax [1], which this is t.b.h. just a 
> superset of (current syntax allows limiting to exactly one, you 
> propose limiting to 'n'):
>
> ---
> foo(T: char)      // Existing syntax: Limit T to the single 
> type `char`
> foo(T: (A, B, C)) // New syntax:      Limit T to one of A, B, 
> or C
> ---

Yes, if this worked, I'd be fine with it. Again, I could care 
less. `:` == `in` for me as long as `:` has the correct meaning 
of "can be one of the following" or whatever.

But AFAIK, : is not "can be one of the following"(which is "in" 
or "element of" in the mathematical sense) but can also mean "is 
a derived type of".

All I'm after is the capability to do something elegantly, and 
when it doesn't exist, I "crave" that it does. I don't really 
care how it is done(but remember, it must be done elegantly). I 
am not "confused"(or whatever you want to call it) by symbolic 
notation. As long as it's clearly defined so I can learn the 
definition and it is not ambiguous.

There are all kinds of symbols that can be used, again, we are 
limited by querty(for speed, no one wants to have to use 
alt-codes in programming, there is a way around this but would 
scare most people).

e.g.,

T ∈ X is another expression(more mathematical, I assume that ∈ 
will be displayed correctly, it is Alt +2208) that could work, 
but ∈ is not ascii an so can't be used(not because it can't but 
because of peoples lack of will to progress out of the dark ages).

> Strictly speaking, this is exactly what template specialization 
> is for, it's just that the current one only supports a single 
> type instead of a set of types.
> Looking at the grammar rules, upgrading it like this is a 
> fairly small change, so the cost there should be minimal.
>

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).

The main reason I suggest syntax is because none exist and I 
assume, maybe wrongly, that people will get what I am saying 
easier than writing up some example library solution and 
demonstrating that.

if I say something like

class/struct { foo(T ∈ X)(); }

defines a virtual template function for all T in X. Which is 
equivalent to

class/struct
{
    foo(X1)();
    ...
    foo(Xn)();
}
  I assume that most people will understand, more or less the 
notation I used to be able to interpret what am trying to get at. 
It is a mix of psuedo-programming and mathematics, but it is not 
complex. ∈ might be a bit confusing but looking it up and 
learning about it will educate those that want to be educated and 
expand everyones ability to communicate better. I could, of 
course, be more precise, but I try to be precise only when it 
suits me(which may be fault, but, again, I only have so many 
hours in the day to do stuff).


>>
>> or whatever. Doesn't really matter. They all mean the same to 
>> me once the definition has been written in stone. Could use 
>> `foo(T eifjasldj Typelist)` for all I care.
>
> That's okay, but it does matter to me.


That's fine. I am willing to compromise. Lucky for you, 
symbols/tokens and context are not a big deal to me. Of course, I 
do like short and sweet, so I am biased too, but I have much more 
leeway it seems.


>> The import thing for me is that such a simple syntax exists 
>> rather than the "complex syntax's" that have already been 
>> given(which are ultimately syntax's as everything is at the 
>> end of the day).
>
> 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.

>>
>>
>>> W.r.t. to the idea in general: I think something like that 
>>> could be valuable to have in the language, but since this 
>>> essentially amounts to syntactic sugar (AFAICT), but I'm not 
>>> (yet) convinced that with `static foreach` being included 
>>> it's worth the cost.
>>>
>>
>> Everything is syntactic sugar. So it isn't about if but how 
>> much. We are all coding in 0's and 1's whether we realize it 
>> or not. The point if syntax(or syntactic sugar) is to reduce 
>> the amount of 0's and 1's that we have to *effectively* code 
>> by grouping common patterns in to symbolic equivalents(by 
>> definition).
>
> 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. It 
is all lowering to 0's and 1's. Syntactic sugar is colloquially 
used like you have defined it, but in the limit(the most general 
sense), it's just stuff. Why? Because what is sugar to one person 
is salt to another(this is hyperbole, of course, but you should 
be able to get my point).

e.g., You could define syntactic sugar to be enhancement that can 
be directly rewritten in to a currently expressible syntax in the 
language.

That is fine. But then what if that expressible syntax was also 
syntactic sugar? You end up with something like L(L(L(L(x)))) 
where L is a "lowering" and x is something that is not "lowered". 
But if you actually were able to trace the evolution of the 
compiler, You'd surely notice that x is just L(...L(y)...) for 
some y.

A programming language is simply something that takes a set of 
bits and transforms them to another set of bits. No more and no 
less. Everything else is "syntactic sugar". The definition may be 
so general as to be useless, but it is what a programming 
language is(mathematically at least).

Think about it a bit. How did programmers program before modern 
compilers came along? They used punch cards or levers, which are 
basically setting "bits" or various "function"(behaviors) that 
the machine would carry out. Certain functions and combinations 
of functions were deemed more useful and were combined in to 
"meta-functions" and given special bits to represent them. This 
process has been carried out ad-nauseam and we are were we are 
today because of this process(fundamentally)

But the point is, at each step, someone can claim that the 
current "simplifying" of complex functions in to a 
"meta-function" just "syntactic sugar". This process though is 
actually what creates the "power" in things. Same thing happens 
at the hardware level... same thing happens with atoms and 
molecules(except we are not in control of the rules of how those 
things combine).


>>
>> No one can judge the usefulness of syntax until it has been 
>> created because what determines how useful something is is its 
>> use. But you can't use something if it doesn't exist. I think 
>> many fail to get that.
>
> 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. e.g., the use of computers(used to be 
completely useless for most people because they failed to see the 
use in it(it wasn't useful to them)). The use of medicine... the 
use of a new born baby, the use of life. The use of a turtle. 
People judge use in terms of what it does for them on a 
"personal" level, and my point is, that this inability to see the 
use of something in an absolute sense(how useful is it to the 
whole, be it the whole of the D programming community, the whole 
of humanity, the whole of life, or whatever) is a sever 
shortcoming of almost all humans. It didn't creep up too much in 
this thread but I have definitely see in it other threads. Most 
first say "Well, hell, that won't help me, that is useless". They 
forget that it may be useless to them at that moment, but might 
be useful to them and might be useful to other people.

Why something is useless to someone, though, almost entirely 
depends on their use of it. You can't know how useful something 
is until you use it... and this is why so many people judge the 
use of something the way they do(They can't help it, it's sort of 
law of the universe).

Let me explain, as it might not be clear: Many people many years 
ago used to think X was useless. Today, those same people cannot 
live without X. Replace X with just about anything(computers, 
music, oop, etc). But if you asked those people back then they 
would have told you those things are useless. But through 
whatever means(the way life is) things change and things that 
were previously useless become useful. They didn't know that at 
first because they didn't use those things to find out if they 
were useful.

The same logic SHOULD be applied to everything. We don't know how 
useful something is until we use it *enough* to determine if it 
is useful. But this is not the logic most people use, including 
many people in the D community. They first judge, and almost 
exclusively(depends on the person), how it relates to their own 
person self. This is fundamentally wrong IMO and, while I don't 
have mathematical proof, I do have a lot of experience that tells 
me so(history being a good friend).


>
>> The initial questions should be: Is there a gap in the 
>> language? (Yes in this case). Can the gap be filled? (this is 
>> a theoretical/mathematical question that has to be answered.
>
>> Most people jump the gun here and make assumptions)
>
> 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."

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. So, the actual functions are not known up 
front, and that fundamentally does not work with virtual 
functions, where the functions need to be known up front, and you 
get a different function by a look-up for occurring in the 
virtual function call table for the class. Templates and virtual 
functions simply don't mix. You're going to have to come up with 
a solution that does not try and mix templates and virtual 
functions."

Now, I realize I might have no been clear about things and maybe 
there is confusion/ambiguity in what I meant, how they 
interpreted it, or how I interpreted their response... but there 
is definitely no sense of "Yes, we can make this work in some 
way..." type of mentality.

e.g., "Templates and virtual functions simply don't mix."

That is an absolute statement. It isn't even qualified with "in 
D".

>> Does the gap need to be filled? Yes in this case, because all 
>> gaps ultimately need to be filled, but this then leads the 
>> practical issues:
>
> Actually, I disagree here. It only *needs* filling if enough 
> users of the language actually care about it not being there. 
> Otherwise, it's a *nice to have* (like generics and Go, or 
> memory safety and C :p ).

Yes, on some level you are right... but again, who's to judge? 
the current users or the future users? You have to take in to 
account the future users if you care about the future of D, 
because those will be the users of it and so the current users 
actually have only a certain percentage of weight. Also, who will 
be more informed about the capabilities and useful features of D? 
The current users or the future users? Surely when you first 
started using D, you were ignorant of many of the pro's and con's 
of D. Your future self(in regard to that time period when you 
first started using D) new a lot more about it? ie., you know 
more now than you did, and you will know more in the future than 
you do now. The great thing about knowledge it grows with time 
when watered. You stuck around with D, learned it each "day" and 
became more knowledgeable about it. At the time, there were 
people making decisions about the future of D features, and now 
you get to experience them and determine their usefulness 
PRECISELY because of those people in the past filling in the gaps.

EVERYTHING that D currently has it didn't have in the past. 
Hence, someone had to create it(Dip or no dip)... thank god they 
did, or D would just be a pimple on Walters brain.  But D can't 
progress any further unless the same principles are applied. Sure 
it is more bulky(complex) and sure not everything has to be 
implemented in the compiler to make progress... But the only way 
we can truly know what we should do is first to do things we 
think are correct(and don't do things we know are wrong).

So, when people say "this can't be done" and I know it damn well 
can, I will throw a little tantrum... maybe they will give me a 
cookie, who knows? Sure, I could be wrong... but I could also be 
right(just as much as they could be wrong or be right). This is 
why we talk about things, to combine our experiences and ideas to 
figure out how well something will work.  The main problem I see, 
in the D community, is that very little cooperation is done in 
those regards unless it's initiated by the core team(that isn't a 
bad thing in some sense but it isn't a good thing in another 
sense).

I guess some people just haven't learned the old proverb "Where 
there's a will, there's a way".

> [1] 
> https://dlang.org/spec/template.html#parameters_specialization

As I mentioned, and I'm unclear if it : behaves exactly that way 
or not, but : seems to do more than be inclusive. If it's current 
meaning can still work with virtual templated functions, then I 
think it would be even better.  But ultimately all this would 
have to be fleshed out properly before any real work could be 
done.