daokoder / dao

Dao Programming Language
http://daoscript.org
Other
198 stars 19 forks source link

Question: Does specialization of none|@T works as intended? #509

Open dumblob opened 9 years ago

dumblob commented 9 years ago
0$ dao -e 'routine return_some_complicated_non_none_type() { 1 }; x: none|@T = none; x = return_some_complicated_non_none_type(); if (x == none) io.writeln("A", x) else io.writeln("B", x)'
[[ERROR]] in file "command line codes":
  At line 0 : Invalid function definition --- " __main__() ";
  At line 1 : Invalid virtual machine instruction --- " MOVE:3,1,1 ";
In code snippet:
      3 :  CALL        :     2 , 32768 ,     3 ;     1;   return_un...()
>>    4 :  MOVE        :     3 ,     1 ,     1 ;     1;   x = return_un...
      5 :  GETCG       :     0 ,     1 ,     4 ;     1;   none
  At line 1 : Invalid operation on the type --- " x = return_unknow... ";
  At line 1 : Types not matching --- " 'int' for 'none' ";

After changing @T to any, it starts working fine.

Night-walker commented 9 years ago

@T is meant to be a placeholder for type; declaring a variable with @T in its type makes no sense for me, I don't think it should be allowed unless there is some actual @T in this context resolved to a known type.

dumblob commented 9 years ago

unless there is some actual @T in this context resolved to a known type.

Exactly - it's known at compile time, but not at the place of declaration. I thought, that the resulting type is derived from the first non-none occurence of assignment in the subsequent use of the none|@T variable. In other words, @T placeholder would serve as a temporary type being filled in later (this should be pretty much the general semantics of type holders in Dao if I'm not mistaken).

daokoder commented 9 years ago

@T is meant to be a placeholder for type; declaring a variable with @T in its type makes no sense for me, I don't think it should be allowed unless there is some actual @T in this context resolved to a known type.

For x: none|@T = none, the expression in the right side of the assignment actually provides a context to resolve the type holder. But in this case, the type holder cannot be resolved, because here none will match to none, ignoring the type holder.

daokoder commented 9 years ago

Exactly - it's known at compile time, but not at the place of declaration. I thought, that the resulting type is derived from the first non-none occurence of assignment in the subsequent use of the none|@T variable. In other words, @T placeholder would serve as a temporary type being filled in later (this should be pretty much the general semantics of type holders in Dao if I'm not mistaken).

It has to be known at the place of declaration.

daokoder commented 9 years ago

Fixed. Now x is left as unspecialized type none|@T, which allows the second assignment to succeed.

dumblob commented 9 years ago

It has to be known at the place of declaration.

And that's quite inconvenient - none is the best fit for a "special value" in case one can't or doesn't want to use some "stop" value.

Fixed. Now x is left as unspecialized type none|@T, which allows the second assignment to succeed.

Great. This was just my assumption not based on thorough thinking.

By the way, I was already several times thinking about some way how to "extract" type information from a function or variable and use this type as any other manually written type. E.g. something like x: none|@<T=return_some_complicated_non_none_type> = none. This should make things clear, concise and allow easy manipulation without the need of having the not-so-obvious "second assingment rule".