[Grace-core] SETL question

[Andrew P Black]

On 1 Apr 2013, at 03:38 , James Noble wrote:

> although I'm not at all sure "all()suchThat()" and "no()suchThat()" are consistent with regards to return type - "all" probably should be renamed back to "collect" or something. 
> 
> this is another case where Grace using only blocks, not macros, means we write
> 
> all (2..10) collect {x -> x * x}
> 
> rather than the more lisp-ish (or Wirth-ish, or "natural")
> 
> all x : (2..10) collect {x *x} 

This post highlights the fact that we need to do some serious library design, and that we probably all have different ideas on how things should look.

Note that SETL is a DSL for set manipulation, and Lisp is a DSL for list manipulation, so I would expect that set programs might be shorter n SETL and list programs shorter in LISP.

Grace is an OO language.  So we should rejoice in using OO notation and idioms.

It may have been a mistake to use . for method request, but we did it.   So we should be HAPPY to write

	(2..10).collect{x -> x ^ 2}.into(aSet) or
	(2..10).collect{x -> x ^ 2}

(depending on whether collect answers a stream or a collection) rather than trying to create a different top-level method name for every operation on every different kind of object.

As for naming, it seems to me that allSatisfy{aPredicate} should answer a boolean, while collectAllSatisfying{aPredicate} should answer a stream (or collection).   Contrarily, noneSatisfy{aPredicate} should also answer a boolean.    These enumeration messages should work on streams (lazy collections) as well as eager collections.

But the meta-quesiton is: what's the design process?

	Andrew