[Nickle]Boolean type, twixt, static vs global, built-in profiling

Keith Packard nickle@nickle.org
Mon, 29 Jul 2002 19:43:47 -0700


Around 12 o'clock on Jul 29, Bart Massey wrote:

> No, this really *isn't* what I wanted to write: see above
> :-).  I really intend the twixt() to be *good* syntax for
> things like opening and closing files, creating and removing
> temp files, locking and unlocking mutexes, etc.

I've removed the 'else' clause from 'twixt' and made the 'enter' 
expression not conditional anymore.  The results inside the interpreter 
are quite salutory, cleaning up quite the mess generated by the 
handling the conditional.  Now twixt is nice and symmetrical.

I've also added the expression-level statement, as expected it took about 
2 minutes -- a new production in the grammar and a two line addition to 
the compiler.  These are *always* void at this point, making them able to 
return a value would be a bit tricky, and would somewhat overload the 
'return' statement.  I suggest that if these statement expressions want to 
return a value, a nice lambda would do the trick.

The varactual patch is also done and nicely symmetrical with the varargs 
syntax:

    poly (poly...) compose (poly f, poly g) {
        poly[*] split((*poly[*]) a, int start, int len) {
            poly[*] p = [len]{};
            for (int i = 0; i < len; i++)
                p[i] = a*[i+start];
            return p;
        }

        poly composite(poly args...) {
            return f (g (split (&args, 0, func_args (g))...),
                      split (&args, func_args (g), func_args (f)-1)...);
        }
        return composite;
    }

Now compose works like it's supposed to.  Note that you do get some 
typechecking with this; the requirement is that the type of the array 
element in the actual matches the type of each formal it will be assigned 
to.

-keith