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.
Related
I've been reading lots on functional languages and would like to maybe play with re-writing some parts of my application in F#. Is it better to design from the outside in or the inside out?
One of the influental works on the subject of FP Why Functional Programming Matters by John Hughes can be considered as a direct answer:
Our ability to decompose
a problem into parts depends directly on our ability to glue solutions
together. To support modular programming, a language must provide good
glue. Functional programming languages provide two new kinds of glue —
higher-order functions and lazy evaluation. Using these glues one can modularize
programs in new and useful ways, and we’ve shown several examples of this.
Smaller and more general modules can be reused more widely, easing subsequent
programming. This explains why functional programs are so much smaller and
easier to write than conventional ones. It also provides a target for functional
programmers to aim at. If any part of a program is messy or complicated, the
programmer should attempt to modularize it and to generalize the parts. He or
she should expect to use higher-order functions and lazy evaluation as the tools
for doing this.
I would also recommend looking at contemporary interview with John Hughes in InfoQ.
One article that really helped me come to terms with functional programming is this one:
http://prog21.dadgum.com/23.html
It is a tutorial for how to create a Pac-Man clone using functional-programming techniques. I don't even recognize the language he used (it might have been Erlang,) but the explanation helped me understand the correct mindset which I used when rewriting one of my programs in Scheme.
I'm not an expert at all on this subject, but here is a link to an article on this subject, by 'our' very own Brian:
How does functional programming affect the structure of your code?
And some questions from SO & Programmers (where - incidentally - I suspect this question would be a better fit)
Real world pitfalls of introducing F# into a large codebase and engineering team
How to organize F# source of large project (>300 classes) in Visual Studio?
Not sure I understand what is meant by "inside out" / "outside in", but FP is most useful "in the small" -- at the function level. OO is probably still the best way to organize projects in the large. It's easiest to deal with objects that correlate with your business domain.
I guess by outside in you mean top to bottom approach and by inside out you mean from bottom to top. If this is what you mean than FP is more suited towards bottom up approach i.e inside out.
While designing FP programs think about solving the problem using:
Data Structure : What all data your application needs to handle and
which data structure is most suitable to represent that data.
Function : A function does one thing (and do it correctly).
Composition : Create new functions which achieve their goals by composing other functions using technique like higher order functions and compositions.
Other more advance and abstract FP techniques like Monads etc.
So basically you start from bottom, for each atomic problem you write a function and then as you move upward in the design you use these atomic function to create functions at higher level using composition.
Remember always think of solving problem using abstractions and composition of those abstraction rather than thinking sequentially as you would do in a imperative programming.
Just as my title . I want my VS to auto indent for me like in VBNET . Please help.
As far as I know, the F# language integration doesn't support this feature.
Also, automatic formatting is not as useful in F# as it is in Visual Basic. In VB, the formatting is not really important (so you can write code with crazy indentation and the formatter can fix it). In F#, the indenation (partly) determines what code means, so you need to write correctly indented code (although I agree that the automatic formatting could make the code more consistent).
In principle it should be possible to implement this feature as a Visual Studio plugin using the open source release of F#. There is a similar plugin that adds colors for nested expressions by Brian, so that could be used as an inspiration, but it's definitely not something I could write in the answer box :-).
Sadly, the indentation-sensitive syntax that F# inherited from languages like Haskell makes it impossible to auto-indent. This is actually my only major gripe with the F# language because, in addition to making it impossible to implement professional tools like auto-indenters, it renders programs fragile in the absence of correct indentation which means an accidental change in whitespace can silently corrupt a program and cut-and-paste (e.g. from blogs) is prone to breaking or corrupting programs. F# almost always screws up if you feed it OCaml code, partly because it cannot handle tabs.
The damn crying shame is that OCaml already got this right by providing a concise unambiguous syntax and powerful tools. For example, you can autoindent any definition by pressing ALT+Q in Emacs. This makes it much easier to manipulate OCaml code and can be an enormous time saver. I often find myself trawling through F# code trying to reindent it by hand, having to read the code in detail and understand the algorithm just to indent it is seriously frustrating. Having done this many times, I can also state quite confidently that the verbosity savings of the #light syntax are insignificant. In fact, F# is almost always more verbose than OCaml in practice.
I prefer to pour cold water all over this question. In principle, it's impossible to provide an auto-formatter for a whitespace-significant language.
(Pragmatically, you could add a few small niceties to the editor, e.g. if you type a line of code that starts with if and ends with the matching then and press enter, the editor could get smart and also insert the next indent so you don't also have to press tab. But this is a far cry from auto-formatting, which I think would be wrong-headed to even attempt.)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I would like to hear from you folks that have achieved a high-level of proficiency in F# (and also in functional programming in general too) what should be my steps from now on to become a better/professional F# programmer?
I already know much of the F# syntax and have some years of experience with C++. My goal is, as an engineer and mathematician, to design better scientific libraries (linear algebra packages, partial differential solvers, etc.).
what should be my steps from now on to
become a better/professional F#
programmer?
Keep coding everyday :)
I jumped on the F# train in Sept '07, before that I had a boatload of C# experience. It took about 3 months or so for me to stop writing code as C# with a little funnier syntax and start picking up on the right coding style :)
Tips and things that helped me:
I found that F# makes it really hard to write non-idiomatic code, really easy to write good, clean code. If you find yourself fighting the compiler, 9 times out of 10 your doing something wrong. Go back to the drawing board and try again.
The entire concept of immutability was a mystery at first, but implementing all of the data structures from Okasaki's Purely Functional Data Structures was hugely helpful.
During some slow days at work, between '08 and '09, I wrote a wikibook. I haven't looked at it in a while, but I'm sure its really bad --- but, the experience of explaining the language to others was a good jumpstart for someone like me who normally wouldn't have enough motivation to start a pet project in F# :)
Map, Fold, and Filter are your friends. Try to express algorithms in these functions rather than implementing a loop with recursion.
Non-tail recursive functions are almost always easier to read and write. See here.
Project Euler. Lots of people recommend it, I didn't find it particularly helpful at all. You might get more use from it than me if your a mathematician, however.
<3 unions! Use them!
Falling back on mutable state -- big no-no. At least for beginners. The worst beginner code is full of mutables and ref variables. Immutability is an alien concept at first, so I recommend writing fully stateless programs for a while.
Still, the best advice is just keep coding everyday.
Hope that helps!
-- Juliet
Like any other language now that you know the syntax and the basics it's time to write code and more code.
Make sure you have the core concepts of functional programming down.
Work on a large project so you also get familiar with the large and not just the small.
Write a few immutable data structures.
Work on a large project without using inheritance.
If your familiar with design patterns implement some of them in a purely functional way and notice how some of them disappear.
F# is about mixing functional and OOP styles. Once you've done a fare amount of abstraction without inheritance bring it back and start mixing the styles together. Find a balance.
Since your goal as an engineer and mathematician is to design better scientific libraries may I suggest as a learning exercise working on a video game style simulation. Something that involves physics and math but also requires control of state.
I can only agree that trying to explain functional programming to others is a great way to learn it. I spent a lot of time about thinking the structure of my F# book and I think it really helped me to understand how functional concepts relate. Even giving a talk on F# in your company or to your friends should have a similar effect.
When I started learning F#, I started working on the F# WebTools project. I think this was quite useful, because many components of the project were perfect for functional programming, so I learned many functional tricks (because they were the best way to solve the problem). The project processed source code tree of F# and translated it to JavaScript, so I was using a lots of recursive functions and discriminated unions.
The area you're working in is quite different than my, so I cannot give you any specific advice, but it is a good idea to write programs in a clear functional way - even if you think that it would look nicer if you wrote it in the C++ style. When you write it, you'll probably find some way to simplify your code.
So, I think that the tips I could give are:
Try to explain F# to others - this helps you to organize ideas in your mind
Pick good problems to start with - e.g. algorithmic problems, processing tree structures, etc.
Write as much F# as you can and don't be afraid to start with a solution that does not look perfect to you - I rewrote my first program so many times!
you very probably don't want to hear from me as I have not achieved a high level of proficiency with F#, but I have set myself the goal of getting there (much like your self).
I thought I might suggest what has turned out to be my biggest learning tool: Stubbornness.
I set my self a large-ish project (a game, just as gradbot suggests). I then decided to code using as much immutable data as possible regardless of the performance costs.
Then if I couldn't find a way to use immutable data I'd come here and ask for help.
The hoops this stubborn approach forced me to jump through has been a brilliant learning exercise, as (just as Juliet mentions) F# allows you to write really ugly C# if you let your self get lax.
Right now I have tile based 2D world and a little man who can find his way to the treasure and back home again using A* path-finding ... The only thing I mutate is the title of the window it's displayed in.
I only got serious about learning F# towards the end of July (I'd dabbled before then) and this project has taught me a huge amount, along with the help of the guys here at StackOverflow.
The other answers do a good job of suggesting ways to practice your F# writing skills, which is obviously very important. However, something which doesn't seem to have been emphasized much is reading F# code, which is just as important in my opinion. There are a lot of people doing cool stuff with F#, and one of the best ways to learn about the different corners of the language is to read about what they're doing. This will help you pick up idiomatic style and will also expose you to more design patterns, language features, and functional programming techniques than you would be likely to encounter if you were just solving a problem using F# on your own.
The F# blogs syndicated on Planet F# are a good place to start, but there are also several excellent books and presentations on the language.
This only answers part of your question, but as you talk about wanting to create libraries in F#, the F# component design guidelines just came out:
http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/manual/fsharp-component-design-guidelines.pdf
If you are interested in scientific libraries I suggest you to take a look at Jon Harrop's F# for Scientists.
Also to catter for your mathematician side I suggest you to read Doets-Van Eijck The Haskell Road to Logic, Maths and Programming, although written in Haskell, you will certainly be able to follow most of the text, and re-implementing the samples in F# could be a nice exercise.
The F# compiler appears to perform type inference in a (fairly) strict top-to-bottom, left-to-right fashion. This means you must do things like put all definitions before their use, order of file compilation is significant, and you tend to need to rearrange stuff (via |> or what have you) to avoid having explicit type annotations.
How hard is it to make this more flexible, and is that planned for a future version of F#? Obviously it can be done, since Haskell (for example) has no such limitations with equally powerful inference. Is there anything inherently different about the design or ideology of F# that is causing this?
Regarding "Haskell's equally powerful inference", I don't think Haskell has to deal with
OO-style dynamic subtyping (type classes can do some similar stuff, but type classes are easier to type/infer)
method overloading (type classes can do some similar stuff, but type classes are easier to type/infer)
That is, I think F# has to deal with some hard stuff that Haskell does not. (Almost certainly, Haskell has to deal with some hard stuff that F# does not.)
As is mentioned by other answers, most of the major .NET languages have the Visual Studio tooling as a major language design influence (see e.g. how LINQ has "from ... select" rather than the SQL-y "select... from", motivated by getting intellisense from a program prefix). Intellisense, error squiggles, and error-message comprehensibility are all tooling factors that inform the F# design.
It may well be possible to do better and infer more (without sacrificing on other experiences), but I don't think it's among our high priorities for future versions of the language. (The Haskellers may see F# type inference as somewhat weak, but they are probably outnumbered by the C#ers who see F# type inference as very strong. :) )
It might also be hard to extend the type inference in a non-breaking fashion; it is ok to change illegal programs into legal ones in a future version, but you have to be very careful to ensure previously-legal programs do not change semantics under new inference rules, and name resolution (an awful nightmare in every language) is likely to interact with type-inference-changes in surprising ways.
I think that the algorithm used by F# has the benefit that it is easy to (at least roughly) explain how it works, so once you understand it, you can have some expectations about the result.
The algorithm will always have some limitations. Currently, it is quite easy to understand them. For more complicated algorithms, this could be difficult. For example, I think you could run into situations where you think that the algorithm should be able to deduce something - but if it was general enough to cover the case, it would be non-decidable (e.g. could keep looping forever).
Another thought on this is that checking the code from the top to the bottom corresponds to how we read code (at least sometimes). So, maybe the fact that we tend to write the code in a way that enables type-inference also makes the code more readable for people...
F# uses one pass compilation such that
you can only reference types or
functions which have been defined
either earlier in the file you're
currently in or appear in a file which
is specified earlier in the
compilation order.
I recently asked Don Syme about making
multiple source passes to improve the
type inference process. His reply was
"Yes, it’s possible to do multi-pass
type inference. There are also
single-pass variations that generate a
finite set of constraints.
However these approaches tend to give
bad error messages and poor
intellisense results in a visual
editor."
http://www.markhneedham.com/blog/2009/05/02/f-stuff-i-get-confused-about/#comment-16153
The short answer is that F# is based on the tradition of SML and OCaml, whereas Haskell comes from a slightly different world of Miranda, Gofer, and the like. The differences in historical tradition are subtle, but pervasive. This distinction is paralleled in other modern languages too, such as the ML-like Coq which has the same ordering restrictions vs the Haskell-like Agda which doesn't.
This difference is related to lazy vs strict evaluation. The Haskell side of the universe believes in laziness, and once you already believe in laziness the idea of adding laziness to things like type inference is a no-brainer. Whereas in the ML side of the universe whenever laziness or mutual recursion is necessary it must be explicitly noted by the use of keywords like with, and, rec, etc. I prefer the Haskell approach because it results in less boilerplate code, but there are a lot of folks who think it's better to make these things explicit.
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/