Skip to content

Work items

Jump to bottom
funnelweb edited this page Jul 26, 2012 · 13 revisions

F# language binding work items and suggestions

This page lists various features that could be added to the F# plugin for MonoDevelop. If you want to contribute to the project, you can either choose one item here or suggest and implement your own idea. Do you have more ideas and suggestions? Do you want to work on some feature and need advice? Join our mailing list!

Additional F# Templates

The plugin currently contains only basic templates (empty source/script file and empty console application). It would be useful to have more templates for typical applications that people develop with F#. The first work item would be to write a list of the most useful templates and discuss them on our mailing list.

  • Importance Important
  • Solution See existing templates in project resources
  • Difficulty Creating templates is relatively easy. Finding a good set of templates suitable for F# is more tricky.

Debug Debugging

Although F# compiler emits correct debugging information (that can be used with the command line mdb debugger) the debugger in MonoDevelop is for some reason failing to debug F# projects. It would be nice to get this feature working - the work item is mainly to find out why this doesn't work (because all the required features seem to be implemented).

  • Importance Important
  • Difficulty Shouldn't be difficult, but requires finding out how debugging works in MonoDevelop

Ordering of F# source files

The order of files in F# projects is important, because the F# compiler does not allow recursive dependencies between files. It would be nice to be able to specify order in "Solution" window.

  • Importance Important (not critical, but it would simplify interop between VS and MD)

Insert spaces instead of tab character

F# requires indentation using spaces, but the default settings in MonoDevelop is to insert the tab character when a tab key is pressed. We should find a way to make sure inserting spaces is the default behavior. Right now you have to set the default source formatting for all "text" filees.

  • Importance Important

Go to Definition

Go to definition (F12) can be implemented using functionality exposed by the F# language service.

  • Importance Nice to have.
  • Solution This can be done using GetDeclarationLocation method of TypeCheckInfo (see service.fsi in F# source code). We'd have to add wrappers for the method to Services/FSharpCompiler.fs and then call them from our language service.
  • Difficulty This is relatively simple task. You need to find out how to implement the feature in MonoDevelop (because we're not relying on completely standard API) and it requires a few additions to F# plugin source, but mostly following existing patterns.

Navigation Bar

When opening C# file, you can see items such as classes and members in a navigation bar on top of the editor. This feature could be added to the F# integration, because the F# language service exposes all the necessary information via untyped parse information.

  • Importance Nice to have.
  • Solution This could be done by using GetNavigationItems member of the UntypedParseInfo type (see service.fsi in F# source code). We'd have to add wrappers for the type to Services/FSharpCompiler.fs (so that the feature can be used with standard F# installation using Reflection). The access to untyped parse info would also have to be added to LanguageService type, but the machinery is already there.
  • Difficulty This is relatively simple task. You need to find out how to implement the feature in MonoDevelop (because we're not relying on completely standard API) and it requires a few additions to F# plugin source, but mostly following existing patterns.

Collapse type declarations

This is similar to the previous work item. F# language service already exposes the needed information (via the Range properties of objects returned by GetNavigationItems).

  • Importance Not important (the regions reported from F# language service are quite limited)
  • Solution Similar to the previous work item
  • Difficulty Similar to the previous work item (depends on how difficult is it to implement collapsing in MonoDevelop)

Improve colorization

Current implementation uses the XML based specification of syntax. This has some limitations (e.g. doesn't recognize let! and a few other tricky things and it doesn't handle #if macros, doesn't handle nested comments etc.). It should be possible to re-implement colorization by calling the F# tokenizer exported by the language service.

  • Importance Important (although the current is ok, it is not perfect)
  • Difficulty Relatively simple (depends on how difficult is to use tokenizer in MonoDevelop)
  • Solution For some hints on how to do this in MonoDevelop see this mailing list post. For information about using the F# tokenizer, look at F# web snippets.

Improve F# interactive

The VSLab project extends the F# support for Visual Studio with tools that make scientific programming (in the style of Matlab) using F# easier. The project adds support for creating charts from F# Interactive, doing 3D visualizations and similar. It would be interesting to add similar features to F# bindings for MonoDevelop.

  • Importance Nice to have (this is not useful for everyone, but it would make F# in MonoDevelop attractive to scientific community).
  • Solution This would require adding charting tools (i.e. using existing open-source project) and modifying F# Interactive a little to expose some objects for interoperating with the MonoDevelop plugin.

Gtk# Editor Support

MonoDevelop provides a nice editor for creating Gtk# user interfaces. It may be possible to provide support for the editor in F# projects. F# is probably not going to be used mainly for Gui development and people can always reference simple C# library with the Gui, but it would be nice to have.

  • Importance Nice to have/Not very important
  • Difficulty and Solution Not known. Depends on what needs to be done in order to support the editor.

CodeDom Provider (for template generation)

The F# language binding currently doesn't expose CodeDOM provider. It contains CodeDOM generator from F# PowerPack, but that tends to generate ugly F# source code, so it is disabled (and it is not used for generating MonoDevelop templates). The CodeDOM generator from PowerPack attempts to generate F# code that compiles, but we need nice code that can be used in templates.

  • Importance Not very important (the default templates generated by CodeDOM aren't that useful for F# projects)
  • Solution This could be done by simplifying the F# code generator from PowerPack or writing a new (simpler and incomplete) implementation.
  • Difficulty This is relatively simple task that requires some familiarity with CodeDOM and F#, but doesn't require any interactions with the F# compiler or MonoDevelop IDE.

F# Resolver Provider

Resolver provider is used to expose most of the information about source code to the MonoDevelop IDE and is used for default implementation of many features (such as go to definition). To support resolver provider, the F# language service would have to return AST with the parsed code in a format required by MonoDevelop. As a result, more MonoDevelop features would "just work"

  • Solution This requires modifying the F# compiler source code (to expose the required information). It would be a good idea to discuss this on our mailing list first.
  • Difficulty Modifying the F# compiler is difficult task, but it could be used for many advanced features (e.g. maybe even refactoring)
  • Importance Nice to have (what all features would we get as the result remains to be answered)
Clone this wiki locally