potential changes to breve 2.0

As I continue to work on breve 2.0, I've come across several
areas where I'd like to make large changes or improvements.
Because many of changes would existing features and
backwards-compatibility, I thought I would solicit feedback
on some of these ideas.

I've described some of the issues below.  I'd like to hear
what people think of these potential changes, as well as
feedback on other potential changes or improvements for
version 2.0.



Are arrays obsolete?
--------------------

Arrays in breve are now almost completely obsoleted by
lists.  Lists are far more flexible than arrays, and are now
indexed such that access is as fast as array access.  The only
advantage of arrays is that they require less memory than lists.

Do people still use arrays?  Does anybody object to removing
them?


A unified operator for "member access"?
---------------------------------------

Members of lists and hashes are currently accessed using
braces: list{0}.  What do people think of using the same syntax
for accessing members for all data types?

Current syntax for member access:

	list{0}.			# the 0th element in the list
	hash{"element"}.	# the value associated with "element"
	vector::x.		# the X-value of the vector

Proposed syntax additions:

	vector{0}.		# the X-value of the vector
	vector{x}.		# another way to access the X-value
	matrix{0}{0}.		# the matrix element at (0, 0)

And even potentially:

	instance{ var }.	# access the instance variable "var"


Patches and PatchGrids
----------------------

Many people have found patches to be a very useful feature.
Many people have also complained that past a certain point,
patches take up too much time and memory.  This is because
patches are currently represented as individual breve objects
and some simulations call for many thousands of patches to be
created.

An alternative to creating individual patch objects is to
provide fast, memory efficient hard-coded grid operations
at the cost of the flexibility.  This would mean that a
single Grid object would manage values for hundreds or
thousands of cells.  In addition, the cells would not be
able to hold arbitrary data, as they do now, but would
perhaps be restricted to holding only a small vector of
floating point numbers.

This will likely not replace "Patches", but will instead
be implemented as a separate version of the same thing.
What kinds of functionality would people expect from this
type of scheme?


New list operators
------------------

What new operators should be included for lists?




- jon klein

_______________________________________________
breve mailing list
[email protected]
http://www.spiderland.org/mailman/listinfo/breve