.NET (pronounced "dot-net") is a marketing term from Microsoft. There are at least four things that go by that name:
The .NET Framework is a layer on top of Win32. Some of its main features are the use of byte code (intermediate language, IL), programming language independence and language cooperation, a common runtime library for all languages (CLR), the new language C# and a sandbox environment with code verification ("managed code").
Microsoft has submitted core parts of the framework to the ECMA for standardization, and the ECMA has basically accepted the submission and started a workgroup for this. An interesting part of the discussion is a call for scripting access to .NET [L1 ]. The ECMA thinks of ECMAScript (JavaScript) here, but Tcl could be used in this place as well. The standardization efforts allow reimplementation on other platforms and Mono http://www.go-mono.com/ is such an effort.
Tcl and Tk could be ported to use the framework instead of the OS API. This would gain us even more interoperability (although we already have that through COM, as cooperation with COM is built into .NET). It would also allow Tcl and Tk to run in a "managed" environment, i.e. Tcl and Tk could be "trusted" in the Microsoft sense of the word.
The .NET Framework including the C# compiler can be downloaded as a preview from [L2 ].
[Who wrote this page? Nice work!]
That would be me. Thanks ;-) BR
TCLBridge allows full access to Tcl/Tk from all .NET languages.
That's through COM right? We have a number of packages referenced on the COM page that could help there.
06-Jan-2003: DKF - Note that porting to the IP/CLR is in effect equivalent to porting to Java or Parrot; you're really forced to write a Tcl parser in the target language and then produce an implementation of all (well, a useful subset in the first instance) the commands in the target language too. The key problem is that the current Tcl bytecodes are defined at a level that is meaningful to Tcl, not at a level that virtually any other bytecode operates at; very few bytecodes have an opcode for "increment-hash-entry-and-fire-attached-traces"! Given that, you're either just producing another language reimplementation (like Jacl) or you're taking on the hard task of defining how to go from Tcl to the fairly-common low-level register-based bytecode engines that so many other languages use. Which would be nice and useful, but is a really huge (and definitely complex and deep) task...
CL follows up: perhaps readers are wondering what's wrong with Donal; hasn't Microsoft emphasized that .NET is "multi-lingual" and "standards-based" and so on? Yes, that's how Microsoft markets .NET. Keep in mind that Microsoft feels no obligation to link its marketing to any particular engineering reality. Developers can, in principle, use any language for their .NET work. The reality is quite a bit different, Microsoft collectively knows this, but feels no urgency to correct the confusion.
BR As I see it the major problem is that Tcl is interpreted (bytescodes are mostly a compile-time feature) while the language portability features of .NET seem to be targeted at (limited to?) compiled languages only. That's why I found the scripting aspect interesting, as ECMAScript/JavaScript also is an interpreted language with facilities like eval.
TAC Tcl runs best under its own TVM (Tcl Virtual machine ;-) The problem with generic (or multi-lingual) virtual machines (byte-code interpreters) is that they provide yet another abstraction above the CPU's machine code (which may not be geared toward your favorite language's semantics anyway). Forth runs fastest on Forth chips (where the machine code and possibly the microcode/wiring is optimized toward running Forth). Sorry, I'm digressing... But anyway, Java runs best under the JVM. In the end, you want your bytecode to match the semantics of your language. I would be interested in finding a language built on top of the Java Virtual Machine (JVM) that runs faster than Java. The idiosyncracies of common .NET languages (C#) set the bytecode for .NET. You can get other languages to play (like Tcl), but be prepared for complex semantic mappings.
Jeffrey Hobbs just had this to say on the very topic on comp.lang.tcl:
From: Jeffrey Hobbs <[email protected]> Subject: Re: TCL/TK .NET Newsgroups: comp.lang.tcl Date: Tue, 07 Jan 2003 03:32:10 GMT Organization: ActiveState [...] Tk does not become any more x-platform than it currently is by having an IL implementation of Tcl. While this may be interesting in the research sense now, I'm not sure that there is much practical value. The .NET CIL is not well suited for dynamic languages, but there is also no limitation in using the current Tcl binaries on Microsoft's .NET OSes, as .NET is (currently) just an adjunct to the rest of the system. I'm not against seeing such an implementation, but I do try and understand the motivation behind seeking way (and trying to make sure people aren't misled by MS's misleading marketing mumbo-jumbo).
ulis, 2002-01-07
Does not Tcl be already running under all Windows? What is the interest of having Tcl included in the .NET platform?
My understanding is that Tcl if for all and .NET only for Microsoft.