Back to Questions
969
views5
comments
Array slicing stops working after referencing DLL
f#

Hello everyone.
I'm currently running Visual Studio 2008 Professional with F# 2.0 installed. I'm running into a bizarre problem with array slicing. Whenever I reference another library (.dll) from my project, array slicing stops working and I get the error message:

stdin(6,1): error FS0001: This expression was expected to have type
'a [] * int
but here has type
string []

This only happens if the library being referenced was also written in F# (I tried one in C# and that didn't mess up the array slicing).

I wrote a small test library to try and narrow it down:

namespace Test

open System

type TestLibrary() =
member this.GetCOMsArray() =
[| for n in 1..16 -> sprintf "COM%d" n |]

member this.GetAll3DigitNums() =
[| for n in 100..999 -> n |]

...then I did this in F# Interactive:

Microsoft (R) F# 2.0 Interactive build 1.9.9.9
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

> let coms = [| for n in 1..16 -> sprintf "COM%d" n |];;

val coms : string [] =
[|"COM1"; "COM2"; "COM3"; "COM4"; "COM5"; "COM6"; "COM7"; "COM8"; "COM9";
"COM10"; "COM11"; "COM12"; "COM13"; "COM14"; "COM15"; "COM16"|]

> coms.[0];;
val it : string = "COM1"
> #r @"C:\Documents and Settings\de\My Documents\Visual Studio 2008\Projects\F#\TestLibrary\bin\Release\TestLibrary.dll";;

--> Referenced 'C:\Documents and Settings\de\My Documents\Visual Studio 2008\Projects\F#\TestLibrary\bin\Release\TestLibrary.dll'

> open Test;;
> let tl = new TestLibrary();;

val tl : TestLibrary

> coms.[0];;

coms.[0];;
^^^^^^^^

stdin(6,1): error FS0001: This expression was expected to have type
'a [] * int
but here has type
string []
>

As you can see, array slicing was working before I opened the Test library, but stopped working right after. This not only happens in F# Interactive - it also happens in my compiled projects as well. I'm not overriding the [] operator in any way. Is this a bug, or am I doing something wrong?

.

Here is my guess:

- a week ago you did have some crazy operator overloading in TestLibrary, and that was the last time you compiled the library in 'Release' mode

- you've change the code now to something simple, but you're in 'Debug'

- the FSI command references the stale 'Release' version and so you see this weird behavior

Just a guess.

Also, aside on terminology: "arr.[ i]" is not 'array slicing', it's just indexing. Slicing is e.g. arr.[3..6].

By on 6/23/2010 12:02 PM ()

Brian,
Thanks for the response. I meant to also include sample code to show that array slicing was also failing besides the indexing.

To answer your points, I'm not overloading any operators in any of the libraries. Haven't had to do that yet. The TestLibrary is just something I quickly wrote this morning to give a simple example that showed the failure, so I'm definitely using the latest version. I also made sure to compile it for Release.

Your comments about compiling did get me thinking, however, and one thing I do is use the --standalone flag when building to bundle all the F#-specific libraries into the DLL. So I tried rebuilding everything without that flag, and that actually fixed the array indexing/slicing problem. I then added the flag back in, and it started failing again.

So why would that cause the failure? It doesn't seem like it should...

By on 6/23/2010 2:56 PM ()

If you compile with --standalone, then you cannot reference the resulting assembly from F# code. All kinds of weird stuff happens, since there are now two copies of FSharp.Core floating around (one embedded in the referenced app, and the real one referenced by the referencing app).

It would be better if we gave a compiler diagnostic about this; I'll file a bug.

By on 6/23/2010 3:34 PM ()

Thanks. In the meantime, what would be the best way to deploy the F# libraries along with the .dll (since I'll be compiling without the --standalone switch)? I was hoping not to have to do a setup project just for one .dll, but if I have to I will.

Also, I have a WCF service that references this .dll, so is there anything special I need to do to deploy it to IIS?

By on 6/23/2010 6:12 PM ()

Well, in the absence of another solution, I've deployed FSharp.Core.dll to the IIS server along with my WCF service .dll's (compiled without the --standalone option), and this seems to have solved the problem for the moment.

By on 6/25/2010 11:18 AM ()

    Topic tags

    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