[Grace-core] Library Structures

[Michael Homer]

On Tue, May 27, 2014 at 5:52 AM, Kim Bruce <kim at cs.pomona.edu> wrote:
> 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.
"Where ListFile is an opaque string interpreted in an
implementation-defined manner, which may map onto a file path in some
way".
> If we were to be able to generalize this then we could actually include several modules in a file (if we wanted)
So I think what you're thinking of here is just "an object"...
> 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
I'm not sure how these logical names would work, but it seems that you
want to have more than one module with the same undistinguished name,
which somewhat reduces its utility as a way of talking about a module.
> without having to change file names.
You don't have to change file names now, as far as I can tell.

Of course, you can have all the logical names you want just by
imagining them into existence. Or "ListFile" is a perfectly good name,
and you got to choose it.
>  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.
Can you sketch a design for that? Where do they come from?
> 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!
You can always alias an object. You can never alias a method.
-Michael