This project is read-only.

Introduce dialects to VB/C#

Topics: General, VB Language Design
Apr 21, 2014 at 2:13 PM
With open Roslyn, we may expect that multiple languages (specialized, test vehicles, new concepts etc) will soon appear, that will be based on C#/VB. These derived languages may differ from standard languages with different syntactic/semantic/code editor tools. Such big changes may discourage potential users from download and test these languages, if current install-with-complete-replacement scenario will be maintained. Exhibiting these new languages as new languages with new file extensions (like .vbproto1, .vbproto2014, etc) is not good idea because of VS tooling focussed on VB/C#. Better way is to introduce concept of dialects, and implement these languages with that philosophy. At beginning VB file we may specify UseDialect VB2014_SQL, and VS open this file with new compiler/code editor that support specified VB dialect (with SQL language implemented for example). Other VB files without such declaration, will be handled by default code editor/compiler or by dialect specified as default with project's settings. This way VS users can download and use multiple languages with new features/tools, without breaking their current experience. Language creators may create new languades with significant/breaking changes without worry about compatibility. This allow to faster language development.
Apr 21, 2014 at 11:55 PM
When we introduce changes to the languages, we aim to be backward compatible. That is, newer versions of the language with additional language features should continue to work with existing code. That's why you don't have to specify the language version in your program.

If you used a declaration to specify which dialect you used, your program would be broken as soon as it is no longer supported as a dialect in the product.
Apr 22, 2014 at 11:10 PM
Of course everybody expect that all RTM language version will be backward compatibile. But any Alpha/Beta/RC version language from MS, or from others providers that create incompatible languages, could fit nicely into dialects, by allow to test/use new language without drop RTM tools from VS. No one except Beta/RC to be supported for longer time, because this is short-lived version. If somone begin to use incompatible language from other vendor, then he do it on his own responsibility.
Within browsers we have DOCTYPES for different HTML dialects, and this work pretty well.
Apr 23, 2014 at 5:11 AM
Oh, I thought you were asking US to do something. Since we don't support dialects, there is nothing for us to do. But yes, you could make you own versions of the language that accept some sort of declaration up top that says what dialect it is.
Apr 28, 2014 at 9:51 PM
I like the way this is done in unix shell-scripts, with a COMMENT as the first line of the file. For example
#!/bin/bash
.......
......
This tells the system to execute it using the "bash" interpreter. I guess there could be some similar convention in .vb source files, or in .vbproj files.
May 1, 2014 at 7:36 PM
nmgafter wrote:
When we introduce changes to the languages, we aim to be backward compatible. That is, newer versions of the language with additional language features should continue to work with existing code. That's why you don't have to specify the language version in your program.
There are some language features which are very seldom useful, and more often cause what would otherwise be correct code to fail, or cause the compiler to accept rather than squawk at incorrect code. The fact that removing such features might break a few programs would be a reason for having the features be available to code that needs them, but doesn't IMHO justify code which doesn't need the features to suffer their existence.

For example, even with Option Strict On, type Object sometimes exhibits value semantics. This behavior might occasionally have some usefulness with Option Strict Off, but I can think of no case where it's helpful with Option Strict On since boxed objects can only be mutated by casting them to types which exhibit reference semantics. I'm not sure that any code which is designed for the sole purpose of testing this phenomenon would break if the behavior were eliminated in Option Strict Off, but even if there's a means by which code that needs it can have it, there should certainly be some means of eliminating it for code which neither needs nor wants it.

As another example, while porting code from VB6 might have been facilitated by allowing read-only values to be passed as ByRef parameters (passing a byref to the copy), such usage is generally a mistake except in cases where a parameter is ByRef because code was imported from VB6 where that was the default, rather than because it's supposed to have pass-by-reference semantics. While there needs to be a way by which code written for the existing behavior can continue to use it, there should also be a way by which code could request that most such substitutions should be forbidden by default for explicit or extension-method ByRef parameters. It would be helpful to also have finder-grained control, especially with value-type instance methods and properties (which receive this as a ByRef) but the legality of passing a read-only value to a ByRef in general would seem a "dialect" issue.