Roslyn CTP Introduces Interactive Code for C#

Roslyn CTP Introduces Interactive Code for C#

  • Comments 2

 

There's been a lot of posts on using the Roslyn CTP APIs for syntax trees, semantic binding, and IDE smart editor features. The Roslyn CTP also introduces a set of features for C# we refer to as "Interactive". These features won't be new to VB, but we plan to bring the same feature set to VB. Interactive features comprise three goals:

· Read-eval-print loop (long known as a REPL) -- to support exploring code, learning about APIs, and iterative development

· Keep simple programs simple -- just write some top-level variable declarations, statements, and function declarations, then run the code as a text-based asset without needing a solution, project, class, Main, etc.

· Roslyn Scripting APIs -- to support .NET apps hosting a C# engine to execute snippets or files of code to script the application

This post talks about the Interactive features in the Roslyn CTP, which is only supported for C# right now, but we are working on VB support for a future release.

Interactive code is a set of language and tooling features that enable customers to interactively explore and discover C# and VB readily. You do not have to create a solution, then a project, then a class, then a Main method and finally then get to write the few lines you care about. Users can open a tool window in VS and start typing code snippets to see what they do. You can build up execution context cumulatively by defining variables and functions, executing statement, defining types, and building up data structures. You can also seed the REPL's execution context from a project so that you can explore instantiating types from the project and trying out new snippets of code or develop a new function or integrity check on the data structures used in the project. This sort of development has been a hallmark of dynamic languages for decades and considered to be one of the most productive features related to dynamic languages.

Some getting started walkthroughs:

Executing Code in the Interactive Window

Seeding the Interactive Window from a WPF Project

For a quick example, using View->Other Windows->C# Interactive and starting to type a reference, you get completion:

clip_image002

After finishing the previous input and hitting enter to execute it, if you start to type MessageBox, you get a quick fix for inserting the 'using' and then completion to help with enter a call to Show().

clip_image004

When using the REPL to iteratively develop code, you may start with simple expression or statement snippets of code. You might be just checking how to call a .NET function correctly, or making a change to live code and data structures, then writing a snippet to check whether the change occurred as expected. You might build up helper functions that, for example, either help you recreate execution context for experimenting in another REPL session or help you repeat integrity checks as you experiment with an algorithm. You can save helper code away in .csx files or in your project for later evaluation and use in the REPL. Your code snippets might grow into a little program or utility that you want to run now and then, which you can save in a .csx file. You can #load .csx files in the REPL to re-execute the same code at a later time.

An important aspect of the Interactive feature set is enabling you to keep simple programs simple. If you have a quick, one-off task that just needs, say, 10-20 lines of code to open a file, manipulate some data, or test some code, you can open a .csx file and write the code you need. Then run the code with csi.exe. You do not have to jump through the VS ceremonial hoops to create a program, compile it, then execute the resulting .exe. By default, csi.exe uses the same references and 'using's that a console application uses, but you can use #r to add other references in your script file. A script file is a self-contained simple program that may have started as little snippets of code in the REPL. When you invoke csi.exe, you can pass multiple .csx files (and even .cs files) on the command line which is useful if you have a library of top-level functions you commonly use with different main scripts that use the library. The whole idea is to let you work in a simple way when simple text-based code assets are easy to manage or execute as part of a build script, file utility, etc.

Lastly, with the ability to execute snippets of code and cumulatively build up execution context, it is very natural to want to host the C# execution engine as a way to enable scripting of your .NET applications. You can then take snippets of code or files from users and execute them in a context where free identifiers are bound to public members on a host object model instance. The host application can decide what to expose to user script code for controlling the application, adding commands, or hooking events.

Scripting walkthroughs:

Introduction to Scripting

Scripting a Paint-like Application

You can download the “Roslyn” CTP and try it out today!  The REPL installs as a new tool window in VS 2010.

Leave a Comment
  • Please add 3 and 5 and type the answer here:
  • Post
  • How is Reflection.Emit different from the "scripting" you are mentioning?

  • @Lior There are a few differences.  First, if you use ref.emit, you must know IL and construct code at a lower level and in a more complicated way, even if you use LCG and don't have to emit assemblies, types, etc.  With the Roslyn Scripting APIs, you can simply execute snippets of code, or you can use compilation methods that create delegates from strings of source code or create class instances from strings of source code.  The compilation methods let you create code that compiles once for repeated execution, like ref.emit, but at a higher level, with more manageable/readable code.

    Another reason the Roslyn Scripting APIs can be more useful is if your goal is to easily open your application to scripting for your users.  You can take script files or snippets of code inputs and trivially execute them or compile them for repeated use.  The code can execute in a context where free identifiers bind to public members on a host supplied object so that the script code can call on your host applicaton to get at services or modify the behavior of the application.  Enabling users to work with these text-based assets can be a much better experience for them than their having to create VS solutions and projects to build DLLs against an API you have, then announce the DLLs to you for you to load, and so on.

    Another difference, if you squint a little :-), is that you can easily load new code to update or replace definitions with the Roslyn Scripting API.  If a user has a business rule or a custom command implementation that needs to be updated while the app is running, you can just re-execute their code in a scripting Session, and the later, more recent definitions of functions and so on hide older definiitions.  Of course, with ref.emit, if you're holding onto some delegate or ref'ed code, you can always change your storage to point to new code you generated, but 1) the experience for the user is better and 2) it may be easiest for the host to just re-execute code in a single scripting method call than to get a rule form the user and transform that to IL.

    Cheers,

    Bill

Page 1 of 1 (2 items)