Eagle: Tcl interpreter implemented in CLR | Hacker News Reader

Eagle: Tcl interpreter implemented in CLR

eagle.to

80 pointsblacksqr33 comments

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.

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.

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

That's a what, not a why.

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.

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

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

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

This sounds real rad. I'm gonna give this a look soon. Thanks!

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.

It is an entirely new implementation.

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.

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.

This brings back memories of writing Tcl for AOLServer after listening to Phil Greenspun rave about it.

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.

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.

now imagine writing tcl commands in f#

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.

Its very widely used in EDA. Companies like Cadence, Synopsys, Mentor etc. This software is used to design the chips in cell phones etc.

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

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.

Reply on news.ycombinator.com