OQ3 has no imaginary type, only complex type (I don't know of any general purpose language that differs in this respect). But it is convenient to implement and use imaginary literals in order to handle expressions like 10 im, 10im, 12.3 im, 12.3im, etc.
We already have implemented all the machinery for timing literals. Lexing and maniuplating imaginary literal is structurally identical, so we can use the machinery for timing literals at (almost) no extra cost in coding or complexity. A disadvantage is that imaginary and timing literals don't belong in the same category. IDK, we could rename everything to `timing_or_imaginary.
An imaginary float literal can be stored and manipulated in exactly the same way, with the same semantics as a real float literal. The exception is the last step of specifying the type. For this reason we break with the precedent of all other variants of enums in asg.rs by reusing a the struct field for real literals. That is, we have:
OQ3 has no imaginary type, only complex type (I don't know of any general purpose language that differs in this respect). But it is convenient to implement and use imaginary literals in order to handle expressions like
10 im,10im,12.3 im,12.3im, etc.We already have implemented all the machinery for timing literals. Lexing and maniuplating imaginary literal is structurally identical, so we can use the machinery for timing literals at (almost) no extra cost in coding or complexity. A disadvantage is that imaginary and timing literals don't belong in the same category. IDK, we could rename everything to `timing_or_imaginary.
An imaginary float literal can be stored and manipulated in exactly the same way, with the same semantics as a real float literal. The exception is the last step of specifying the type. For this reason we break with the precedent of all other variants of enums in asg.rs by reusing a the struct field for real literals. That is, we have:
The type (float or complex float) is stored at a higher level as it is for all expressions.
Closes #190