[Grace-core] More thoughts on modules

[James Noble]

> 
> Yes, as long as the types are compatible (structurally or otherwise).  They could easily be imported from one or more modules and used interchangeably if the resulting objects have the same type.

I guess the questions are 
 - are modules parametric in the modules from which the interchangeable types are implemented?
 -  if so how do you specify that parameterisation?
 - how does this differ from classes, objects, generics etc.

> The intention is that the definition modules would be early bound (compile time), but the implementation modules would be late bound (e.g., at link time).  I see modules as static, so don't see the need to bind at run time, 

OK - so very different to classes / objects then? 

> but am happy to listen to arguments in favor of that.

I guess the arguments are Scandanavian; Orwellian :-); or Millerian...

> Yup.  I like it this way, as it makes it easier to late-bind these without changing any existing code.  However, it could be done the other way.

having that sort of binding is good.  
Having no global scope seems good too - even if we don't go all the way to the object-capability or Newspeak models.

> I think this is where the multiple interfaces for an implementation module in my presentation kick in.  Depending on what privileges you want for that object, you would import and/or use one or the other interface module for the same implementation.  I can't tell if your scenario provides more flexibility than the one I outlined.

Right. so this is a fundamentally different model than the E-Newspeak-Anbienttalk-object//capability model,
where you'd hand out a proxy *object* with a restricted interface, rather than hand out the real object
with access to some of the features prevented by the module system. 

Again, one catch with this model is that if interface restrictions are not enforced agains
type Dynamic (and presumably pattern matching again structural types too) then the
language breaks the module system.  This would require some way of calculating
a "perspective" from any lexical scope to an object, refracted by the permitted "views"
of the object in that scope, then dynamic lookups or pattern matches match against
only the permitted views.   Do we know anything that does this (except I guess the OO
encapsulation paper of Andrew & co?)   Is this what we want? 

> I'm not sure they don't provide something close to what you outline, though probably in a slightly less expressive/flexible way.

well it's up to us to decide
 - what problems we want modules to solve
 - how they solve 'em

for me, its composing whole programs out of various bits that seems the most important, 
name management very much related to that.
Also support separate typechecking / compliation, being units of deployment
(we can just give out source code - works for JavaScript :-)

encapsulation also seems important, but I'm not sure how that goes together.

> I agree that namespaces and deployment are the highest priorities for a novice language.

Good!   

>> encapsulation policies (although I cold see them appearing high up in the lattice of language levels)


so another (in practice even the most important) use of modules may be 
primarily to *support the language levels* 

if we go for a nested newspeak like language: your level is primarily defined
by the modules / classes you have on your (nominally nested) lexical "path"


>  An advantage of including partial revelations is that it can be used to limit access to particular methods when objects (or their types) are imported.  This could (if we wanted to be more radical than we have so far) lead us to omit protection annotations in class definitions, using interface modules to hide access rather than "private" or "protected".  (I won't push this, but I find it intriguing.)

Yes so do I, actually.  I see things like protected & private as modifiers that change the 
(implicit) generation of a structural / interface type from a class (or the other way around:
that change the definition of the nominal type derived from the class) 

but then, I don't see how that gives per-object vs per-class encapsulation,
nor how it plays "nicely" with dynamic types.  (now one answer, of course,
is that it doesn't and that's fine: anyone who writes the equivalent of 
"Integer.new(7).setValue(12)"  deserves everything they get!! 

but do we really want to reify every interface & double-dispatch every method?
(answer: perhaps we do)

James, in turbulence halfway to NZ