Lime Update 1

Tomorrow's my first day of school, so I'll probably have less development and YouTube time. However, I'll get a chance to do some more 3D printing and robotics.

I've been working on some development for Lime, my programming language. I've added a few new features:

Multi-Line if Statements

You can now write if statements with multiple conditionals and clauses. For example, the following code:

(define (print x)
        (if (equal (type x) 0) (iprint x)
            (if (equal (type x) 1) (map $print x)
                (if (equal (type x) 2) (sprint x)
                    (if (equal (type x) 3) (if x (sprint "true") (sprint "false"))
                        (if (equal (type x) 4) (fprint x)
                    (exception "print: unknown type.")))))))

could be refactored as:

(define (print x)
        (if (equal (type x) 0) (iprint x)
            (equal (type x) 1) (map $print x)
            (equal (type x) 2) (sprint x)
            (equal (type x) 3) (if x (sprint "true") (sprint "false"))
            (equal (type x) 4) (fprint x)
            (exception "print: unknown type.")))

Originally, I wanted to make case/elif statements that would be compiled to nested if statements with macros, but purely functional macros don't exactly have the functionality you need to do that.

Floating Point Operations

For some strange reason, floating point numbers don't work properly in Lime. x87's FPU instruction set is a million times more complicated than x86 already is. The operation

(print (/ 3.0 2.0))                                                                                           

returns the value


while integer operations like

(print (+ 3.0 2.0))



Because Lime objects must be passed around on an integer stack, they're stored in 4 32 bit integers:

4   # the first number, 4, indicator of the number of integers required to store the float
4   # 4, the type ID of floating point numbers
667 # the main integer
1   # number of times to divide by 10
0   # 0 if the number is postive, 1 if it's negative

thus, extensive rounding occurs, truncating a lot of decimal places. I'm not sure if inaccuracy this high could be a result of floating point error propogation or if there's an error in my code.