Back to Questions
1.8k
views3
comments
Feature request: forward declarations
f#functional

This goes all the way back to the issue of not being able to have mutual dependencies spanning multiple files. Forgive me for beating a dead horse, but I would like to suggest a practical solution: some variation of forward declarations, limited to the extent necessary to otherwise encourage as much modularity as possible.

The number of problems caused by the inability to have mutual dependencies spanning multiple files would seem to warrant allowing forward declarations:

1. Object models tend to have mutual dependencies. I see no other reason that F# shouldn't be used to write object models; after all, it is supposed to be a functional language with OO features.

2. Expert F# has samples of ASP.NET code, but in practice, F# is incompatible with ASP.NET for the only reason that ASP.NET compiles files in an arbitrary order.

3. There is no possibility of any GUI designers in sight, even though there are no other reasons that F# is not suitable for writing GUIs.

4. There are also no ORM designers in sight.

5. It affects code conceptualization and design on a very large scale, and because the problem is so unexpected (not even C++ suffers from this problem), a lot of time might be invested in a project before this blocking issue is noticed.

The current workarounds aren't very acceptable:

1. Dumping all mutually dependent code in a single file is totally impractical in larger projects with multiple developers.

2. Increasing inheritance layers just to overcome this problem, as was suggested in the past, results in even uglier code that is not only uglier for developers but also uglier for consumers.

3. As of the latest version, in order for a type augmentation to be intrinsic, it must be declared in the same .fs file as the type being augmented. (Why?!?!)

Brian mentioned in the other thread that all languages have strengths and weaknesses. But really -- the weaknesses caused by this limitation unquestionably outweigh the strengths. Mutual dependencies are a fact of life, and while modularization is obviously important, its importance when it concerns dependencies within the scope of a single assembly is being given far too much weight. Is it really worth sacrificing all this functionality just for this one sanity enforcement?

.

Agreed, this does seem like a throwback (as you say, very far...) It almost smacks of a synthetic political restriction to make sure there are still some checkmarks on the C# side of the page. :)

One excuse, type augmentations, which depend on their position in the compilation unit and then only usable thereafter in the same file, is not worth keeping, IMHO.

I can't see why F# can't be functional in-the-small - inside of lexically scoped language constructs (fn defs, funs, and whatnot) - but treat larger-scale program structure in a standard way that is compatible with standard modern software development.

One of C#'s greatest advantages over Java is it's n'er-do-care attitude about where program source comes from in realtion to package/namesspace structure (any directory, partial or not, etc.) -- now as advanced as F# is in other respect, seems like it has actually re-wound time past the invention of modern linkers.

One answer is to use C# as "glue", but that doesn't work well as the interop story is really about calling C# from F#, and not visa-versa, and not all F# constructs are (at least transparently) callable from C#, which is understandable, but means the onus is on F#.

Even with the way things are, you'd at least think I could right-click on the project and have it sort the list of files *for me* and tell me if there are any problems.

Don't get me wrong - I love F# or I wouldn't bother posting - and I'm sure that treating program source linearly is convenient for the type of advanced analysis that F# does - but hopefully we'll have a nice surprise here sometime in the future :)

By on 10/16/2009 7:56 AM ()

... but hopefully we'll have a nice surprise here sometime in the future :)

To quote myself from the other thread:

</li><li>We have some long-term plans to extend F# so that 'recursive code' can span multiple files, but such a language feature is unlikely to make the VS2010 release.</LI> We recognize the utility of this feature, but it is non-trivial to design and implement.

By on 10/16/2009 11:00 AM ()

Well Beta 2 should be released "soon" now, so we'll see what's in store. Maybe they've done some work to help out here. I don't think there is much disagreement in general about having some way to make object types mutually recursive across files.

I don't understand point 2, about ASP.NET. Do you mean the "App Code" directory so you can drop loose source files in and let it try to sort it out? Because it works fine with ASPX and so on, apart from the Beta 1 bugs with the codedom, and I was unaware that people still copied .cs or .fs files to deploy ASP.NET apps. Just curious what you ran into.

I don't get point 3 either, how there's "no possibility" of GUI designers. If you mean that VS 2010 probably won't ship one, OK. But subclassing a generated file from XAML doesn't really seem that bad or impossible. Not to mention using a specially marked region as in VS2002/2003 would sitll _work_. Just saying "impossible" is a bit of an exaggeration.

By on 10/16/2009 4:44 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper