Try giving a --module flag to fsyacc.exe

In an MSBuild project file we use

<FsYacc Include="Parser.fsy">

<OtherFlags>--module Parser</OtherFlags>

</FsYacc>

<FsLex Include="Lexer.fsl">

<OtherFlags>--unicode</OtherFlags>

</FsLex>

Somehwere after these:

<Import Project="$(MSBuildExtensionsPath32)\FSharp\1.0\Microsoft.FSharp.Targets" Condition="!Exists('$(MSBuildBinPath)\Microsoft.Build.Tasks.v4.0.dll')" />

<Import Project="$(MSBuildExtensionsPath32)\..\Microsoft F#\v4.0\Microsoft.FSharp.Targets" Condition=" Exists('$(MSBuildBinPath)\Microsoft.Build.Tasks.v4.0.dll')" />

<Import Project="$(MSBuildExtensionsPath)\FSharp\1.0\FSharp.PowerPack.Targets" />

Apologies for responding to my own post ..

I managed to fix the problems I was having with lexing - basically by removing namespace declarations altogether and declaring each file to be a (single) module of its own name. I had not previously twigged to the fact that a module declaration at the very beginning of a file requires no = sign, nor any subsequent indentation.

However, I was then confonted with problems with parsing. I ended up working round these by manually editing the yacc output. Obviously this is far from satisfactory, but when I downloaded the source to the latest PowerPack and studing how fsYacc itself works, it seemed to me that they must have done exactly the same thing. Whilst I think this could be verified this by running the fsyaccpars.fsy through the built FsYacc.exe, I couldn't summon up the energy. The simple approach of just recompiling the PowerPack source failed due to the lack of a .snk. Is this intentional?

I could well be wrong about this - I often am! Either way, I would like to figure out how to generate a working file from a .fsy grammar file. There seems no way of preventing it from generating statements (a nowarn and a could of opens) before the included header - and therefore outside of any module or namespace.

many thanks,

gary

Have you tried the following? It is an alternate form of namespace/module declaration, which is only valid at the start of a file. I haven't tested it, but this is what the docs say.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{

module FsXml.Lex

open Microsoft.FSharp.Text.Lexing

open Microsoft.FSharp.Text.Parsing.ParseHelpers

open FsXpath

let lexeme (lexbuf : LexBuffer<char>) = new System.String(lexbuf.Lexeme)

}