When it comes to parsing, OCaml has integrated cross-platform support for ocamllex, ocamlyacc and a bewildering array of advanced functionality and tools. In contrast, F# has only a partial reimplementation of ocamllex and no integrated build system or feature-complete editor on any platform and far fewer tools and libraries.

This is such a hindrance that I strongly advise you to stick with OCaml for such development until F# provides a build system and editor that handle fsl and fsy files.

If you just want to port an existing code base and not develop it then this should be feasible. You should check that the required functionality is available in F# before starting a port though. In particular, make sure the lexer doesn't use the "as" construct that is not yet implemented in fslex.

Drop me a line if you need more specific advice.

By on 9/25/2007 10:09 PM ()

I suggest using dummy Makefile projects that call MSBuild to drive the build of such an F# solution. Customizing MSBuild to call .EXE's as part of the build process is easy (just follow the MSBuild samples).

Essentially you shouldn't aim for the "perfect" IDE development experience for projects that include FSY and FSL files. Just use command-line driven or Makefile-driven builds for these solutions and use the IDE for editing.

Kind regards

Don

By on 9/26/2007 12:24 AM ()

Don,

I'm curious, are there any plans to extend fslex in the future?

By the way, it would be really good if there at least was some basic sytax highlighting for fsl and fsy files (not the realtime type checking provided for normal F# sources).

Best regards,
Stephan

By on 9/26/2007 3:40 AM ()

The FSharp.PowerPack.dll now includes msbuild tasks for fslex and fsyacc. At this point, there is no VS IDE support for adding lex and yacc files to the .fsproj file. However, the edits can be done manually and then builds will work as required. The following .fsproj shows the additions which are needed. Note, build tasks for the lex and yacc files are added. The generated source files are also added.

<?xml version="1.0" encoding="utf-8"?>
[link:schemas.microsoft.com]</A>"> <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration> AnyCPU 8.0.30703 <SchemaVersion>2.0</SchemaVersion> {fedb485b-cbdf-440a-ba98-1d8ed2d02704} <OutputType>Exe</OutputType> <RootNamespace>TestA1</RootNamespace> <AssemblyName>TestA1</AssemblyName> <TargetFrameworkVersion>v3.5</TargetFrameworkVersion> <FileAlignment>512</FileAlignment> <Name>TestA1</Name> <DebugSymbols>true</DebugSymbols> <DebugType>full</DebugType> <Optimize>false</Optimize> <OutputPath>bin\Debug\</OutputPath> <DefineConstants>DEBUG;TRACE</DefineConstants> <ErrorReport>prompt</ErrorReport> <WarningLevel>4</WarningLevel> <DebugType>pdbonly</DebugType> <Optimize>true</Optimize> <OutputPath>bin\Release\</OutputPath> <DefineConstants>TRACE</DefineConstants> <ErrorReport>prompt</ErrorReport> <WarningLevel>4</WarningLevel> <ItemGroup> <FsLex Include="lex.fsl" /> <FsYacc Include="pars.fsy" /> <Compile Include="ast.fs" /> <Compile Include="interp.fs" /> <Compile Include="pars.fsi" /> <Compile Include="pars.fs" /> <Compile Include="lex.fs" /> <Compile Include="main.fs" /> </ItemGroup> <ItemGroup> <Reference Include="FSharp.PowerPack, Version=1.9.6.2, Culture=neutral, PublicKeyToken=a19089b1c74d0809"> <Name>FSharp.PowerPack</Name> <AssemblyName>FSharp.PowerPack.dll</AssemblyName> </Reference> <Reference Include="System" /> <Reference Include="System.Core"> <RequiredTargetFramework>3.5</RequiredTargetFramework> </Reference> </ItemGroup> <Import Project="$(MSBuildExtensionsPath)\FSharp\1.0\Microsoft.FSharp.Targets" /> <Import Project="$(MSBuildExtensionsPath)\FSharp\1.0\FSharp.PowerPack.Targets" /> <!-- To modify your build process, add your task inside one of the targets below and uncomment it. Other similar extension points exist, see Microsoft.Common.targets. <Target Name="BeforeBuild"> </Target> <Target Name="AfterBuild"> </Target> -->

By on 11/13/2008 8:54 AM ()

RE: Files in libraries or multiple-file applications must begin with a namespace or module declaration, e.g. 'namespace SomeNamespace.SubNamespace' or 'module SomeNamespace.SomeModule'

F# 2.0 requires source.fs files to start with a module (or namespace) declaration. The fsyacc generated files need to include a "module Name" declaration. On the command line, fsyacc accepts a "--module Pars" option. Within a project.fsproj file, the module name can be be set on the FsYacc build task (e.g. edit manually), as follows:

<FsYacc Include="pars.mly">


<Module>Pars</Module>


</FsYacc>


For fslex, the "module Lex" declaration can be added to the lex.fsl file.

By on 5/26/2010 11:33 AM ()

p.s. Since posting the sample.fsproj, MSBuildExtensionsPath has become MSBuildExtensionsPath32.

By on 5/26/2010 11:35 AM ()

p.s. if you need to pass options to the lexer, e.g. to have a unicode lexer then

<FsLex Include=\"Lexer.fsl\">

<OtherFlags>--unicode</OtherFlags>

</FsLex>

By on 8/19/2010 6:39 AM ()

For the moment the visual studio intergration is not that fully featured so you will have to work with command-line commands. I think the normal way to do this is produce a batch file that compiles you fsy and fsl files into fs files and add these resulting files into the project. Unfortunatly you have to remember to manually run this file everytime you change an fsl or fsy definition.

The F# team have been saying that they will be improving the visual studio intergration for sometime now, and from what I hear work on this will probably be kicking off soon, although don't except results too soon as intergation into VS is very time consuming.

By on 9/18/2007 12:35 AM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper