I'm trying to make an example I've found on the net work. It's a 3D fractal in F#. Here it is: http://tomasp.net/blog/infinite-cheese.aspx. The source code is available for download at the end of the article. The article and the sample were written in 2007, so I think the code is just slightly obsolete. There is one block of code that causes error and the code won't compile:
// Returns a cube with filtered sides
let private get_cube(incl_sides) =
[ for (side,trigs) in cube
when Set.mem side incl_sides
->> trigs ]
The when keyword is underlined, and the error message goes as follows:
Unexpected keyword 'when' in expression. Expected '->' or other token.
I can't figure out what's wrong with this. In an attempt to understand the code better, I searched the langauge specs. As far as I know, there is nothing about the Set.mem function or the ->> operator. Do you have any idea what could be wrong?
Try
[for (side, trigs) in cube do
if Set.contains side incl_sides then
yield! trigs]
The language has undergone a lot of changes since that code was written. In particular, the ->> operator has been replaced by yield!, Set.mem has been renamed to the more descriptive Set.contains, and comprehensions now use if ... then instead of when.
Yes, the version of the source code that is linked from the blog post is a bit old. You can find the latest (updated) version in the F# samples project on CodePlex. I think there may be some other changes, so it is best to get the version from CodePlex. (It includes FractalSimple.fs which is simpler version and Fractal.fs which also removes cube sides that are not visible).
The project contains standard Visual Studio 2008/2010 .fsproj project. The original version on the blog was written using F# CTP (from VS 2005 times) which had a completely different Visual Studio integration and used an obsolete .fsharpp project format (before MSBUILD format existed).
The when and ->> constructs have been used as a lightweight syntax for writing queries, but are now deprecated, to keep the syntax inside comprehensions consistent with the rest of the language. As kvb points out, you can use ordinary if .. then and the only non-standard thing is yield!, which means return all elements of the given sequence.
Related
Can't build GrainLib (only interfaces) with Microsoft.Orleans.CodeGenerator.MSBuild 3.0.0 package
error:
Exc level 0: System.NotSupportedException: Projects of type .fsproj are not supported.
Is there workaround?
Upd
After Arshia001 explanation i return to finding errors in F# silo configuration and solved my problems by applying WithCodeGeneration instead WithReference and applying it for every assembly.
.ConfigureApplicationParts(fun parts ->
parts.AddApplicationPart((typeof<IMyGrain>).Assembly)
.WithCodeGeneration()
.AddApplicationPart((typeof<MyGrain>).Assembly)
.WithCodeGeneration() |> ignore)
it seems there are lot of issues with orleans documentation and examples.
Unfortunately, no. I once started a discussion around adding first class F# support to Orleans, but it died down pretty quickly since nobody else seemed to be interested at the time.
You can always use runtime serializer generation. They do have an official F# sample too.
It only recognizes top-level non-function value declarations.
e.g. let a = 2
and doesn't produce documentation for functions or type definitions.
I've checked the xml documentation file and it has all the /// comments I put in the source, but none of them (except for the top level values) show up in the resulting html.
Yes, using C#-centric tools for F# documentation generation is usually pretty horrible. We started an alternative project a while ago, but it is not yet as mature as SandCastle: http://bitbucket.org/IntelliFactory/if-doc
I want to make my Application configuration as F# file wich will be compiled to dll. (like XMonad configuration with xmonad.hs on haskell). I found it more interesting and just better way then using XML serialization.
So is there any way how can I compile single file (or more) to Library with some configuration like
module RNExcel.Repository
open RNExcel.Model
type ExpenseReportRepository() =
member x.GetAll() =
seq{ yield {Name="User1"
Role="someRole"
Password = "123321"
ExpenseLineItems =
[{ExpenseType="Item1"
ExpenseAmount="50"};
{ExpenseType="Item2"
ExpenseAmount="50"}]}
yield {Name="User2"
Role="Estimator"
Password = "123123"
ExpenseLineItems =
[{ExpenseType="Item1"
ExpenseAmount="50"};
{ExpenseType="Item2"
ExpenseAmount="125"}]} }
my idea was to run shell .... and msbuild the project , but I don't think it will works for every user with .net 4
Check out the F# Power Pack, specifically the FSharp.CodeDom library. You can use this library to compile F# code at run-time and, with a little Reflection thrown in, can likely achieve your goal of code-as-configuration with minimal fuss.
I think that using CodeDOM provider from the PowerPack as Ben suggested is a way to go. I'd just like to add a few things (and it didn't fit into the comment box).
To parse and compile the F# code with the configuration, you need just to compile the source file that the users write using F# PowerPack. The compilation part of PowerPack is complete and works just fine. It invokes the F# compiler under the cover and gives you the compiled assembly back. The only problem is that the users of your application will need to have F# compiler installed (and not just the redist).
The incomplete part of F# CodeDOM provider is generating F# code from CodeDOM trees (because the trees were not designed to support F#), but that's not needed in this case.
Could anyone explain how to work WebSharper translator in conjunction with the F#?
Is it translate F# code to JS itself or using F# compiler for it?
In second case, what F# compiler are doing when finds [] attribute in source? Does compiler generate functions in any case and in runtime construct JS as reflection from compiled bytecode or there something other?
I develop WebSharper. Good question!
Roughly the compilation looks like this:
a.dll: a.fs b.fs c.fs
fsc ...
a.dll.js: a.dll
WebSharper.exe ..
When functions are annotated with [<JavaScript>], which is an alias for [<ReflectedDefinition>], the F# compiler does not only compile these functions to .NET IL, but also stores the representation of their syntax in the DLL metadata. This representation has type Quotations.Expr and can be recovered by reflection. Have a look at Quotations.DerivedPatterns.MethodWithReflectedDefinition.
WebSharper is therefore a source to source translator, and it is pretty direct (preserves lambdas, for example). In WebSharper 2.0 we have an intermediate Scheme-like language, but that is only there to help optimize the generated code.
I am using D2007 and am trying to document my source code, using the HelpInsight feature (provided since D2005). I am mainly interested in getting the HelpInsight tool-tips working. From various Web-surfing and experimentation I have found the following:
Using the triple slash (///) comment style works more often than the other documented comment styles. i.e.: {*! comment *} and {! comment }
The comments must precede the declaration that they are for. For most cases this will mean placing them in the interface section of the code. (The obvious exception is for types and functions that are not accessible from outside the current unit and are therefore declared in the implementation block.)
The first comment cannot be for a function. (i.e. it must be for a type - or at least it appears the parser must have seen the "type" keyword before the HelpInsight feature works)
Despite following these "rules", sometimes the Help-insight just doesn't find the comments I've written. One file does not produce the correct HelpInsight tool-tips, but if I include this file in a different dummy project, it works properly.
Does anyone have any other pointers / tricks for getting HelpInsight to work?
I have discovered another caveat (which in my case was what was "wrong")
It appears that the unit with the HelpInsight comments must be explicitly added to the project. It is not sufficient to simply have the unit in a path that is searched when compiling the project.
In other words, the unit must be included in the Project's .dpr / .dproj file. (Using the Project | "Add to Project" menu option)