Type value

[js.mdnq]

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)