On Monday, 10 December 2012 at 19:54:51 UTC, Zhenya wrote:
Hi!
In some previous post I asked about possibility of declar
opIndex,that return type.
I thoght about it,and I understood that code like this is legal:
struct Type(T)
{
alias T m_type;
alias m_type this;
}
void main()
{
Type!int Int;
// Int a;
}
Is it hard to implement possibility of using Int as a type?
It would allow functions,that return types:)
Type's are compile time concepts that are only used to partition
data into logical units. Computer memory is just a bunch of 0's
and 1's and have no logical interpretation.
By creating a type you are taking a group of bits and telling the
compiler(a static construct) how you want to interpret them. You
do not tell the cpu this as it does not have any idea of
types(well, except for basic things like ptr's, bytes, words,
etc...).
So, when you say "return a type" it means nothing because a type
is not addressable. How would you return an int as a type? (not a
group of bits but an actual int type specification)
To help bridge the gap between compile time static type
constructs and a rather typeless run-time system modern languages
seem to create a type that wraps Type information into an actual
object which then you can pass around like "normal" objects.
Remember, compilers simply make it easier to program in binary,
but ultimately that is all we are doing. To make things more
logical we use higher level types, the cpu does not understand
arbitrary types(but we use the types it does understand as basic
building blocks). In some sense, it doesn't even "understand"
types at all... it just has some instructions that make dealing
with different length of binary numbers easier/more efficient.
As far as I know, D does allow you to wrap compile time type info
into an object to be used at run-time for various things(but it
will exist as an addressable object).
for example, you can't really do something like this
type return_type(int x) { if x == 1 return int; return fruitType;
}
c = readkey();
return_type(c) y;
// How do we use y? we don't even know what type it is at this
point! We are going to have to assume it is one or the other and
code for both! But then we essentially just have the same as the
following
alternatively:
c = readkey();
if c == 1 { int y; do whatever; } else { fruitType y; do
whatever; }
because y is not known at compile time(it is not a static
construct). y, essentially is a polymorphic type but is too
arbitrary to be useful. Remember, the compiler ultimately has to
make an address and a set of bits for y in computer member for
the cpu to be able to understand it. How, though, can it do this
for y if the "type" is not known at compile time?
The 2nd case is completely defined at compile time. The first is
not and essentially is "open ended"(the compiler can't figure out
all the possibilities that y can be, while in the second case it
is fixed).
So, you can't pass types around in a run-time fashion. D is nice
in that it allows you do easily do this sort of stuff at compile
time. You can pass around type info objects dynamically and even
create types from such objects at run-time. Doing so, though,
requires a more difficult approach because, ultimately, the
compiler still has to be told everything that is being done(it
can't guess) and it still has to translate the program into 0's
and 1's.
The variant type is a way to sort of get around the problem for
some cases as it allows a type to be polymorphic to a degree(but
not arbitrarily).
If cpu's stored data in logical units then such a system would be
much easier to do. Instead of storing bytes one would store
"records" which would contain a type field which would tell the
cpu information about it(which you have to setup). Unfortunately
this would bloat the code tremendously(every int would have to
have a type field). It would be sort of the same though as modern
compilers and their typing systems but would be more transparent.
(probably equivalent of just implementing the compiler on the cpu)
