F #, przestrzenie nazw, moduły, fs i fsx

Question

Jestem świadomy otherquestions o modułach i przestrzeniach nazw w F #, ale nie pomagają mi one teraz.

Mam projekt z

Utilities.fs

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

Functions.fs

namespace Company.Project.Namespace 
open Utilities 

module Functions = 
    //stuff here 

I próbuję przetestować je w FSX :

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

co daje mi error FS0039: The namespace or module 'Utilities' is not defined kiedy próbuję wysłać go do FSI z Alt-Enter.

Próbowałem dodać tę samą przestrzeń nazw w górnej części pliku skryptu, ale to się nie podoba.

Co dziwne, kompilator tła nie krzyczy na mnie.

Wygląda na to, że działa, ale czy jest to właściwy approch?

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

Czy istnieje projekt „odniesienia” FSharp gdzieś, który zawiera przykłady, jak zintegrować wszystkie te rzeczy: nazw, moduły, klasy, pliki skryptów, testy itp?

Answer 1

Nie jestem ekspertem od FSI, ale niektóre eksperymenty sugerują, że przestrzenie nazw są obsługiwane tylko przez deklaracje #load (nie poprzez typowe interakcje - wysyłanie grupy deklaracji przestrzeni nazw do VFSI przez Alt-Enter nie działa) i że różne interakcje powodują różne "przypadki". Na przykład, w pliku kodu

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() 

gdybym #load go więcej niż raz mam np

> [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 

Należy zauważyć, że wygląda na to, że FSI_0003.Foo.Bar zasłonił wersję FSI_0002.

Więc myślę, że część F # specyfikacji, który mówi

obrębie grupy deklaracji przestrzeni nazw, sama nazw jest niejawnie otwarty czy któregokolwiek z poprzednich nazw grupy oświadczenia lub odwołuje zespoły przyczynić się do ten obszar nazw , np

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 

Jednak to tylko otwiera nazw jak utworzoną przez poprzedzający nazw grupy deklaracji.

Nie współpracuje z FSI, biorąc pod uwagę ograniczone zrozumienie przestrzeni nazw FSI. W szczególności oczekuję, że "drugi #load" z twojego przykładu zostanie otwarty np. FSI_000N+1 - wersja obszaru nazw, podczas gdy poprzedni kod był w FSI_000N.Co może - wyjaśnia, dlaczego jawna interakcja open ją naprawia; wprowadzasz istniejące, nie cieniowane obiekty do najwyższego poziomu, zanim spróbujesz (niejawnie) odwołać się do nich później.

Answer 2

Jestem stosunkowo nowy w tym też, ale to, co działa na mnie, gdy jestem testowania w pliku FSX:

#if INTERACTIVE 
#r @"C:\Program Files\FSharpPowerPack-2.0.0.0\bin\FParsec.dll" 
#r @"C:\Program Files\FSharpPowerPack-2.0.0.0\bin\FParsecCS.dll" 
#endif 

open FParsec.Primitives 
open FParsec.CharParsers 

następnie mojego kodu, który korzysta z tych bibliotek.