However, to make things more confusing, it also permits dynamically loading native Tcl libraries and interacting with them, on both Windows and Unix. Of course, this feature is actually optional at compile-time because it requires using P/Invoke.
Thanks! I just recently bought John Gough's Compiling for the .Net CLR but haven't had time to look into it. Open source resources like his Component Pascal compiler, and Eagle, seem like they'll be pretty important tools for learning this stuff.
Oh, man. It has been a long time since I messed with Tcl.
I haven't dug into the code yet, but I'm assuming "interpreter" means no DLR shenanigans or other platform-limiting stuff? (DLR-based scripting languages are no bueno on iOS, since you can't generate bytecode at runtime.)
Correct, Eagle does NOT use the DLR. In theory, it should be possible to port it to iOS.
There are a couple platform-specific portions of code; however, they are all optional and can be easily disabled at compile-time. Also, checks are performed at runtime prior to calling into those platform-specific portions of code.
The full test suite is routinely run on both Windows and Linux platforms (using Mono).
Cool. I have a special place in my heart for scripting languages due to their extreme productivity boost for shorter programs. How much faster does this run using .NET?
How much faster does what run? In terms of raw performance, Eagle is not faster than Tcl (i.e. since it's an interpreter running on a virtual machine rather than C code running much closer to the hardware).
My misunderstanding. I thought the TCL code was transpiled to .NET IL which then got JIT'd or something like that. I thought that's what IronPython did and guessed you did something similar.
I actually thought about doing this; however, I realized given the (lack of) type system in Tcl, the potential performance gains would be minimal. Also, this sort of dynamic compilation can lead to memory consumption issues that are very hard to address (i.e. due to being unable to unload the dynamically generated assemblies from the AppDomain). Additionally, it would limit the portability of the library, since some platforms do not permit JIT compilation (e.g. iOS).
Can we not just build cool things? Sorry, I could not help myself.
Fun fact: antirez of Redis fame started with an interest in Tcl, and he has written about it. He wrote his own minimalist Tcl implementation in C, despite the original being an exemplary C project (or so I have heard the Tcl codebase is still sometimes used, despite reservation about the resulting language here, as a very clean and easy learning object for teaching language/interpreter design) and I doubt none of his experiences or lessons learned bled into the uber-success that Redis now is, right?
Edit: If this subthread got you interested, antirez's other Tcl projects are worth checking out. They are listed on his page on the Tcler's wiki: https://tcl.wiki/9497. I particularly recommend https://tcl.wiki/Picol, the tiny predecessor to Jim Tcl, and https://tcl.wiki/Sugar, a macro system for Tcl 8.4+. Disclosure: I maintain a somewhat larger fork of the former.
Jim Tcl sounds really awesome. I use tcl quite a bit as the embedded scripting language in a CAE app. Things like OO with garbage collection and closures/functional primitives are probably what I miss the most from Tcl.
I've always found Tcl interesting-yet-strange, but any language that lands on the CLR gets bonus points, especially if the interop design for calling into the .NET base class libraries is clean.
Yes, Eagle supports completely self-contained deployment scenarios, including any application scripts you may need. You can end up with a single EXE, if needed.
Also, Eagle runs quite well on Mono, on both Mac OS X and Linux.
I'm not sure what you mean by "Can you run Fossil on this" since Fossil itself is written in C. However, Eagle can certainly be used with Fossil via its Tcl integration support. The Garuda package (part of Eagle) is used to load the CLR and Eagle from native Tcl.
Eagle "knows" about all the .NET primitive types, including generics, nullable value types, ByRef, multi-dimensional and nested arrays, and all delegate types. The "core marshaller" handles all translations between these types and strings. Everything is handled with full fidelity.
Sorry, that was dumb, re Fossil. I was tired and know the Sqlite/Fossil community are tight with the Tcl community (since the Fossil scripting language was once Tcl, and now I believe a derivative of Tcl now, called TH1), so I got confused with lack of coffee and just waking up.
The type situation is cool. I know little of CLR and .NET, but will definitely check out this code. This sounds wonderful, good on you and your community! Perhaps I will play.
Actually, it's not dumb at all. Eagle uses Fossil as its source repository. Further, there are several other Eagle related projects that use Fossil quite extensively, including the new Package Repository Server.
Is Tcl still used very often? The last time I looked, it was often used as a scripting language embedded into other programs, much like Lua. Is that still true?
Yes, it's still used in a variety of industries; however, given its nature, these uses are not always known.
For example, several prominent hardware companies embed Tcl in their firmware: Cisco, F5 Networks, and TiVo.
While it's true that Tcl was primarily intended to be used as an embedded scripting language, it can also be used for stand-alone application development. Also, the Tk toolkit may be used to create reasonable, cross-platform user interfaces.
It's not currently implemented; however, it could be implemented as a wrapper around WinForms (either in C# or Eagle).
Alternatively, it is possible to dynamically load and use Tcl/Tk from Eagle, including bidirectional communication with WinForms and/or WPF. This makes porting Tk applications or portions thereof relatively straightforward.
