Re: potential changes to breve 2.0

Jon,

I'd vote for keeping patches as-is for backward compatibility, which it 
looks like you plan to do anyway.

Is there some reasonable middle ground on backward compatibility for 
other items, for example a "use-old-vector-access" declaration that 
could be added to the top of a file to allow old simulations to 
continue to run without extensive changes?

For list operations I'd look at the Scheme spec (or the Push2 spec, for 
which I went through a similar exercise but then added more than you 
probably want).

  -Lee


On Jun 22, 2004, at 11:09 AM, jon klein wrote:

> 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
>
>
--
Lee Spector
Dean, Cognitive Science + Associate Professor, Computer Science
Cognitive Science, Hampshire College, Amherst, MA 01002
[email protected], http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438

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