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

[Carl Worth]

On Jul 29, Keith Packard wrote:
 > I've removed the 'else' clause from 'twixt' ...
 >
 > I've also added the expression-level statement, ...
 > 
 > The varactual patch is also done and nicely symmetrical with the
 > varargs syntax...
 > 
 > Now compose works like it's supposed to...

which means you also added the reflexive func_args builtin.

Wow, you've been busy Keith! Thanks for all the fun features.

Looking at the split function you wrote for compose. Do we want some
builtin support for array manipulation? It could be a function similar
to your split, (although I'd vote for "slice"). Or the array index
could accept an array of values. That, along with some support for
easily constructing arrays of integers could be quite handy.

So, given:

	int[*] a = {1, 2, 4, 8, 16, 32, 64, 128};
	int[*] b;

Some options for slicing out elements 2 through 6 could be, (sorted in
order of increasing language support required):

(A)	b = slice(a, 2, 6);	/* New builtin slice */

(B)	b = a[seq(2, 6)];	/* New indexing by array */

(C)	b = a[2 .. 6];		/* (B) plus array construction operator */

I have no idea if adding a ".." operator for integer array
construction would be a good idea or not in terms of precedence or
other concerns. Actually, it's probably not a good choice given the
new use of "..." in varactual support. I suppose `:' might be another
choice for the operator's name, (no, that would definitely interfere
with "? :").

I think I'd prefer option (B). It doesn't require too much new
language support, and it's quite flexible. For example, one might want
to extract every even-indexed element from 2 to 6:

	b = a[seq(2, 2, 6)];

What think ye? Other ideas?

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                 cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203		  703-812-3725