Compartir a través de


Power1: REPL, and VBScript.NET

[This post is part of a series, "wish-list for future versions of VB"]

[The first set of ideas I called "Core Ideas" because they fill in missing parts VB's current code feature set. This next set I call "Power Ideas" because they open up new ways of programming.] 

 

IDEA: VBScript.NET. We should allow programs to simply have Subs, Functions, statements and even expressions at the top level in the code. (All statements would be placed in an implicit Sub Main. All subs and functions would be placed in an implicit Module MainModule. All modules would be placed in an implicit Namespace MainNamespace.) We should also have a notepad-like editor, with none of the VS features like debugger or project system: all it has is a plain old editor window with intellisense. And we should have "vbcrun.exe" which compiles-then-executes a VBScript.NET file. We should have a wider default set of implicit "Imports" statements for such programs. We should also repurpose the old VB6 "Print" command to be like Console.WriteLine. We should allow "#!..." at the top of these files, for unix compatibility.

IDEA: a "REPL" window inside Visual Studio. You should be able to select an expression, statement or subs/function, press Shift+Enter, and have the code execute in a "REPL window". You should also be able to type expressions, statements or subs/functions inside this REPL window to have them execute, and there should be an easy way to select/copy what you've written to paste back it into your main code (or to create a "VBScript.NET" script-file from it). This would be very similar to the REPL experience that most development environments have for dynamic languages like Python and Ruby.

 

SCENARIO: You have an application and want to embed a scripting language inside it. You want to be able to drop an instance of the "code-editor-with-intellisense" into you application. You want users to be able to write simple scripts inside these code windows, without needing classes or modules or subs.

SCENARIO: You want to explore as you code. The easiest way to do that is with a REPL window, where you have live objects, and you can experiment with lines of code until they get it right.

SCENARIO: You want to update your old VBScript files into something that can use the full .NET library (rather than just COM objects), and that's more modern.

SCENARIO: You want part of your application to be an "enhanced configuration text file" that your end-users can edit on their own machine in notepad, without a full heavyweight VS IDE.

SCENARIO: You are a novice user who wants to write some code. You don't know what a Namespace or Module or Sub or Imports is, and you don't care. You just want to write some code that does something. Note: with the above idea, the following would be perfectly valid!

10: Print("hello world")

20: GoTo 10

 

Provisional evaluation from VB team: This is a decent idea, one that's worth considering with the other decent ideas.

Comments

  • Anonymous
    February 01, 2010
    Why using MainNamespase and not leave the code namespace-less? What about inferring namespace from file name? In case global- (namespace-) level methods and fields will be allowed in VB then there is no need even for module :-). Just an idea