[Grace-core] Modules vs Objects

[Marco Servetto]

> I had assumed that initially would be called immediately after the object expression was evaluated (or perhaps we should consider it as part of the evaluation -- hence the one-phase style design).  I don't see any advantage to deferring the execution, as you can easily define a different method if you wanted to defer it.  (I worry about timing of side effects)
------------------
I think that if we go for a deferred design (-not suggested-) it
should explicit (aka initially keyword) and be integrated (and not
exclusive) w.r.t. "instant" design (in this case non-initially
expressions could be forbidden to use 'self').
-NOT- implicit deferred with no easy way to make "instant" one.
Otherwise we will see many programmer doing the following:
{
var y=expr;
object{
  [def/var] x=y;
  ....
  }
}

Just to be sure to obtain the intuitive instant evaluation.
------------------

>>> What about inheritance?
>>>      module {                                                                                        (7)
>>>              inherits module.new
>>>              def x = exp1
>>>              var y := exp2
>>>              statement
>>>              method foo { x + y}
>>>      }
>>>
>>> Yes, I think that it does make sense to talk about inheriting from "module.new", and not from module, because this makes it clear that each use of a module creates a new set of fields.
> Personally, I'm more worried about the semantics of "import" as I thought we were going to treat that as inheritance of public features of the module being imported.  I see that as the important distinction -- and normally there we do not want to create new fields.  Actually most of the time I don't see modules having public fields to export, however in those few cases where they do (e.g., a counter of some sort), it seems more likely that we would want all importers to have access to the same fields rather than new copies.


I think that "static" modules vision is from the old time where memory
was still precious and we needed shared libraries.
If you have an inheritance hierarchy of modules, you want to document
only the final result, leaving the "way you obtain such module"
as an implementation detail.
If you do not create new fields (no matter public  or only used
thorough methods)
then a module X can interact in undocumented way with a module Y if
they both inherits from the same module Z than the user of
X and Y could never be aware of its existence itself.

> Do we need each use to create a new set of fields?  I'm used to thinking about modules statically, as it simplifies the semantics.  If there are strong motivating examples, then I could see it.

I strongly disagree that the semantic is simpler if you not duplicate
the fields. Is like saying that the semantic of aliasing is easier to
understand w.r.t. the semantic of a deep copy in a functional setting.
(be clear, i'm NOT a proponent of functional languages at all, I agree
that sometimes, even often, aliasing semantic is fundamental. But not
simple, only fundamental)


Marco.