Lets say I\'m building a parser for a domain-specific language in F#.
I\'ve defined a discriminated union to represent expressions:
type Expressi
It seems to me that it would be cleaner if each member of the union defined its own
InferType
andGenerateCode
locally with it.
I believe you mean "more familiar", not "cleaner".
Really, is your ideal to have you code generator implementation spread out across 10 different classes?
There is definitely a fundamental tension between whether you want to group things "by type" or "by operation". The usual OO way is "by type" whereas the FP (functional programming) way is "by operation".
In the case of a compiler/interpreter (or most things that in OO rely heavily on the Visitor pattern), I think "by operation" is the more natural grouping. The code generator for If
and And
and Or
may have a bit in common; the typecheckers of the various nodes will similarly have commonalities; if you make a pretty-printer, there will likely be formatting routines common to all the node-pretty-printing implementations. In contrast, printing, typechecking, and codegenning an IfElse
really don't have much to do with one another at all, so why would you want to group those in an IfElse
class?
(To answer your questions: yes, this is idiomatic. Is there another way - yes, you can do it just like you would in C#. I think you'll find you're much less happy with the C# way, and that the code will also be 2-3x larger that way, with no benefit.)