Suggestions For F Sharp

Enter a topic name to show or a new topic name to create; then press Enter

.

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
13. Please document the syntax much better. Earlier I learned Haskell and found it to be an elegant functional language, but I am thoroughly baffled by F# syntax. Which is a shame because I really want to use Functional Programming with .NET. And I keep coming across snippets of F# online that the current CTP cannot parse, so I suspect F# has changed over time and this is why I see so many different syntaxes for doing the same thing. The worst syntactic randomness seems to be in class definitions. It looks like there are multiple ways to define variables in classes, multiple ways to define functions in classes, multiple ways to define indexers... I'm so thoroughly confused I don't know where to begin. So please write better documentation, preferably exhaustive (list all possible ways to do the same thing), contrastive (pros and cons of each syntax), and relate the syntax to roughly equivalent syntax in C# or Haskell. I'm just about ready to give up on F# due to its syntax alone - David Piepgrass
A Macro facility in the spirit of Lisp/Scheme
1/20/2010 4:09:59 AM - -75.102.39.212