[Grace-core] Minutes of Teleconference 2013-07-24

[Andrew P Black]

On 30 Jul 2013, at 10:25, James Noble wrote:

>> They are three different things, so shouldn't they have three different methods? 
> 
> I guess that's the question, isn't it?   This is why API design is hard and how language design interacts with API design.   

API design for experts and API design for novices have different goals.  For novices, offering guidance and catching mistakes is the most important, I think.  For experts, it may be "power" and universality.
> 
>> repeat(n)times(zeroaryblock)
>> for(vals)do(unaryBlock)
>> withValIndex(vals)do(binaryBlock)


Why not:

	theCollection.do { each -> stuff }

	theArray.doWithIndex { each, ix -> stuff }

	4.timesRepeat { stuff }

What's the value of adding dialect-level methods so that 

	repeat (n) times { stuff } 
and
	for (theArray) doWithIndex { each, ix -> stuff }

gets turned into 

	n.timesRepeat {stuff}
and
	theArray.doWithIndex { each, ix -> stuff }  ?

It's just one more level of syntax to explain—students will need to learn to read the collection APIs themselves.   Will this syntax help when the student transfers to a language with C-like syntax for for loops?  Not one whit.

Most valuable to the learner is systematic naming within our own APIs.   Which means that we can't just carry stuff over from some other language: we have to de-design.

The "iter" objects that Michael put in the libraries are useful when one needs multiple streams, coming from multiple collections (as, for example, when implementing a merge).   They are overkill for implementing do, which can be done with a single method.  In contrast, thinking about error checking, putting some "fail fast" logic into iterators, as does Java, to detect modification of the underlying collection, might be really valuable for novices.

	Andrew




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20130730/b46c09d3/attachment-0001.html>