This question started out from
My translating of "ML for the Working Programmer" (WorldCat) by L. C. PAULSON to F# which uses functors for the examples.
Eventual desire to translate "Purely Functional Data Structures" (WorldCat) by Chris Okasaki which uses functors.
Reading "CATEGORIES TYPES AND STRUCTURES - An Introduction to Category Theory for the working computer scientist" (WorldCat) by Andrea Asperti and Giuseppe Longo.
Not understanding it all, mostly the category theory.
SML.NET can do functors and worked with Microsoft .NET.
* See: SML.NET User Guide Section 4.8.2 Class types and functors?
I keep seeing that F# cannot do true functors because of some limitation in Microsoft .NET.
* Can ML functors be fully encoded in .NET (C#/F#)?
* Any workaround for functor?
So if SML.NET could do functors on .NET then why can't F#? What did SML.NET do that F# can't?
The more I learn about functors coming from category theory, the more I see the beauty of them and desire to have them in F#.
EDIT
In a pursuit to better understand the relation between category theory and functional programming see these Q&A at CS:StackExchange.
There's no fundamental limitation of .NET that stops functors from being implemented in F#. True, they can't be represented directly in .NET metadata, but neither can other F# language features like union types. Compilers for languages with functors (e.g., Standard ML, OCaml) have a pass called defunctorize; it works just like C++ template expansion, in that it "flattens" the functors by specializing them into normal modules.
The F# compiler could do the same thing, but you then have to ask: how will this be exposed to other .NET languages? Since functors can't be directly encoded in the .NET type system, you'd need to come up with some way to represent them; and if that representation is difficult/impossible to use from C# or VB.NET, would it still make sense to include F# functors? A non-trivial part of F#'s success comes from it's ability to easily interop (in both directions) with C# and VB.NET.
EDIT: Don't get me wrong -- I'd love to have functors in F#, they'd be really useful to handle a few cases which are currently painful and/or impossible to implement without them. I'm just pointing out that the main reason the language doesn't yet (and maybe won't ever) have functors is that the interop issue hasn't been solved; the metadata-encoding issue is actually the easy part.
EDIT 2: Code for the defunctorize pass of MLton: defunctorize.fun
Update: I had a thought about how functors actually could be expressed within the .NET type system, so I put together a little experiment. It isn't pretty, but it works -- so now we know it's at least plausible that F# could one day support functors. In practice, the complexity you see in my experimental code would all be hidden by the compiler/language. If you want to check it out: experimental-functors
Related
What would be the best .NET language for a new ISO 8583 parser, if we're talking about dev time and comprehensibility (not so much about performance)?
I'm currently mostly involved with C#, but have also worked with VB.Net, and have introductory level knowledge of functional programming (so F# is not completely out of the question).
If domain of problem is parsing finite depth textual data structures with bitmaps of fields, I'm asking which language is the best fit? (if your suggestion is Javascript or Perl I'll take a note of that too).
I know it might sound strange but I would like to know one thing in this new world where Microsoft Visual F# is getting into.
There are many application of this language, I am going to learn, regarding parsing, functional programming, structured programming... But what about artificial intelligence?
Are there any applications for Fuzzy Logic? Is F# a good language to be used for Fuzzy Logic applications?
At university we are studying Prolog and similar languages. Prolog is able to create complex query in a very plain and short expresisons (by taking advantage of predicates and facts). Is F# able to do this?
Thank you in advance.
Fuzzy Logic. F# doesn't provide any types for implementing fuzzy logic calculations out of the box, but it is certainly possible to use F# in this domain. The succinctness of F# and the ability to define custom overloaded operators should make code based on fuzzy logic quite nice. I did a quick search and discovered a few articles implementing fuzzy logic in F#:
Fuzzy Logic in F#, Example 1
FuzzyAdvisor - A Simple Fuzzy Logic Expert System in F#
Prolog is a bit different question. The power (and also the weakness) of Prolog come from the fact that it has backtracking built directly in the language. This makes it very nice for implementing search algorithms based on backtracking, but it also a limitation.
F# doesn't have any direct support for backtracking, but it is quite easy to write algorithms based on backtracking using recursion (which is the main control flow mechanism in both F# and Prolog).
Also, it is possible to implement domain specific language for logical programming in F#. This means that you'd implement something like Prolog within F# and then write your search algorithms using this mini-language in F# (possibly using other F# features as needed). You can find more information about similar problems in this question.
F# is a general purpose language with some nice language features, such as computation expression/Monad and quotation. You can assume that it has about the same power as C#.
It is not like Matlab or R, where a lot of pre-implemented libraries are built-in. If you want to implement a Fuzzy Logic library or other AI algorithms from scratch, F# is a very good language for you as its language features make life easier.
But if you just want to use a Fuzzy logic library, then using other languages or specialized systems will be more appropriate because F# or .Net in general does not have very good quality libraries in this aspect.
Good day all,
I am developing a small hobby project in OCaml. I was wondering how easy it would be to migrate it to F#. I know that F# has some features that OCaml doesn't, but I was hoping that my OCaml code would require little effort to port. I don't necessarily want to migrate, I want to retain / develop on both platforms.
Thanks in advance,
Michael
Writing cross-compiling code looks like a world of pain to me. John Whitington of Coherent PDF is the only person I know of who has tried to do this to any real degree.
I have translated a lot of OCaml code to F# (probably more than anyone else in the world) and the main problems are #light syntax, the use of any non-trivial OCaml features (objects, polymorphic variants, higher-order modules, labelled and optional arguments and so on), libraries (e.g. lablgl, lablgtk, ocamlgraph, laziness), macros (parsing, streams, pattern matching extensions) and changes in basic syntax such as array indexing. For example, I just tried to port the Almabench benchmark from OCaml to F# and it took several hours because I ended up by having to rewrite every a.[i] to an a.(i) by hand due to a multitude of bugs in the F# compiler: its OCaml compatibility mode is quite fragile.
So I would advise you to choose between the languages rather than trying to cross-compile.
You should read the final portion of the spec
Features for ML Compatibility
and be sure to grab FSharp.PowerPack.Compatibility.dll from the PowerPack for various compat libraries.
I haven't done any OCaml to F#-porting, but I know F# has been designed with OCaml compatibility in mind. As I know, F# is mostly a superset of basic OCaml.
It should support (and without #light be limited to) most OCaml keywords and have equivalents of most standard functions in the core libraries (or in the .Net framework). So I'd guess that - at least for hobby projects - porting should be actually easy.
F# doesn't have OCaml's advanced module system though, so you'll have trouble with implementing e.g. functors.
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).
What is the added value for learning F# when you are already familiar with LISP?
Static typing (with type inference)
Algebraic data types
Pattern matching
Extensible pattern matching with active patterns.
Currying (with a nice syntax)
Monadic programming, called 'workflows', provides a nice way to do asynchronous programming.
A lot of these are relatively recent developments in the programming language world. This is something you'll see in F# that you won't in Lisp, especially Common Lisp, because the F# standard is still under development. As a result, you'll find there is a quite a bit to learn. Of course things like ADTs, pattern matching, monads and currying can be built as a library in Lisp, but it's nicer to learn how to use them in a language where they are conveniently built-in.
The biggest advantage of learning F# for real-world use is its integration with .NET.
Comparing Lisp directly to F# isn't really fair, because at the end of the day with enough time you could write the same app in either language.
However, you should learn F# for the same reasons that a C# or Java developer should learn it - because it allows functional programming on the .NET platform. I'm not 100% familiar with Lisp, but I assume it has some of the same problems as OCaml in that there isn't stellar library support. How do you do Database access in Lisp? What about high-performance graphics?
If you want to learn more about 'Why .NET', check out this SO question.
If you knew F# and Lisp, you'd find this a rather strange question to ask.
As others have pointed out, Lisp is dynamically typed. More importantly, the unique feature of Lisp is that it's homoiconic: Lisp code is a fundamental Lisp data type (a list). The macro system takes advantage of that by letting you write code which executes at compile-time and modifies other code.
F# has nothing like this - it's a statically typed language which borrows a lot of ideas from ML and Haskell, and runs it on .NET
What you are asking is akin to "Why do I need to learn to use a spoon if I know how to use a fork?"
Given that LISP is dynamically typed and F# is statically typed, I find such comparisons strange.
If I were switching from Lisp to F#, it would be solely because I had a task on my hands that hugely benefitted from some .NET-only library.
But I don't, so I'm not.
Money. F# code is already more valuable than Lisp code and this gap will widen very rapidly as F# sees widespread adoption.
In other words, you have a much better chance of earning a stable income using F# than using Lisp.
Cheers,
Jon Harrop.
F# is a very different language compared to most Lisp dialects. So F# gives you a very different angle of programming - an angle that you won't learn from Lisp. Most Lisp dialects are best used for incremental, interactive development of symbolic software. At the same time most Lisp dialects are not Functional Programming Languages, but more like multi-paradigm languages - with different dialects placing different weight on supporting FPL features (free of side effects, immutable data structures, algebraic data types, ...). Thus most Lisp dialects either lack static typing or don't put much emphasis on it.
So, if you know some Lisp dialect, then learning F# can make a lot of sense. Just don't think that much of your Lisp knowledge applies to F#, since F# is a very different language. As much as an imperative programming used to C or Java needs to unlearn some ideas when learning Lisp, one also needs to unlearn Lisp habits (no types, side effects, macros, ...) when using F#. F# is also driven by Microsoft and taking advantage of the .net framework.
F# has the benefit that .NET development (in general) is very widely adopted, easily available, and more mass market.
If you want to code F#, you can get Visual Studio, which many developers will already have...as opposed to getting the LISP environment up and running.
Additionally, existing .NET developers are much more likely to look at F# than LISP, if that means anything to you.
(This is coming from a .NET developer who coded, and loved, LISP, while in college).
I'm not sure if you would? If you find F# interesting that would be a reason. If you work requires it, it would be a reason. If you think it would make you more productive or bring you added value over your current knowledge, that would be a reason.
But if you don't find F# interesting, your work doesn't require it and you don't think it would make you more productive or bring you added value, then why would you?
If the question on the other hand is what F# gives that lisp don't, then type inference, pattern matching and integration with the rest of the .NET framework should be considered.
I know this thread is old but since I stumbled on this one I just wanted to comment on my reasons. I am learning F# simply for professional opportunities since .NET carries a lot of weight in a category of companies that dominate my field. The functional paradigm has been growing in use among more quantitatively and data oriented companies and I'd like to be one of the early comers to this trend. Currently there doesn't an exist a strong functional language that fully and safely integrates with the .NET library. I actually attempted to port some .NET from Lisp code and it's really a pain b/c the FFI only supports C primitives and .NET interoperability requires an 'interface' construct and even though I know how to do this in C it's really a huge pain. It would be really, really, good if Lisp went the extra mile in it's next standard and required a c++ class (including virtual functions w/ vtables), and a C# style interface type in it's FFI. Maybe even throw in a Java interface style type too. This would allow complete interoperability with the .NET library and make Lisp a strong contender as a large-scale language. However with that said, coming from a Lisp background made learning F# rather easy. And I like how F# has gone the extra mile to provide types that you would commonly see it quantitative type work. I believe F# was created with mathematical work in mind and that in itself has value over Lisp.
One way to look at this (the original question) is to match up the language (and associated tools and platforms) to the immediate task. If the task requires an overwhelming percentage of .NET code, and it would require less shoe-horning in one language than another to meet the task head-on, then take the path of least resistance (F#). If you don't need .NET capabilities, and you're comfortable working with LISP and there's no arm-bending to move away from it, keep using it.
Not really much different from comparing a hammer with a wrench. Pick the tool that fits the job most effectively. Trying to pick a tool that's objectively "best" is nonsense. And in any case, in 20 years, all of the currently "hot" languages might be outdated anyway.