[clean-list] Clean and scientific programming

[Sven-Bodo Scholz]

On Fri, Aug 31, 2001 at 03:09:24PM +0200, Jan Kort wrote:
> 
> I didn't anticipate on the paper not being
> publicly accessible, but there is a link with
> Clean. The main asset of Sisal discussed
> in the paper is it's copy elimination
> analysis. Clean's uniqueness types could be
> used to achieve the same effect.
> 
IMHO, not quite the same effect:

claim 1) "There remains a significant specificational difference"

   If the programmer inserts uniqueness annotations, he has to carefully think
   about the usage of his data structure. Whenever two modifications of a unique
   data structure are required, he has to explicitly create a copy of that structure.
   The "only" help from the  system he gets (which often is very helpful indeed -
   but often is annoying as well) are uniqueness violation messgaes that pinpoint
   (sub)expressions which might introduce unintended sharing.
   In other words: The programmer has to think about the allocation and potential
   reuse of his array; he has to organize the allocation and deallocation of memory
   portions turning a functional data structure into a state-full one.
   This contrasts the Sisal approach, where arrays (on the language level) remain
   immutable expressions that are consumed and produced by functions in exactly the
   same fashion as all other functional data structures are. If an array is used in
   a modifying context only once, it is updated destructively otherwise it is copied.


claim 2) "There remains an effficiency difference if uniqueness is not statically available"

   Even if the Clean system is able to infer uniqueness types (which AFAIK to some extent is done
   in the actual compiler ?! Maybe someone of the group could comment on this one (Sjaak?))
   further significant differences to the Sisal approach can be observed whenever uniqueness
   can not be infered (which probably is the most common case): In Sisal - due to reference counting
   - memory can be reused as soon as the last reference is gone. As a consequence, an array
   that is modified twice can be updated destructively when applying the second modification
   operation. In Clean, this information at runtime is not available requiring two copies to
   be made and garbage collection (in a later stage of computation) to reclaim the memory of
   the initial array.

Therefore, I think that the "the same effect" only holds in terms of efficiency AND that
it only holds iff uniqueness can be assured at compile time.


  Sven-Bodo

-- 
Sven-Bodo Scholz                        University of Kiel            
email: sbs@informatik.uni-kiel.de       Department of Computer Science
http://www.informatik.uni-kiel.de/~sbs/ Herman-Rodewald-Strasse 3, 24118 Kiel  
Phone: +49-431-880-4482              	Germany