F# - The thing with the namespaces
I just spent a little while hunting down an interesting problem in a little F# app. I had a bunch of code in a single file and I was going to structure it a bit and move certain parts into separate files. I started out from some code like this:
Yeah, I know - useless code. The point is that there are dependencies between the three types. So I was trying to move the interfaces into a different file, and suddenly the type blah couldn’t find the interfaces anymore. Interesting.
The solution to this is simple, but looks a bit stupid. At the start of my new file, I had of course repeated the namespace declaration namespace Sturm.MyNamespace, but that is not enough. Even though that puts all the types in the same namespace, it is still necessary to explicitely open the namespace as well, if you’re going to access elements that have been defined elsewhere for the same namespace. So I need this header in the file with the class type:
While I can see the logic behind that, it doesn’t seem like a very useful approach… perhaps I’ll figure out the reasons later, right now I’m glad I’ve found a solution.






Hi Oliver,
Out of curiosity, what got you interested into F# ?
Is it for XPO / XAF ?
Regards,
Marc
Comment by Anonymous — 19/3/2008 @ 11:49 am - 1 month, 4 weeks ago
Hi Marc - no, not specifically. It’s a great language, and I’m almost sure I like it better than C#.
Comment by Oliver Sturm — 19/3/2008 @ 11:52 am - 1 month, 4 weeks ago
Seriously, if for example you had to start XPO over, would it make sense to develop it in F# ?
Comment by Marc — 19/3/2008 @ 1:15 pm - 1 month, 4 weeks ago
Interesting question… perhaps not, since XPO is a library and an important design criteria is that others must be able to use it easily. So unless my potential target group uses F# as well, they might not be able to benefit from things I have done, and in some cases usability might be decreased.
That said, "does it make sense" is a bit of a weird question. I believe that F# is generally a more powerful language than C#, and so yes, it makes sense to use the most powerful language for most tasks. Would I start a new project in it today? Yes, I probably would. Would I go back and rewrite something that exists, for a perceived benefit? In most cases, probably not, since the benefit wouldn’t justify that. But I’d probably try to use F# for additions to an existing core - .NET makes this easy. Whether or not these approaches are actually considered today, in 2008, in many development teams, depends on yet another set of conditions…
I’ve probably not looked into all the issues that might come up, but at least there’d be some questions to answer before one could consider using F# for a general purpose library that needs to be reused from other languages. In this situation, more often than one we find ourselves using the least common denominator only.
Comment by Oliver Sturm — 19/3/2008 @ 2:18 pm - 1 month, 4 weeks ago
Here a short article on F# (for those for whom F# is totaly new):
<a href="http://msdn2.microsoft.com/en-us/magazine/cc164244.aspx" title="F# Primer: Use Functional Programming Techniques in the .NET Framework">
Comment by Marc — 20/3/2008 @ 2:58 pm - 1 month, 3 weeks ago