Numerics in Radian
Posted: December 29th, 2009 | Author: Aaron Ballman | Filed under: Design | Comments OffInitially, Radian handled numbers as basic integers only. The way floating-point support was implemented was by using the dot operator as a function which would take two integers (the left-hand side and the right-hand side) and return a floating-point value. However, this also meant that it was basically impossible for us to write any backend support for special processing of numerics. Also, it meant that it was possible to write some funky things, like:
var wahoo = 12
var blah = 1.wahoo
if blah = 1.12 then
end if
In theory, that would work fine because the dot operator function would concatenate 1 and wahoo (12) together.
Now Radian has lexical support for more numeric formats than just integers. The support is highly based off of Python, so those of you coming from that language should feel right at home. We now support integers, floating-point values, hexadecimal, octal and binary literals. All of the various literal formats are still considered to be a “number” internally, and there basically is no support for coercion aside from what the backend does via C. Eventually, we’d like to see a numeric tower like Scheme, where each numeric format builds on top of a lower abstraction. However, that project will wait for another day.
Currently, the syntax for numeric literals is:
Integers: [1-9][0-9]* | 0
Floats: [0-9]+.[0-9]+
Hexadecimal: 0[Xx][0-9A-Fa-f]+
Octal: 0[Oo][0-7]+
Binary: 0[Bb][0-1]+
You’ll notice that there is not support for scientific notation with floats, which will likely change in the future. Also, I’m not supporting sign information as part of the numeric literal. When you apply a sign, we treat it as an operator currently. I’m not too keen on that right now because I think it will make constant folding a bit more difficult. Also, I’m still on the fence as to whether I want to support a unary + as well as a unary – in the same way that Python (and JavaScript, etc) does. I can’t think of reasonable use cases that aren’t contrived or too clever.