F#、命名空间、模块、fs 和 fsx [英] F#, namespaces, modules, fs and fsx

问题描述

我知道其他 问题 关于 F# 中的模块和命名空间，但它们现在对我没有帮助.

I'm aware of other questions about modules and namespaces in F#, but they're not helping me right now.

我有一个项目

Utilities.fs

namespace Company.Project.Namespace
module Utilities = 
     //stuff here

Functions.fs

namespace Company.Project.Namespace
open Utilities

module Functions = 
     //stuff here

我正在尝试在 fsx 中测试它们:

And I'm trying to test them in an fsx:

#load "Utilities.fs"
#load "Functions.fs"

这给了我 error FS0039: The namespace or module 'Utilities' is not defined 当我尝试使用 Alt-Enter 将其发送到 FSI 时.

which gives me error FS0039: The namespace or module 'Utilities' is not defined when I try to send it to FSI with Alt-Enter.

我尝试在脚本文件的顶部添加相同的命名空间，但它不喜欢那样.

I've tried adding same namespace at the top of the script file, but it doesn't like that.

奇怪的是，后台编译器并没有冲我大喊大叫.

What's weird is that the background compiler doesn't shout at me.

这似乎有效，但这是正确的方法吗?

This seems to work, but is it the right approch?

#load "Utilities.fs"
open Company.Project.Namespace
#load "Functions.fs"

某处是否有参考"FSharp 项目，其中包含如何集成所有这些内容的示例:命名空间、模块、类、脚本文件、测试等?

Is there a 'reference' FSharp project somewhere, which contains examples of how to integrate all this stuff: namespaces, modules, classes, script files, tests etc.?

推荐答案

我不是 FSI 的专家，但一些实验表明命名空间仅由 #load 声明支持(不是通过典型的交互 - 通过 Alt-Enter 向 VFSI 发送命名空间声明组不起作用)，并且不同的交互贡献不同的实例".比如用代码文件

I'm not an expert with FSI, but some experimentation suggests that namespaces are only supported by #load declarations (not via typical interactions - sending a namespace declaration group to VFSI via Alt-Enter does not work), and that different interactions contribute different 'instances'. For example, with the code file

namespace Foo

type Bar() =
    member this.Qux() = printfn "hi"

namespace Other

type Whatever() = class end

namespace Foo

module M =
    let bar = new Bar()
    bar.Qux()

如果我#load它不止一次，我得到例如

if I #load it more than once I get e.g.

> [Loading C:Program.fs]
hi

namespace FSI_0002.Foo
  type Bar =
    class
      new : unit -> Bar
      member Qux : unit -> unit
    end
namespace FSI_0002.Other
  type Whatever =
    class
      new : unit -> Whatever
    end
namespace FSI_0002.Foo
  val bar : Bar

> #load @"C:Program.fs";;
> [Loading C:Program.fs]
hi

namespace FSI_0003.Foo
  type Bar =
    class
      new : unit -> Bar
      member Qux : unit -> unit
    end
namespace FSI_0003.Other
  type Whatever =
    class
      new : unit -> Whatever
    end
namespace FSI_0003.Foo
  val bar : Bar

> new Foo.Bar();;
> val it : Foo.Bar = FSI_0003.Foo.Bar

请注意，似乎 FSI_0003.Foo.Bar 隐藏了 FSI_0002 版本.

Note that it seems the FSI_0003.Foo.Bar shadowed the FSI_0002 version.

所以我在考虑 F# 规范中提到的部分

So I'm thinking the part of the F# spec that says

在命名空间声明组中，命名空间本身是隐式的如果前面有任何命名空间，则打开声明组或引用大会为此做出了贡献命名空间，例如

Within a namespace declaration group, the namespace itself is implicitly opened if any preceding namespace declaration groups or referenced assemblies contribute to this namespace, e.g.

namespace MyCompany.MyLibrary 

   module Values1 = 
      let x = 1

namespace MyCompany.MyLibrary 

   // Implicit open of MyCompany.MyLibrary bringing Values1 into scope

   module Values2 = 
      let x = Values1.x

然而这只会打开命名空间由前面的命名空间构成声明组.

However this only opens the namespace as constituted by preceding namespace declaration groups.

不与 FSI 交互，因为 FSI 对命名空间的理解有限.具体来说，我希望您的示例中的第二个#load"打开，例如FSI_000N+1 的命名空间版本，而之前的代码在 FSI_000N 中.这可能解释了为什么显式 open 交互修复它；在稍后尝试(隐式)引用它之前，您将现有的、未隐藏的 FSI_000N 内容带到顶层.

Does not interact with FSI, given FSI's limited understanding of namespaces. Specifically, I expect that the 'second #load' from your example opens e.g. FSI_000N+1's version of the namespace, whereas the prior code was in FSI_000N. Which maybe-explains why the explicit open interaction fixes it; you bring the existing, unshadowed FSI_000N stuff up to the top level before trying to (implicitly) reference it later.

这篇关于F#、命名空间、模块、fs 和 fsx的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！