.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.
2003-01-09 JJM -- Yes. It provides bi-directional communication with COM components. Tcl/Tk scripts may be evaluated from the COM side and new Tcl commands may be added via methods of COM objects. This allows for full Tcl/Tk based scripting of any application capable of using COM objects.
Please see http://www.tclbridge.com/html/CreateCommand.html and http://www.tclbridge.com/html/CreateDynamicCommand.html for more information.
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 is for all and .NET only for Microsoft.
Sean Halliday Jan 17/2003
I think some people might be missing the big picture with .NET. The .NET IL gets compiled to native code at run-time. This makes it a big win over other byte-code languages that interpret the byte code. There is also a common type system (CTS) and common runtime. This allows code that was written in various languages to all work together. I am a big fan of Tcl/Tk and have been using it for about 8 years. I am now a big fan of .NET and I hate COM and ActiveX. Don't prejudge .NET just because it is from MS. As for Tcl/Tk being a .NET language, I don't know. I think if it was taken seriously, it could be done quite well. The big question is whether the .NET framework will really catch on. Anyway, I currently have Tcl and .NET working together just fine (without the need for COM.) I just write managed C++ code to access .NET. Since unmanaged code can call managed code, the Tcl commands I add can access .NET. I have even hosted C# windows forms in a Tcl app (again without ActiveX or COM.) This is the other really big win with .NET, it is very easy to write interfaces to existing C/C++ libraries - I didn't even need a Wizard :-)
Sean brings up an interesting idea on interopability. Let Tcl be as it is with an adaptor handling the connection. But I'm wondering (don't have VC7, so I can't test), as C# is so close to the C syntax, can Tcl's generic code be compiled by C# ?? If so, could a new platform directory be made for ngws ? -- DG