[Grace-core] Library Structures

[Kim Bruce]

I'm not sure I completely understand the issues here, but I do find that T is usually used as a type variable, so would prefer to see aList.List<e> or aList.List<T>.  I presume you left off the type variable because you are thinking of the dynamically typed version.

This brings up an issue I've been facing when working on the book.  I am starting to talk about having classes defined in separate files (in order to reuse them in different places).  I find that I am missing having an internal name to talk about them.  That is, I would like for each file to have an internal name like:
  module lists
Right now our library system is totally tied to files and file names as we have to write something like
 import "ListFile" as list
where ListFile.grace is the name of the file.

If we were to be able to generalize this then we could actually include several modules in a file (if we wanted) or just have a single one per file.  Having a module name would allow us to have a logical name for libraries as opposed to a hard wired one.  This both makes it easier to talk about modules and allows us the flexibility to have several modules with the same name that could be swapped in and out of a system without having to change file names.  Of course this means we would have to redo how the implementation keeps track of and imports modules, but I suspect it wouldn't be that hard to design such a system, but it would require some work on the implementation.

Of course each module would continue to be imported as an object.  If we wanted (though I don't think this is necessary), we could even have modules that are parameterized by type parameters.  [I suspect this isn't necessary, because we can use type parameters on everything inside the module, but it might be desirable in some circumstances]

By the way, I was pleased to see that the current implementation allows me to define a type Draggable and a class aFunnyFace in a file "FaceClass.grace"  as follows:
 type Draggable = {…}
 class aFunnyFace.at(locn:Location)on(canvas:Canvas) -> Draggable {…}

(note I am using old class syntax), and then define a program using them with the following code:

import "FaceClass" as fc

type Draggable = fc.Draggable
def aFunnyFace = fc.aFunnyFace

and then be able to write
 aFunnyFace.at(someLocn)on(canvas)
in that program.

I'm not surprised that we can use Draggable, but I was pleasantly surprised that we could grab aFunnyFace
and rename it without somehow including ".at()on()".  Nice job!

This makes libraries much easier to use.

Kim

P.S.  My laptop had a disk failure (and perhaps worse) on Friday.  I restored another computer with all my files and then had that fail as well, so am now on a third computer.  I am unlikely to be able to get to or update anything in the repository for a while (not worth the time).  I'm hoping I get my computer back and everything restored before leaving for Portland on Sunday, but …

On May 23, 2014, at 4:59 AM, Andrew P Black wrote:

> As I mentioned on the teleconference yesterday, I've just committed a revision of the collections library, that contains objects that implement lists, sets, dictionaries, ranges and iterators (streams of values).  There are also a fair number (120) of tests.  
> 
> I'm quite pleased with the structure of map, fold and filter, which operate on iterators as well as on "concrete" collections, and the way that iterators can be reified as concrete collections.
> 
> Right now the files are in the gUnit project, because I don't know how to put it in a separate directory and still import gUnit.  Probably all of this code should be moved to the same tree as minigrace, and then there would not be a problem.   Is there any documentation on the changes to import that took place over the NZ summer?
> 
> I'm considering splitting the collection module into separate list, range, set, etc modules.   So one would be able to just
> 
> 	import "list" as aList
> 
> 	def attendees = aList.with("Andrew", "James", "Oscar")
> 
> If I do that, I imagine that we will still want a consolidated collection module, that imports and re-exports the individual kinds of collection.
> 
> 	import "collections" as coll
> 
> 	def attendees = coll.aList.with("Andrew", "James", "Oscar")
> 	def aSet = coll.aSet
> 	def diceThrows = aSet.with(3, 4, 3, 6, 2, 3, 4)
> 
> My question is: what should I call the types?  Should we do something like Modula-3 and write
> (in the module list)  
> 
> 	type T<e> = type {first -> e, addAll(_:Collection<e>) -> T<e> ... }
> 
> so that clients can refer to it as aList.T  Or should be say 
> 
> 	type TListe> = type {first -> e, addAll(_:Collection<e>) -> T<e> ... }
> 
> so that clients can refer to it as aList.List?
> 
> 	Andrew
> 
> 
> 
> 
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core