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.
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.
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.
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)
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. 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).
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).
This is all programming is. We define certain symbols to mean
certain bit patterns, or generic bit matters(an if keyword/symbol
is a generic bit pattern, a set of machine instructions(0's and
1's) and substitution placeholders that are eventually filled
with 0's and 1's).
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. 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)
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: Is the gap "large", how much work will it take
to fill the gap? Will feeling that gap have utility? etc. These
practical questions can only be dealt with once the theoretical
can of "is it possible" is dealt with. I have shown it is
possible(well, Jonathan gave a proof of concept first, I just
implemented an automation for it).
I think, at least several of us, should now be convinced that it
is theoretically possible since several ways have been shown to
be fruitful. We are now at where you have said you are not
convinced if a new simpler syntax is warranted. The only real way
to know is to implement that syntax experimentally, use it, then
compare with the other methods and compare. But of course this is
real work that most people are not willing to invest and so they
approximate, as you have, an answer.
I do not know, as you don't. We have our guesses derived from our
experiences and our extrapolations. I can say, that in my case,
it would only simplify my code by a few lines(and, of course,
remove a library dependency, which I do not like anyways). What
it mainly does is reduce kludges and being I'm the type of person
that does not like kludges, makes me "happier". If you are ok
with kludges, then it won't effect you as much.
The only thing I can say are theoretical assertions and it is up
for you to decide if they are worth your time to implement
them(assuming you were the person).
1. Library solutions are always less desirable in the theoretical
world. Ideally we would want a compiler that does everything and
does it perfectly. Such an ideal may not be possible, but
obviously compiler and language designers feel there is some
amorphous ideal and history shows compilers tend to move towards
that ideal. Libraries create dependencies on external code which
have versioning issues, upkeep, etc. They are a middle ground
solution between the practical and theoretical. But they are not
something that should be "striven" for. Else, again, we should
just write in binary and have everything implemented as a library
solution. (which, once we do, we will realize we have a compiler)
Library solutions also add complexity to the code itself. It is a
trade off of compiler complexity vs user code complexity. The D
community seems to love to push the complexity on the user. I
feel this is partly do to those that deal with the compiler not
really being coders(in the common sense of writing practical
business applications for making $$$). For example, What has
Walter actually coded as far as "practical stuff"? A video game?
Did he even use D? This is not a jab at him, but my guess is that
he is more of a mathematician rather than an engineer. You can't
really do both and be great at them because there is only so much
time in the day... even though they overlap greatly. When you get
in to writing massive real world applications that span hundreds
of developers, I'd bet D starts to fail miserably... of course,
unless you are writing the next clone of pac man or some ad
software. It's not that it can't be done, or that it can't be
done well, but D starts showing it's weakness the more difficult
the problem becomes(and it's strengths). You can write a simple
command line utility in just about any language... it's not a
test of the languages strengths and weaknesses.
2. Given the nature of the topic, which is virtual templated
functions, which is a parallel of virtual functions, it seems IMO
that it is more of a core concept that fits nicely with the other
pieces. Those pieces are not implemented as a library
solution(they could be, but then we are back to 1). Hence, it is
not too much of a leap to think that adding this feature as a
compiler solution is warranted. Since these are a simple
extension of a compiler solution, it seems natural that the
compiler should deal with it. If it were a library solution then
it would be natural to extend the library... not mix and match,
which is what is generally being suggested.
Now, it's true that the suggested solutions are relatively
straight forward. So, the issue is somewhat moot now. It wasn't,
at least for me, when I asked... and given that several people
quickly denied that such a solution(any) existed, is what made
this thread much longer than it needed to be. I'd prefer a
compiler solution... that is my opinion. Do what you will with
it. It means nothing at the end of the day. If I had my own
compiler I would have already implemented it in the compiler. If
my compiler was so fragile that I could not add such a simple
rewrite rule(which should be very simple extensions that
introduce minimum complexity to the language or compiler), I'd
either rewrite the compiler(fix it like it should) or move one to
greener fields. Also keep in mind that what is complex to one
person is not necessarily so to another. I just don't like to be
*told*(not proven) that something is impossible when I very well
know it is... it's really not about "liking" but the fact that
those same people go and perpetuate their ignorance on other
people. I can deal with it because I know better, but many people
fall victim to such ignorance and it's one of the reasons why the
world has so many problems as it does.
