Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
RE: [Caml-list] let mutable (was OCaml Speed for Block Convolutions)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-06-15 (16:07)
From: Dave Berry <Dave@k...>
Subject: RE: [Caml-list] let mutable (was OCaml Speed for Block Convolutions)
I once advocated a "const" datatype for SML.  The const constructor
would create unique immutable values that could be compared for pointer
equality, satisfying Don's first use of refs.  (It's possible I included
these in the Edinburgh SML Library -- I don't recall after all these
years).  But this idea never caught on.

A similar idea is to define:
  type 'a pointer = 'a option ref
  fun null (ref NONE) = true | null _ = false
  fun ::= (p, v) = p := SOME v


-----Original Message-----
From: Don Syme []
Sent: 15 June 2001 04:20

[ To expand on why "mutable" fields are, IMHO, so much better...  In
Standard ML "refs" get used in data structures for four main purposes: 
  - to get values that can be compared by pointer equality; 
  - to ensure sharing of an allocation cell; 
  - to allow "regular" mutation; 
  - to cope with initializing recursive data structures using "ref

Because of these multiple uses I honestly used to get "ref" type
constructors nested two or three deep (when designing some
pointer-chasing graph structures)!!  

I was never able to get this code right until I switched to Caml,
precisely because my structures became simpler.  In Caml the combination
of inbuilt pointer equality and "mutable" made things sufficiently
simple, and the ability to allocate at least some recursively linked
objects without using "ref option" also helped.  

Bug reports:  FAQ:
To unsubscribe, mail  Archives: