While there is no One True Correct Style, some points of general agreement exist in the C# community regarding coding standard / style; usually, they are variations of the .NET Framework Design Guidelines.
When you look into F#, though, the standard is visibly different from what is considered normal in C#. As an example, the functions accessible on List or Seq (almost) all start in lower case: List.fold, List.map (but List.Cons and List.Empty don't...), whereas it is usually accepted that a method or property in C# should be capitalized.
So my question is, are there widely accepted coding conventions for F#? Is there an equivalent to the Framework Design Guidelines, or a good coding standard out there? And, as a bonus, in the whitespace-based F# world, do people have topics to argue endlessly about, similar to the timeless C# curly-brace position?
The F# team has drafted a document that sounds like exactly what you're asking for. (We're currently in the process of incorporating feedback from community/insiders we've sent the draft to.) It is likely to be published in the near future. I'll be sure to link it here when it's published.
EDIT
The document is archived now and you should consult the updated version instead.
There's also a section of the MS docs that's derived from itL https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/component-design-guidelines
Update #2: There is now an F# Style Guide on Microsoft Docs. This contains new material and also incorporates the material I linked to in Update #1 below.
Update #1: Don's paper (linked below) has been removed from the Microsoft site. However, A comprehensive guide to F# Formatting Conventions appears to be based on the same paper.
Don Syme's F# Coding Guidelines paper deals with the "curly-brace" formatting style issues for F#.
Related
In researching a topic related to programming I came across a pointfree refactoring tool for Haskell in the lambdabot and was wondering if F# can be refactored into a pointfree style?
I am not advocating the use of pointfree style, but see it as a means to better comprehend a function.
Note: pad answered an earlier version of this question, but I reworded this question as the answer is of value to others learning and using F# and I did not want this to be deleted because of some close votes.
Note: Just because I changed the question, don't take the answer to mean that one can not code in a point free style using F#. It can be done in many cases but there are restrictions you have to follow.
Short answer
No.
Long answer
There are a few things in F# that make such a tool impractical. (1) Due to .NET interop, F# code often has side effects and automatic code transformation becomes really difficult when side effects come in play. It's not the case with Haskell; equational reasoning is much easier in Haskell and you can rewrite left-hand sides by right-hand sides without altering their evaluations. (2) Point-free programming in F# is limited by value restriction. I'm not sure you can do code transformation aggressively without hitting this issue.
I think it's more practical to assume that F# code is pure and value restriction doesn't occur in particular cases in order that we can give users some hints. Users can apply suggestions discretely after evaluating that the suggestions are actually correct. It's closer to HLint approach than the one you referred to. FSharpLint has added some linting rules in this direction.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Code documentation for delphi similar to javadoc or c# xml doc
I want to start documenting a very large Delphi application, which currently has no documentation whatsoever. My coworker suggested a javadoc type documentation style because we can then run an automated program to create nice documentation which is searchable and looks pretty.
(* Description of the function
#param S some string
#param Index the index of string s
#retval TRUE condition where it is true
#retval FALSE otherwise.
#see IndexOf
#see Sort
#see Sorted
*)
bool Stringlist::Find(const char *S, int &Index)
{
[...]
}
Is this the best way I can accomplish meaningfull documentation for my project? If so what is a good program to handle these types of comments . So far I have had Doc-O-Matic recommended to me.
If it is any use the program is very old, it has been constantly developed since 1993 or so and has gone though many different authors, many different styles, IDEs, standards, etc.
Take a look at SynProject, an Open Source tool written in Delphi.
It was designed to handle a full documentation workflow, from specifications to release notes, including tests, architecture and design; and of course there is an integrated Delphi parser to generate architecture documentation from existing Delphi source code.
For the architecture document, the source code can extract comments (ala JavaDoc) then embed this text into the main Architecture document (with class hierarchy diagrams and unit dependencies).
You write a plain text file using a wiki-like syntax in a dedicated text editor, then SynProject creates well formated Word documents from it. Some Wizards are available to access the content. But since it's stored as plain file, multiple programmers can write on it, using any SCM tool (SVN, Fossil...).
For instance, I currently use it for writing maintenance documentation for a huge and old Delphi application (about 2,000,000 lines of code written in Delphi 5 and 6), with no prior available documentation. You describe the changes made to the code (by quoting the unit/class/method), then the tool will update all documentations to reflect and trace those modifications. SynProject was designed to be compliant with some very "delicate" regulation rules (IEC 62304), but can be used for any project due to its unique "flat" design.
There are no "best ways" for creating in-source documentation. Consequently, any answer will be subjective to some extent.
First of all you must choose your in-source documenting style. You can use either "native" comments, JavaDoc or XMLDoc. After choosing the documenting style you should choose the documenting standards.
Also you need a documentation generator to publish your in-source documentation (in html, pdf or other format)
As for Delphi source code, currently JavaDoc style is the most supported. I tried DelphiCodeToDoc (it uses JavaDoc) to generate html documentation, and it works. I think you can find more documentation generators for Delphi sources supporting JavaDoc.
Still I prefer XMLDoc style and Delphi Documentation Guidelines. That is subjective. I assume that the best XMLDoc Delphi documentation generator now is Doc-O-Matic. It also supports JavaDoc style, I am currently experimenting with it. It does not support all the tags mentioned in Delphi Documentation Guidelines, for example it does not support <list> tag, but you can use <para> instead and generate respectable documentation.
Try what is available and choose what you like more.
If you just want to document your source code based on functions comments, I would recomend you to use Doc-O-Matic.
But the real question here is: should you document your source code? I dont think so. According to TDD and XP, you should not comment your code at all. Your code should contains good procedures names that really indicates what the procedure does. So you could consider not document it, just refactor it so it can be easily understandable.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I don't believe seeing this. It says:
For April, Chris Smith will be presenting on writing a Java to x86 Compiler in F#.
The presentation may go on for an hour or two which definitely is not enough to write a compiler. I've heard that F# is powerful, but this powerful?
Well, all I wanted to ask is this: Can you write a compiler in F# that quickly?
Let's first start with a few corrections:
It's not a Java compiler, it's a compiler for a small subset of Java.
It doesn't say anywhere that the compiler will be written in the time, only that it will be explained.
In fact, it doesn't even say that, it says, it will be presented. Heck, I can present GCC in 3 minutes. It's not gonna be a very useful presentation, but it's gonna be a presentation.
That said, explaining a well-structured, simple compiler for a simple language implemented in a language which is well-suited for writing compilers within an hour is definitely feasible.
F# is a member of the ML family of languages (specifically, a close cousin of OCaml), and those are indeed well-suited for writing compilers. In fact, the reason why Robin Milner chose the name ML (meta language) for his language, was because it is specifically designed for writing compilers. A compiler is basically a big function (thus making it very natural to implement in a functional language) that detects patterns (thus making it very natural to implement in a language with pattern matching) and executes a little bit of code for each pattern it detects (thus making it very natural to implement in a language with first-class functions). And whaddayaknow? F# is a functional language with very sophisticated pattern matching facilities. Another nice feature is an expressive type system with algebraic data types and discriminated unions which makes it very easy to represent Abstract Syntax Trees.
At the Lang.NET Symposium Jason Olson gave a talk on F#, during which he showed some pieces of an interpreter that he is currently working on that demonstrate these features very well.
Fredrik Holmström is currently working on IronJS, an ECMAScript 3 implementation for the Dynamic Language Runtime. Take a look at the code, specifically the AST types and some of the analysis and parsing code.
Jonathan Tang's Write Yourself a Scheme in 48 Hours is another good example of writing an interpreter, this time in Haskell which shares many features with F#.
The 90 Minute Scheme to C compiler by Marc Feeley is a presentation about a Scheme compiler written in Scheme.
In Implementing Scheme in Ruby, James Coglan teaches the audience Scheme, live-codes and explains a Scheme interpreter in Ruby and writes a couple of sample Scheme programs, all in 15 minutes.
Giving a presentation about a project isn't the same thing as implementing the whole project during the presentation.
It's perfectly possible to present some interesting aspects of a Java to x86 compiler within an hour, and even show some code: but that's not the same as creating all the code then and there.
Java is a fairly complex language, so I suppose that Chris isn't going to implement a complete Java compiler. However, his talk really points out that manipulating with code (and tree-like structures in general) is much easier in F# than in any other .NET language. That's why F# has been used in various static analysis tools (e.g. Microsoft's static driver verifier)
Tools like fslex and fsyacc make it easy to write parser for a language. Chris has a blog with simple mathematical expressions. Robert Pickering wrote a more sophisticated example that actually generates IL code (compiles mathematical expressions to .NET) in just a few lines of code. This can be even easier on .NET 4.0 if you generate code using Expression Trees.
So I suppose that even if he was writing the compiler from scratch, he could write compiler for a langauge that can be used to write non-trivial sample programs.
Can you write a compiler in F# that quickly?
I have written two tiny compilers in F# over the past week, each in about that much time. So yes, it can be done. Here is one of them.
Note that the ML family of languages that F# is descended from were specifically designed for this application (metaprogramming).
I use blogger and I install a windows live writer, I don't know how to insert F# code.
I installed several code highlighter, none of which support ocaml or f#.
I now use VSPaste, a plugin for WLW, which can 'paste from Visual Studio' and copies the VS colors.
Get a better syntax highlighter. Alternatively, store your code in Github Gists and embed on your blog. That way, any code that Github can highlight, you can highlight.
[BTW, the tool you use to write your blog has nothing to do with your syntax highlighting woes.]
You may want to post this question on HubFS. There's more likely to be people there who know what options are available.
I think it depends on how sophisticated syntax highlighting you need. However, most of the formatters should be customizable, so you should be able to adapt them to work reasonably well with F#. On my blog, I use this formatter for C# (which is based on regular expressions), and I added my definition for the F# langauge.
Since I typically use the // comment format in blog posts and strings are formatted in the same way as in C#, I didn't have to do many changes. I only added a couple of F# operators (mostly as I needed them). I also added F# keywords which you can find in the language specification.
Since F# is somehow based on ML -- Ocaml or ML highlighter can help in most cases (except for example "//" comments).
What is the best way to use F# to parse an AST to build an interpreter? There are plenty of F# examples for trivial syntax (basic arithmatical operations) but I can't seem to find anything for languages with much larger ranges of features.
Discriminated unions look to be incrediably useful but how would you go about constructing one with large number of options? Is it better to define the types (say addition, subtraction, conditionals, control flow) elsewhere and just bring them together as predefined types in the union?
Or have I missed some far more effective means of writing interpreters? Is having an eval function for each type more effective, or perhaps using monads?
Thanks in advance
Discriminated unions look to be
incrediably useful but how would you
go about constructing one with large
number of options? Is it better to
define the types (say addition,
subtraction, conditionals, control
flow) elsewhere and just bring them
together as predefined types in the
union?
I am not sure what you are asking here; even with a large number of options, DUs still are simple to define. See e.g. this blog entry for a tiny language's DU structure (as well as a more general discussion about writing tree transforms). It's fine to have a DU with many more cases, and common in compilers/interpreters to use such a representation.
As for parsing, I prefer monadic parser combinators; check out FParsec or see this old blog entry. After using such parser combinators, I can never go back to anything like lex/yacc/ANTLR - external DSLs seem so primitive in comparison.
(EDIT: The 'tiny arithmetic examples' you have found are probably pretty much representative of what larger solutions looks like as well. The 'toy' examples usually show off the right architecture.)
You should take a copy of Robert Pickering's "Beginning F#".
The chapter 13, "Parsing Text", contains an example with FsLex and FsYacc, as suggested by Noldorin.
Other than that, in the same book, chapter 12, the author explains how to build an actual simple compiler for an arithmetic language he proposes. Very enlightening. The most important part is what you are looking for: the AST parser.
Good luck.
I second Brian's suggestion to take a look at FParsec. If you're interested in doing things the old-school way with FsLex and FsYacc, one place to look for how to parse a non-trivial language is the F# source itself. See the source\fsharp\FSharp.Compiler directory in the distribution.
You may be interesting in checking out the Lexing and Parsing section of the F# WikiBook. The F# PowerPack library contains the FsLex and FsYacc tools, which asssist greatly with this. The WikiBook guide is a good way to get started with this.
Beyond that, you will need to think about how you actually want to execute the code from the AST form, which is common the design of both compilers and interpreters. This is generally considered the easier part however, and there are lots of general resources on compilers/interpreter out there that should provide information on this.
I haven't done an interpreter myself. Hope the following helps:)
Here's a compiler course taught at Yale using ML, which you might find useful. The lecture notes are very concise (short) and informative. You can follow the first few lecture notes and the assignments. As you know F#, you won't have problem reading ML programs.
Btw, the professor was a student of A. Appel, who is the creator of SML implementation. So from these notes, you also get the most natural way to write a compiler/interpreter in ML family language.
This is an excellent example of a complete Small Basic implementation with F# and FParsec. It includes even IL compiler. The whole code is very accessible and is accompanied by a series of blog post from the author at http://trelford.com/blog/