On Tue, 2007-05-01 at 23:31 -0400, Chris King wrote: > This is more or less what I'm thinking... operations such as > exponentiation that require polar coords will always return a > pcomplex, whereas operations such as addition will always return a > ccomplex, thus moving a lot of the burden into the typesystem. A > problem arises though when considering operations such as > multiplication and division which are efficient in either > representation, but *sometimes* require that the result be represented > in polar coords (as in one of my examples). Aside from complex (and > probably undecidable) data-flow analysis the only immediate solution > that comes to mind is to fall back to returning a union type in this > case, so we wouldn't be able to totally eliminate the runtime checks.
Full scale data flow analysis isn't impossible but probably premature: there are still some semantics issues to figure out. However patten matching plus some localised analysis is already done, so it is and should give good results for functional code: the problem is how to do this without hacking the compiler to support type specific optimisations. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
