On 2010-12-16, at 10:00 PM, Maxime Chevalier-Boisvert wrote:
There are 38 uses of Infinity in the code and 1 use of NaN... these
must be removed!
In my code at least, I used infinity to say that there is no specified upper bound on something. One thing we can do, for now, is cheat. It seems that at least in V8, Infinity is a global variable. Possibly we could just do something like "const Infinity = {};", just for the bootstrap. We could do the same for NaN.
That won't work if numbers are compared using <, etc (to find a min/max or as a sentinel). Perhaps we can say
const Infinity = 99999999;
for the bootstrap and it will work. On the other hand perhaps the algorithms could be rewritten in a better style. It is rare to see a compiler use floats for internal operations. I fear that if we keep this style of code, integers and floats will get mixed, which will deteriorate the type analysis (i.e. value(foo) in union(Float,Int)), and inefficient code will be generated.
It happens so often that it would be abstracted: typeString(name,
"name");
Right now, assert is a function defined in debug.js. The plan is to eventually make it a special name that Tachyon will recognize, so that assertions are weeded out from our code when we aren't debugging. This is perhaps slightly more complicated if we start to have many functions whose purpose is only to perform an internal assertion. As you said, this would be better served by macros. For now, I would suggest keeping all assertions the way they are. I defined some helper functions in utility, such as isPosInt, to test for the common case that a value is a positive integer, so you can do "assert (isPosInt(x), ...);".
If you still think we should add extra functions that call assert, I would suggest using the "tachyon:inline" prologue annotation inside of them, so that when the internal assert gets weeded out, so does the whole call to the function doing the assertion. I would also suggest naming them in the form "assertSomething(...)", so in this case, "assertString(x, name)".
assertString(x, name) would be fine.
Marc