[Grace-core] Fwd: Some notes on pattern matching on the wiki

[Kim Bruce]

I want modules to package up:
    a collection of objects and classes
    a collection of types
It should indicate which of these items should be exported and also indicate what items from other modules should be imported.  I had hoped that they could also indicate a subset of the method names in an object type to be exported, but I am willing to give that up.

It would be nice to support renaming (of types and/or method names) in some way, but that is less crucial for a language for novices.

Ideally we would have separately compiled module specifications and implementations (the specification just lists declarations and any contracts/comments, but with no operational semantics).

Kim



On Jul 7, 2011, at 2:52 PM, Andrew P. Black wrote:

> 
> On 5 Jul 2011, at 19:00 , Kim Bruce wrote:
> 
>>> 
>>> 
>>>> So what is the graceful view of nested classes anyway?
>>> 
>>> not sure yet. I think we are close to committing to something close to gBeta/Newspeak/ (Ceylon?) view 
>>> but haven't hurtled over that waterfall quite yet..
>>> 
>>> that is - yep classes nest, modules are nested classes, class family inheritance (overriding inner classes in subclases) works right...
>> 
>> NO! NO! NO!  Modules are not nested classes!!!  They have nothing to do with each other!!!!  Modules are modules -- they are not used for generating new objects and are not extended using inheritance.  Why confuse the two very different concepts????
>> 
>> I wish you hadn't posted that without discussing it first ...
> 
> We clearly need to discuss this further.  But I don't see them as very different concepts.  They are both stylized uses of objects. But I think that it depends rather on what you want modules to do.
> 
> What /I/ want a module m to do is package up:
> 
> 	a collection of new objects
> 	a collection of new factories (which are, of course, just a special cases of the above), and
> 	a collection of new types (which may also be a special cases of the above!)
> 	
> These will need to be named in a way that separates them from other stuff that I may have named: m.obj and m.fact provide a great way to do this.   They will also need to be dependent on other modules, which are given to m as arguments.  (So, for example, m.Dictionary might depend on an argument to m that is a Set.)
> 
> Others may have different desiderata for modules.  I think that we will reach closure on this faster if we first talk about what they are /for/.  If our purposes can't be accomplished with objects, then we should certainly invent something else.  Otherwise: concepts "should not be multiplied beyond necessity"!
> 
> 	Andrew
>