Author of Eagle here, happy to answer any questions people might have.

What was the problem you faced for this solution ?

That there was no Tcl implementation for the CLR?

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?

http://antirez.com/articoli/tclmisunderstood.html

https://github.com/antirez/jim

Though the contents of https://github.com/antirez/jim dates from 2009, Jim Tcl is actively maintained. You'll find the official GitHub mirror at https://github.com/msteveb/jimtcl.

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.

The original impetus for the project was to create a simple, self-contained Tcl interpreter in managed code.

Why does the copyright go from 2007-2012? Is the project still active? Lots of users?

It's quite active. The most recent release was October 1st (one week ago).

Updating the copyright date is not super important, due to how the copyright laws are written; however, I'll probably update it again eventually.

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.

What are some of your favorite reference materials for a compiler or interpreter writer interested in targeting the CLR?

Here are a few in no particular order:

1. Expert .NET 2.0 IL Assembler (ISBN 1590596463)

2. Advanced Windows Debugging (ISBN 0321374460)

3. Advanced .NET Debugging (ISBN 0321578899)

4. .NET Framework reference source code (https://referencesource.microsoft.com/)

5. CoreCLR source code (https://github.com/dotnet/coreclr)

6. MSDN documentation (it's not perfect, but it's not all bad)

Before CoreCLR was open source, I had to rely on Shared Source Common Language Infrastructure (https://en.wikipedia.org/wiki/Shared_Source_Common_Language_...).

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).

Does eagle still use libtcl.so/.shlib/.dylib/.dll ? Or is it an entirely new implementation. I know at one point you could use libtcl.

A few questions:

- Can you do Starkits!? With .NET and the CLR, pre-Core (since I see this goes back to 2012), that would be interesting?

- Can you run Fossil on this?

- How does type ellision work (or rather how do you handle moving between CLR/.NET primitives into a very different or minimalist Tcl type system)?

Thanks for the cool work. Sorry so many questions but that is what popped into my head!

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.

https://www.fossil-scm.org/index.html/doc/trunk/www/th1.md

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.

How about Tk? Is it or will it be implemented?

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?