Browse thread
RE: [Caml-list] let mutable (was OCaml Speed for Block Convolutions)
- Dave Berry
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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 Dave. -----Original Message----- From: Don Syme [mailto:dsyme@microsoft.com] 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 option". 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: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr