[Grace-core] Library Structures

[Andrew P Black]

I like the fact that the module object is anonymous unless you give it a name in order to use it.  It's a nice integration of "main programs" and "modules".

The alternative would seem to be to copy Java and to require the name of the module be inside the file as well as the name of the file, just so that it can generate an annoying error message: "module foo" must be in a file named "foo".  

If and when we get a nice IDE that is not file based, the name of the module would be something set by the IDE, and the string in the imports statement would be interpreted in the context of this IDE.  The interpretation of imports statements too seems like a nice separation between language and environment.

The idea that every file is implicitly wrapped in object { ... } currently stops one from putting more than one module in a file.  This is a good thing.  We could turn this off with a pragma ... but why would we want to?

	Andrew 


On 26 May 2014, at 15:46 , Kim Bruce <kim at cs.pomona.edu> wrote:

>>> 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".
> I understand that is minigrace only.  Actually the main point of the email (which I might not have made clear) was to have an internal identifier for the name of the module, where this internal name could be used for importing files.  Admittedly, names could be provided by just adding a comment to the header of each file that lists the file name.  However I was hoping for something that was actually part of the syntax and that could be used in an import statement.  Perhaps something like (and I'm just thinking out loud, throwing out ideas), the following for the module header:
> 
>   module listlibrary
> 
> and then using it in another library by writing one of:
>    import listlibrary
> or
>   import listlibrary as newName  // if there was a name conflict
> 
> The main motivation here is pedagogical.  I have no serious problem with the functionality, I just want to have a name for all the pieces of a program that is not just a file name when I am talking about them in the text.
> 
>>> 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"…
> Yeah, only difference is how many prefixes are needed get access.  I was trying not to equate modules with files, but it may be easiest to do that in practice.
> 
>>> 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.
> Yeah might be better to just fix it in the import statement.
> 
>>> 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?
> There are programming in the large languages that attach logical names to files where code is found.  I believe this is part of what "platform" does in Newspeak. It serves as a guide as to where to find the physical files associated with module names.
> 
> On the other hand, I believe we did consider and reject that design early on.
> 
> Let me just back up to the claim that it would be useful to have an internal name for each module so we could more easily talk about them when we are describing them in a paper or textbook.
> 
>>> 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.
> 
> Yes, the (slight) surprise was that the prefix of the class was indeed recognized as an object.  Of course, that is the way we did the design, but I wasn't sure the implementation would recognize the surface syntax in that way.  I'm very glad it does.  I presume if classes were interpreted as methods then we would need to write something like:  
>   method aFunnyFaceAt(locn) on (canvas) -> Draggable {fc.aFunnyFaceAt(locn) on (canvas)}
> to get the alias.
>> -Michael
> 
> 
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core

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