FSI as a Service/Type Provider

[Ryan Riley]

Fahad extended the updated F# 2.0 drop to make FSI a service. (I've merged this with the latest update on http://github.com/fsharp/fsharp already.) Given the recent discoveries in type providers, I was wondering if running this under a type provider would make sense. I'm sure you can imagine the implications, but consider this a "compiler-as-a-service" option.

I'm not exactly sure what the type provider would or should return. Should it return the result of the of the evaluated code snippet? Should it load the types and modules defined in the snippet and make them available for use? The former seems very plausible. The latter seems a little less so.

Then again, the type provider is doing something similar already in providing types, so perhaps this is just a way to run and execute arbitrary code? Using this as a way to host in-app script support would be nice, if possible.

Just thinking "out loud."

[Tomas Petricek]

When thinking about "exotic" type providers, there is one that I’d really *love* to see, but I have no idea how to start about this or if that’s even possible. Anyway, the idea is to have a type provider that attaches to debugger and provides a type with access to the current state in the debugger.

 

Let’s say you’re debugging a program and hit a breakpoint:

 

 

Now, I’d like to be able to open a new F# Script file and type:

 

#r "FSharpX.TypeProviders.dll"

 

let dbg = Debugger.Current

dbg.res      // prints 10

dbg.times 3  // prints 6

 

I suppose this would have to rely on some Visual Studio API (if it’s possible), but it would be just a fantastic use and really helpful tool for debugging – compared to how difficult it is to explore F# values (i.e. lists and discriminated unions) in the watches window etc.

 

Tomas

[Huw Simpson]

And I would like to see a type provider for COM, using an IDL or .tlb file for the type information, and providing a nice natural api for use from F#. COM doesn't seem to be going away!

[Steffen Forkmann]

@Huw: Something link WinRT? ;-)

[Huw Simpson]

Yes, but for classic COM. Microsoft provides managed APIs for Office, Visual Studio and other applications but I think a type provider approach could offer a more natural feel for F#.

But I've hijacked Ryan's post for long enough now :)

On Friday, March 23, 2012 5:02:50 PM UTC+2, forki23 wrote:

@Huw: Something link WinRT? ;-)

[nicolas]

I had the same idea a few years ago., but not in the context of breakpointed execution. 

I called those "openures" in contrast to "closures"

The idea was to allow for external code to operate on the content of select variables.

That would be a strong typed version of it.