Thanks ais, I did not know about this type. Incidentally, I came back to my code 15mins ago having had the stunning revelation that all i needed to do in order to solve the problem (as above) was just to generalize my 'option' code so that is was not type specific and then my mutually dependent types would no longer be a problem.. but it looks like thats just what the real option type does! I wish I had found this earlier, come to think of it there is a Haskell type called Maybe, ( maybe a = Nothing | Just a ) ... grr what a fool I am!

The syntax for classes used above is the "explicit" construction syntax. There is now a strong tendency to use the "implicit" construction syntax (Eventually we expect the explicit syntax to be really only used for code generation toolls like CodeDom. One current limitation make this harder: the limitation on mutually recursive classes using the implicit syntax referred to in a recent post on these forums)

For the "option", why not just use an option?

Here's one example:

1
2
3
4
5
6
7
8

type Node(name:string) = 
    // internal state
    let mutable next : Node option = None
    let mutable prev : Node option = None
    // external state
    member n.Value = name
    member n.Next with get() = next and set(v) = next <- v
    member n.Prev with get() = prev and set(v) = prev <- v

This approach lets you choose how you present the internal state externally. For example you might choose to publish properties that check for the First (no prev) and Last (no tail) conditions, and then Next and Prev would just derefence through the option values, which can save a lot of case analysis by client code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

type Node(name:string) = 
    // internal state
    let mutable next : Node option = None
    let mutable prev : Node option = None
    // external state
    member n.Name = name
    member n.IsFirst with get() = prev.IsNone
    member n.IsLast with get() = next.IsNone
    member n.Next = 
        System.Diagnostics.Trace.Assert(not n.IsLast)
        next.Value
    member n.Prev = 
        System.Diagnostics.Trace.Assert(not n.IsFirst)
        prev.Value

(You would still need to add some members to initialize or set the next/prev field - but these could be special construction functions such as CreateSingle, LinkBefore, LinkAfter etc. that help ensure the invariants your algorithms will need are maintained)

However these are, of course, simply design choices and you could just have well have used a record originally and done everything by hand from that point on.

1
2
3
4

type Node = 
    { name : string;
      mutable prev : Node option     
      mutable next : Node option  }

Kind regards

don

Hi Julian,

Thanks for your reply. I'm not sure that "null" is the best way to go about it. But it was all that I could think of given y C++ heritage. I would prefer to use an option type, but i'm not sure how to do it, as the option and the class are mutually dependent. The option type would need to be

1
2
3
4

#light 
type Next =
 | NextObj of node
 | Nothing 

but the node class would need to know about the Next type before I could write it and vis-versa. Any hints on how I can do this?

The reason for the Nothing type is for construction and traversal at runtime.

Matt