Hello,

Interesting question, and interesting reply. As I'm just getting my feet wet with F#, I won't make any suggestions on which language element/feature to use. However, I can offer another perspective, from a data modeling standpoint.

I use Object Role Modeling (ORM), to assess an application domain in terms of the facts used by knowledge workers. ORM formalizes facts as Objects playing Roles.

In your example (some type of survey document), a textual representation might look something like:

Document(.Id) has zero or more Section(.Name) //Document and Section are Object Types
Section contains one or more Question(.Nr) //the parentheses denote unique Id schemes
Answer(.Id) is suggested for one or more Question

Some sample 'facts' might be that:

Document "S7" has Section "Contact Preference"

Answer "11-21-321" is suggested for Question "38"

The ORM methodology determines the number of tables to use, PKs, FKs, etc..., to produce a fully normalized data structure. Document, Section, Question and Answer are object types - classes; while Id, Name, Nr are the primary reference modes for unique instances of object types. The result are tables (Relations), columns (your object types), and rows(Tuples)

Relational structures aren't the best solution for every problem; but if that's what you have, I'd stick to those F# elements that most closely match the structure you have - I'll leave it to those that know F# better to suggest what they would be.

Hope it helps,

BRN..

Hi, tuningd,

This is a very interesting question.

I haven't worked on a problem like this, but I'll throw in some thoughts.

The data structures that are most amenable to functional programming are tuples, eg string*int. Then we can do pattern matching without having to name the components. Sequences are also very amenable to functional programming.

However, it looks as if you will need records, with named fields. I don't think that they have as clear an advantage over objects, as tuples do, but still they are more succinct and lightweight than objects, and you can do pattern matching, using the field names.

Records are, by default, immutable, but can be made mutable, by adding mutable fields. You can also add member functions.

A possible advantage of objects is that they can be shared more easily with .Net libraries, Linq, ADO, etc than records (???) (I'll try to look this up, if no one else responds). If you use objects, don't forget that they can be made "functional" with Active Patterns (which is, IMHO, as unintuitive as it sounds).

If it were my program, I'd try it first with records :)

Good luck with it, and please feel free to keep asking questions here.