Suggestions For F Sharp
Last changed: FSharpFan-99.246.250.55
.

Here are some of the suggestions people have made for F# so far on this Wiki:

  1. static fields for objects/classes (suggestion by Geoff Washburn)
  2. a Scheme-like Eval mechanism
  3. a Macro capability
  4. a nemerle style metaprogramming/macro facility for developing DSLs.
  5. a CodeDOM provider (suggestion by Karl Waclawek)
  6. a Buddy BDD library binding (suggestion by Ooge de Moor)
  7. Haskell-style typeclasses (suggestion by Vlad Andreev)
  8. OCaml-style functors (if typeclasses aren't possible)
  9. MSBuild task
  10. higher-rank polymorphism (see Peyton Jones, et al.) (suggestion by Geoff Washburn)
  11. constructor polymorphism (AKA higher-order polymorphism) (suggestion by Geoff Washburn)
  12. the compiler could determine the right order for files that include each other
  13. Integrate F# documentation into MSDN
  14. #region code folding in the VS.Net editor
  15. Indentation support in VS.Net editor (suggestion by Geoff Washburn)
  16. Ability to add method coercion as in Ocaml, e.g. class foo = object method bar (obj : <obj_method: unit->unit ; ..> ) = obj#obj_mehod() end
  17. Use System.Environment.ExpandEnvironmentVariables on #I include paths, to allow portable references to, for example, the DirectX libraries. (suggestion by Jay Hugard)
Comment
nice suggestion
  1. Deprecate ":?>" and replace with ":?<", because the latter expands ("<") the class rather than narrows (">") it. (suggestion by Jay Hugard)
Comment
in F# the '>' character in these operators indicates direction, i.e. 'a ...> b' means 'a becomes b'. It is not an indication of size.
  1. Add "repeat/until" loops. (suggestion by Jay Hugard)
  2. Modify the InteractiveTopLevel to ignore "module" statements, so that "<Ctrl> plus A" then "<Alt> plus <Enter>" from Visual Studio will interpret the entire file rather than result in multiple (and incorrect) syntax errors. (suggestion by Jay Hugard)
Comment
yes, nice suggestion. Note you can use '#load'.
  1. What is the concurrency 'story' for F# vs. (for example) Erlang?
Comment
asynchronous workflows address many aspects of the concurrency/parallel/reactive puzzle. See samples on Robert Pickering's site.
  1. Release F# Visual Studio Express (free)
  2. Optimize "raise" when used to break out of (imperative) loops, or introduce a "break" keyword. (Suggestion by Jay Hugard)
  3. Raise the precedence of member access above function binding; e.g., "fn obj.ToString()" should bind as "fn (obj.ToString())", not "(fn obj).ToString()". (Suggestion by Jay Hugard)

Past suggestions that have been included in the release are:

  1. an InteractiveTopLevel (included in v1.1)
  2. a richer ObjectModel, for enhanced .NET interoperability (included in v1.1)
  3. a BigNums library, for infinite precision arithmetic (included in v1.1)
  4. a Matrix library (included in v1.1.5)
  5. a Linq binding
  6. Make debugging DLLs possible (it's possible for any other .NET language)
  7. sequence comprehensions
  8. Make "new" bind tighter, so I can write: "some_function(a,b,new Object())" without extra braces around "new Object()"
Comment
I'd like to see some "Why use F# and Why I should learn F#" aimed at the new beginner possible new to

programming also.

Please add more!

1. configurable type promotion. #IntToFloat perhaps. after all, 1.0 + 2 = 3.0
  1. make it possible to dump fsyacc state ala OCAML's p option. Debug code exists, but is inaccessible without a rebuild.
  2. Dynamic field names just like in MATLAB! This will allow cleaner variable names, avoid numerical index bugs, and make the code more readable.
  3. Allow comparison chaining like in Python or Perl 6; e.g. "if 100 <= foo < 200 then ..."
  4. Structural record types to eliminate the need to name and declared every record type and for use as simple named arguments (by Vesa Karvonen)
  5. Allow nested type definitions (in class (and maybe interface) types) and/or local ("let bound") type definitions for finer scoping and allowing definitions closer to uses (by Vesa Karvonen)
  6. "local ... in ..." scoping construct (like "local ... in ... end" in Standard ML) (by Vesa Karvonen)
  7. Improve compiler speed (by Vesa Karvonen)
  8. Option to dump inferred types to a file (like O'Caml's "-dtypes" or MLton's "-show-def-use") (by Vesa Karvonen)
  9. Option to dump def-use information to a file (like MLton's "-show-def-use") (by Vesa Karvonen)
  10. Ability to implement interfaces more flexibly. For example, allow overriding inherited interface member definitions. Or maybe allow one to implement an interface via delegation to a given object (interface Foo via (myFoo :> Foo)). The current approach, IIUC, where each interface must be implemented separately makes the use of interfaces very repetitive and verbose. One can't even have a default implementation of an interface. (by Vesa Karvonen)
  11. Allow local ("let bound") open like in SML (by Vesa Karvonen)
  12. Polymorphic variants