[Grace-core] Collections suggestion

[Andrew P. Black]

On 29 Jul 2014, at 14:28, Kim Bruce <kim at cs.pomona.edu> wrote:

> The structure dialect does now compile properly on both Safari and Firefox on my Mac.  I guess I'll have to investigate the best way to get them to clear old code when the compiler has been updated.  It doesn't seem to be a problem with student written code, as far as I can tell.

No, I think that it is only a problem with code fetched from the server.

>> On 29 Jul 2014, at 02:42 , Kim Bruce <kim at cs.pomona.edu> wrote:
>> 
>>> I have a suggestion for a minor change in the semantics of the method at()put() (and []:=) in list.
>>> 
>>> Currently if you write myList.at(k)put(x) then it requires 1 <= k <= myList.size.  I would like it to work for 1 <= k <= myList.size+1
>>> 
>>> That is, I'd like to be able to extend the size of a list by one if the subscript is one greater than the current last index.  Doing this would make some code that involves adding new elements into a list easier in that a simple loop can shift all elements to the right over by one.  Java ArrayLists, for example, have this behavior.
>> 
>> This seems reasonable.  I'll put it in.
> 
> Thanks!

It’s in.  Note, however, that this extension does not (yet) work with list[x] := v.  Should it?   Somehow, having at()put() extend the list seems less bad than having []:= do it!

>> 
>> I've been testing an extended version of collections, which support Sequences (which, if you recall, are what we agreed to call immutable lists), and also more conversion operations (aList.asSet, aSequence.asList, etc).   These are passing all the tests that I've written, but there is as yet no automated way of testing coverage; that's on my list of things to do.
> 
> Those sound good.
>> 
>> I've also allowed for conversion from a list and a sequence to a dictionary, in which the keys will be the indices of the list.  More controversially,  I'm also supporting conversion of sets to sequences and lists — I say controversially, since the order will be arbitrary.  But that conversion will be supported in any case through iteration: aSet.iterator.onto(list).   Sets to dictionaries seems less useful, though.
> 
> Converting to dictionary should be fine, though I'm not sure how helpful it would be to have indices as keys, though perhaps there would be useful dictionary operations that might make it more useful.
> 
> As you note, sets to list will be accessible via iterators anyway.  I'm not sure that I'd like to highlight those conversions (of course we would find examples like s1 == s2, but list(s1) != list(s2)) by making them so easy, but I can live with it.

As a programmer, I really like rich libraries that make common things easy — do()separatedBy() is a great example.  But as a teacher, I can see that this might be a disadvantage, because the introductory assignments might become trivial.   You are not having this problem because your assignments are graphical, and I haven’t been enriching those libraries!

>> I've been thinking about sorting, and have concluded that what makes most sense would be to implement sort on PrimitiveArray (using the underlying Javascript or C sort), and then implement sort on lists &c using the sort on PrimitiveArray.
> 
> Makes sense.  Which would you put into the language?  I could see a justification to do a single sort (hybrid quicksort/insertion) or have several different ones that highlight different big-O performance -- perhaps one O(n^2) and one O(n log n)?
>> 
>> Your thoughts on any on the above are welcome.

I wouldn’t put any into the _language_.  There would be a list.sort(comparisonBlock) in the list object.  Students could still write their own sorts (like Quicksort, and merge sort), but list.sort would be a magic “built-in-sort” that would be a lot faster, I hope, than any Grace code could ever be, because chunks would be “native”.  

> Thanks for all of your hard work on this.  I really appreciate it.  (Could you let me know when you change at()put()?  I have code for the text that i want to try out.)

It should be working now.  Check that the browser says "minigrace-js v0.0.9.1997 / fda1808” after the Visibility pull-down.   I don’t know what the v0.0.9.1997 means, but the fda1808 is the git hash for the commit that the browser is running.

$ git log | head -20
commit fda180857cfbe794cf5b4190f62470c38dba523a
Author: Andrew P. Black <black at cs.pdx.edu>
Date:   Tue Jul 29 18:10:23 2014 -0700

    Added more methods to collections.
    
    Included sequence methods and conversion methods.
    Explanded the applicability of list.at(ix)put(v) to
    case where ix = list.size + 1 (which was formerly a bounds
    error.
    Exported types in StandardPrelude, and corrected name to sequence.

commit 9b4322d7eb7bd23d2b8129995e99e482ab95137c
Author: Andrew P. Black <black at cs.pdx.edu>
Date:   Tue Jul 29 18:08:07 2014 -0700

    Web dependencies added to Makefile.
...


	Andrew