[Grace-core] Modules vs Objects

[James Noble]

> We've agreed that modules are really just objects,  but I see some differences that perhaps be implied by the use of the two different keywords.

given we have a keyword for "class", I won't object too much with a keyword or "module"

> 
> We are working on the assumption that 
> 
> 	object {											(1)
> 		def x = exp1
> 		var y := exp2  
> 		statement
> 		method foo { x + y}
> 	}
> 
> really means something like
> 
> 	object { 											(2)
> 		def x
> 		var y
> 		initially { 
> 			x = exp1
> 			y := exp2
> 			statement
> 		}
> 		method foo { x + y }
> 	}

well I think this depends if we end up with a "one-phase" or a "two-phase" design.
So far we're trying just one phase, which I don't think requires an initially block split out.
The basic semantics are fine.

> The syntax (2) is not too bad for objects, but has the disadvantage that the time when the initially method is executed is not precisely specified.  This matters if exp1 or exp2 refer to variables or to mutable objects.  So I think that it's better not to just
> re-write (1) into (2), but to allow the programmer to choose her syntax and semantics as the situation demands.

I think we do need to specify 

> An alternative is to make 
> 
> 	module {											(3)
> 		def x = exp1
> 		var y := exp2  
> 		statement
> 		method foo { x + y}
> 	}
> 
> mean "execute exp1, exp2 and statement now", while
> 
> 	object {											(4)
> 		def x = exp1
> 		var y := exp2  
> 		statement
> 		method foo { x + y}
> 	}
> 
> means "execute  exp1, exp2 and statement later", i.e., (4) is implicitly re-written in to the form with initially, but (3) is not.

I can see that, but I don't think we need to go there. Yet.
If we have too many issues with the single-phase design, then 
we'll need to re-examine this.  

> A file without a top-level object or module is implicitly surrounded by
> 
> 	def filename = module {  <file contents> }

the second half makes sense I think - 
and is in itself a good reason for a "module" keyword
(otherwise we can't distinguish implicit and explicit modules)

I guess one question is, is it an implicit def, or an implicit method? (like a class)

> This lets 
> 
> 	print "hello, world"
> 
> remain a valid program, this time defining a module that prints "hello, world"

which we do want! 

> 
> What about inheritance?
> 
> 	object {											(5)
> 		inherits bar.new
> 		def x = exp1
> 		var y := exp2
> 		statement
> 		method foo { x + y}
> 	}
> 
> really means something like
> 
>  	bar.new extendedByMethodsOf object {		
> 		def x											(6)
> 		var y
> 		initially {
> 			super.initially
> 			x = exp1
> 			y := exp2
> 			statement
> 		}
> 		method foo { x + y }
> 	}

modulo initially comments!

> What about 
> 
> 	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.

(and is an independent object).
That also makes sense but then shouldn't modules be methods/classes?

> inherits would still have the extendedByMethodsOf semantics.  Do you see a need for the deferred execution semantics when one module inherits from another?

at this stage, we're trying *without* the deferred semantics.
The more I think about it (i.e. without deferral), the more I like it - which doesn't always happen,
and nor does it mean that's the way we should go in the end.


there's certainly stuff here to talk through tomorrow.

James