[Grace-core] Lancaster Workshop update #1 - Minor changes

[James Noble]

Hi all

here are the minor changes proposed out of today's Grace workshop in Lancaster.
Many thanks to Awais (and Phil & co) for hosting us at ECOOP, and finding room
for the BOF at very short notice! 

These notes are (more readably) on the Wiki at 
https://projects.cecs.pdx.edu:8443/~black/NewOOL/index.cgi/wiki/ResultsFromJulyElevenWorkshop



James

= Grace Design Worksop - 30 July 2010 =

InfoLab 21, Lancaster University

 * Erik Ernst (Aarhus Universitet)
 * Gary Leavens (University of Central Florida)
 * Johan Winther (Aarhus Universitet)
 * Kim Bruce & James Noble

Good, intense, and productive meeting from 9am to about 3pm
(and then, for Kim & Gary, five long hours of British Rail hell)

We discussed a bunch of relatively minor stuff,
and the (flat) type system. This page is only about the minor stuff.
the flat type system is being added into the language spec which will 
the spec up to version 0.125.   The "flat" type system does *not* include
nested or exact types; details there remain to be done. 

=== Method Arguments ===

 * Method declarations (including in types) have to contain formal parameter names, and may ''optionally'' include types.  This is because dynamically typed method arguments may not have their types given explicitly as Dynamic, but simply omit the ":" and the type.  If there is just one ''identifier'' in an argument position, Grace must interpret that as a formal parameter, rather than as a type.  
 * Rules for types and patterns should generally mirror the rules for what you're allowed to leave out in type method arguments.  
 * To elide formal argument names, one can always write '''_:''', as in the following: 
{{{
findProp(_: {run(_:Node) -> Boolean}) -> OptionNode
}}}
 * as an option to consider later, Grace could disambiguate based on context: a name bound to a type is a type, a name bound to anything other than a type is an error, an unbound name is a formal argument name. This will be difficult as types, especially, may be used outside their defining context. Disambiguation is possible only because of the "no shadowing" rule on names.

=== Method Return Values ===

  * methods don't need to have an explicit '''return''' statement. By default they will return the value of last expression in the body.
  * every method will return something even if that something is "Nothing" (or Void or Unit or {})
  * when writing return types for methods we don't care about, we can leave off the "->"  
      * should think carefully about what that means: in particularly so that the answer makes sense in both static & dynamic contexts
      * e.g: type is Void unless you write at least -> to get dynamic?
      * but that would mean dynamic defs really have to write at least ''foo(a,b) ->'' 
  * '''unresolved issue:''' what should assignments return?  
      * Kim: nothing
      * Newspeak: value assigned

=== Classes  ===
 * Class arguments are available as '''def'''s in methods in the class body
 * Classes have only one constructor; Grace will not take the option for additional factory methods within the '''class''' declaration. 
     * Programmers should instead write a custom factory object that calls the class
 * Class declarations and object literals can only '''inherit''' from class declarations. 
 * '''unresolved issue:'''  multiple same-name defs in one object?

'''Rationale:'''
In principle, all class declarations and object literals exist before the program starts to run. Non-reflective programs do not create new class declarations or object literals. Even if typing is structural, implementations may compute nominal subtype relations between all classes before the program starts to run.

=== Misc. ===
  * remove option for range on collections: all collection simply range over 1..size
  * remove back-quoted identifiers ---  the  minigrace test case looks horrible, let's not do that



=== Terminology ===

|| '''term''' || '''definition''' ||
|| declaration || definition, variable definition, method, or class at  the outer level of a code block ||
|| literal || object, string, block, number, (potentially ''collection'') literals execute the current lexical scope, binding and substituting names etc.  Each time a ''literal'' is executed it conceptually  creates a new runtime ''object''.  If those objects  are ''values'' (string objects, number objects, collection objects?) then they of course the different runtime objects cannot be distinguished ||
|| object || the runtime objects in the program, created by evaluating a literal, or by requesting ''new'' from a factory object ||

So a ''class declaration'' creates a ''factory object''; an ''object literal'' creates an ''object''; a ''string literal'' creates a ''string object''; a ''number literal'' creates a ''number object'',and (crucially) a ''block literal'' creates a ''block object''.

At this point, Grace does not have ''functions'', ''method literals'', or ''method objects''.