本文介绍了F#,名称空间,模块,fs和fsx的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我知道其他 ,但它们目前对我没有帮助

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"

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

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

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的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-09 13:15