[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