 -*- Mode: Text;  -*-
 File: WHATELSE
 Author: Heinz Schmidt (hws@csis.dit.csiro.AU)
 Copyright (C) CSIRO Division of Information Technology, 1992
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* FUNCTION: Summary of changes since Sather 0.01, June 91 (user view)
*           For more details
*             of changes see doc/CHANGE-LOG reflecting implementors view
*             of extensions see doc/EASI.txt
* HISTORY:
* Created: Sun Mar 22 10:59:10 1992 (hws)
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1. Various ports and compiler fixes, note that some ports required to
change filenames to less or equal 14 characters. Don't forget to
change your .sather files appropriately if these refer lib classes.

2. cs -chk provides traceback on failure, cs -sdb allows incremental
   compile.

3. cs -w omits warnings.

4. cs command line flags override .sather options, currently
    -cc -cflags -hom are in the intersection.

5. Compiler uses pathname canonicalization in lib/base/pathname.sa.
.sather can contain arbitrary environment variables. Make sure you
have setenv ARCH <yourplatform> set beside SATHER_HOME. These
variables are now used in sys/sys_dot_sather.

6. GC (V1.9) can now tell what it is doing and provides (unfortunately
still hacker) support for detecting memory leaks. The SILENT /
NOSILENT setup is done at Sather installation time. You may want to
install two versions of gc_.a in your bin.$ARCH directory. For
instance by
	( cd sys/C/GC; rm gc.a ; make GCSILENT=NOSILENT; \
	  mv gc.a ${SATHER_HOME}/bin.${ARCH}/verbose_gc_.a )

7. Unexecuted shell commands provide error code feedback, cf. system
include <errno.h> on your platform.

8. Sather startup message contains sufficient info for inclusion in
bug reports to sather-admin. The bin<xy> indicates the version of
persistent data structures. You may want to check with subsequent compiler 
installations at your site that you can still load dusty persistent data.

10. Many fixes in sather-mode and underlying language-independent
programming environment support, particularly full multi-click support
and adaptations to more recent Epoch versions.

11. Port plan in doc/PORTING, distribute plan in doc/DISTRIBUTE.

12. a prototype version of ICSIM, a connectionist net simultator in
lib/connectionist/icsim.

13. Fixes and extensions to xview in lib/user_interface/xview.

14. Several new abstractions in lib/base. Also revisision in
lib/data_structure.

17. Exception handling:  except (error: EXC)
                         error break -- this block


The pSather exception handling as presented in the Exception Handling
Workshop of the ECOOP91 has migrated to Sather. The integrated version
is restricted to terminating exception handling. Any block (statement
list) can be split into a normal and an exceptional portion like in

     -- block begin
     <normal flow>
   except(caught: EXC) -- could be $EXC too
     <exceptional flow>
     -- end block

The semantics are a catch/throw control flow mechanism cleanly
integrated into the strong type system. The type of the exception
(signal) object, here `EXC' or `$EXC' for `(caught: $EXC)', is the tag
that is matched by the handler. The object itself, here `caught',
contains further details.  In this way dispatched types can be used to
extend exception classes.  The exception value can thus be passed from
the signaller to the handler (in pSather on a per-thread basis).
Handlers are dynamically chained along the recursive descent of
routines (or their blocks). The last handler set up and matching the
type of the error will catch the error value. User-controled signaling
is possible. This will terminate all active procedure invocations
(dynamically) between the point of raise and the handling block. This
is usually called "terminating exception handling".  Due to the 
left-associativity of except      { { A except B } except C } ...  
cascaded exceptions are properly chained "automatically":
	<normal flow>
	except(x: A)
	<exceptional flow>
        except(x: B)
	<more exceptional flow> ...

Exceptions are raised by the expression

	error break;  -- read "error break current block"
                      
This is intended to be extended to allow block/routine name, like in
"error break foo".

The file lib/base/unix.sa contains one base class SUX interfacing
to the Signals of UniX. See the test SUX_TEST in this file for how
Unix signals can be caught.


18. Alias allows to refer to inherited features

	      alias new old {, new old}*;

allows refering to the inherited features enabling users to

  - extend complex routines without hassle
    alias inh_foo foo;
    foo is do_before; inh_foo; do_after; end;

  - repeatedly inherit features
    alias rep_foo foo;

  - solve inheritance conflicts
    A; alias prefer_foo foo;
    B; -- by default all B::foo's override those in A, except
    alias foo prefer_foo;


19. Attribute default initialization 
 
Syntax:  name `:' type `:=' expression `;'

as used from shareds. The idiom  

(*) 	res := new.initialize(xyz);

can be used instead of 

(**)    res := new;

The old meaning of `new' is preserved in this way, OLD CODE CONTINUES
TO WORK THE SAME WAY.

`initialize' is equivalent to running all attribute initialization of
the respective class (including inherited ones) in the order of their
definition and returning `self'.

One argument of type $OB can be passed to `initialize' to provide
caller-dependent information.  It can be referenced under the name
`initarg' inside init expressions.

A typical way of using this is a class encapsulating project 
conventions like those of ICSIM (cf lib/connectionist/icsim):

class ANY -- inherited by all roots of our class hierarchy, so we have
          -- one place to define our project programming conventions.
   create(init_pmap: PMAP): SELF_TYPE is
      -- Generic creation.  Builds a functioning instance based on
      -- attribute default initialization and calling back `finish'
      -- for attribute interdependent initialization.
      res := new;
      res.initialize(init_pmap).finish(init_pmap);
   end;
   
   finish(init_pmap: PMAP) is ignored("ANY::finish"); end;
      -- final context-dependent touchup, when all components are created.

   create_default: SELF_TYPE is create(PMAP::create); end; -- with empty PMAP
      -- Creates an object in the default state defined by the class.

   i(iarg: $OB; key,default: INT): INT is PMAP::from(iarg).int_opt(key,default) end;
   r(iarg: $OB; key: INT; default: REAL): REAL is
      PMAP::from(iarg).real_opt(key,default);
   end;
   ...
end;

Inside other classes we then have initialization like

	weight: REAL := r(initarg,IK::weight,.05);
        layers: LIST{T} := create_layers(i(initarg,IK::size,1));
        training_rate: REAL := 0.7;
        ...

Other project may want to follow different conventions, like no
parameters to create, or passing argc,argv like parameters.

Due to the compositionality of init expressions (Children inits are
composed entirely of parent inits, modulo attribute redefinition),
this provides a much higher declarative level to deal with
initialization. 

However there are a few flaws that motivate further work in this area:

1. The one argument "initarg" falls from the sky.
2. "initialize" is public and can be called in mainstream.
3. "create" routines do not combine "automatically" in multiple
  inheritance "combinations".



