The L Programming Language or Tcl for C Programmers Oscar Bonilla, Tim Daly,Jr.,Larry McVoy BitMover, Inc. 300 Orchard City Drive,Suite 132 Campbell, CA 95008 Jeffre y Hobbs ActiveState Software Inc. 1700-409 Granville Street Vancouver,BC, Canada V6C 1T2 [email protected] ABSTRACT This paper describes a newprogramming language called L. Lisacompiled-to-byte-code language with the unusual twist that it compiles to Tcl byte codes and by doing so leverages the entire Tcl runtime. Lisdesigned to peacefully coexist with Tcl rather than replace Tcl. Lfunc- tions may call Tcl procs and vice versa. Theymay also coexist in the same source file. Lisa static weakly typed language with int, float, string, struct, array,and hash as first-class objects. The L syntax is reminiscent of C with a tinybit of C++ thrown in. The implementation consists primarily of a simple compiler that Tcl invokeswheneverL source code is encountered. The L code is parsed by a Bison-generated parser into an abstract syntax tree (AST), which is type-checked and then translated into Tcl byte code. Upon its execu- tion, L code is indistinguishable from Tcl code, which makes for easy interoperability. Lisopen source software, and it is made available under the same license as Tcl/Tk with the hope that people will find it useful and it may encourage more people to join the Tcl/Tk com- munity. -2- “It’slikeperl without the nastiest bits.” -- Donal K. Fellows (on the #tcl IRC channel) 1. Introduction conventions, current status, features we have not yet BitMoversoftware is produced using a conservative done but want to do, licensing and availability,and a development methodology.All development goes summary.There is an appendix with some small through a stringent process that relies heavily on peer working program examples. reviewand extensive regression tests to ensure quality products. 2. L overview Because of the stability requirements of our market, Lisactually a very small addition to the Tcl system. we read code much more than we write it. Spot If we divide the Tcl system into logical parts this checks indicate that we spend at least 10 times as becomes obvious: much time reading and reviewing as we do writing. Subsection Percentage of Tcl/Tk 8.5 Naturally,wetend to optimize heavily for the read path rather than the write path. Tcl parser/compiler <= 1% Lparser/compiler <= 1% Foryears we have used the Tcl/Tk system for our Tcl runtime 48% graphical user interfaces. Weperiodically consider Tk 51% the alternativesand have consistently found that short of doing native implementations, the Tcl/Tk system is The parser and compiler are quite small when com- still the best choice from a development cost point of pared to the code that implements the runtime and the view. Our estimate is that it would cost roughly six libraries (in both Tcl and L it is less than 10K lines of times as much to develop and maintain native GUIs code). Because the parser/compiler is such a small instead of using a single Tcl source base for all plat- part of the system, it is reasonable to add an alterna- forms. However, the maintenance of our Tcl source tive parser/compiler to the system and let them both base has recently become problematic because two run side by side. That is L in a nutshell. It is the things happened: small amount of effort required to leverage a large •Our Tcl source base grewpast a manageable size amount of value embodied in the runtime and (for us). libraries. •Our peer reviewsystem could not handle Tcl code. The L compiler creates an abstract syntax tree from L We hav e about 25,000 lines lines of Tcl, implement- source and compiles that to byte codes. The byte ing about a dozen graphical interfaces for browsing codes generated are standard Tcl byte codes, follow- code, checking in code, viewing changes, etc.1 Main- ing Tcl call/return conventions and using Tcl vari- taining and extending the Tcl source base has become ables. Because we are careful not to break anyTcl unmanageable, and when the reviewprocess was rules, L functions may call Tcl procs and vice versa. added to the mix, the costs became too high. This allows L to use the extensive,mature Tcl/Tk run- time and libraries unmodified. This has been a problem for us for years and we were forced to come up with a better answer.Weinv esti- 3. Unique design gated the alternativesbut in the end the Tcl runtime and the Tk widgets were too compelling. We solved As we dive deeper into the L syntax and semantics it our problems by marrying a language syntax we felt would be easy to be drawn into a discussion of whyL waswell suited for fast reviewing and understanding is better or whyTcl is better.Todosowould be to with what we feel is the best GUI toolkit and runtime miss an important point. Regardless of the merits of available today. each language, the value of L is that it demonstrates a newway to leverage and reuse existing code. With a The rest of the paper is divided into sections that dis- relatively small amount of effort, we have lev eraged cuss the following topics: an overviewofL,why the L over1.4 million lines of source making up the Tcl/Tk approach is interesting, whyother runtimes were not system plus some extensions. chosen, whynot pure Tcl, whynot native GUIs, L language details such as types, calling/return The existence of L opens the door to anynumber of domain-specific languages being added to the Tcl run- 1 This number is artificially lowbecause we have time system. been holding offonanumber of GUIs until we had a better answer.Had we not been holding back, 100,000 Forexample, consider the GDB debugger.GDB lets lines is more likely where we would be. users type C, C++, etc., at it and run the code. Doing -3- so means GDB has to provide an interpreter and a drawbacks: runtime. Rather than building one, GDB could reuse Data structures. Probably the single largest problem the ideas and code pioneered by the L effort. Having we found with Tcl was the lack of a C-style struct, awell maintained runtime with the option of creating i.e., a centralized collection of variables with annota- an arbitrary syntax to use that runtime is useful for tions indicating whytheyare there. These are com- anysort of debugger or runtime inspector.Lis just monly emulated in Tcl with associative arrays. That one example of a different syntax leveraging the isn’tgood enough because the ‘‘struct fields’’are scat- Tcl/Tk system; we are confident there will be others. tered all overthe source base rather than being in one place, laid out with types and comments. To para- 4. Alternative runtimes phrase Fred Brooks: “Show me your code and conceal Once the idea of adding a different parser/compiler to your data structures, and I shall continue to be mysti- ascripting language is understood, the question fied. Show me your data structures, and I won’tusu- becomes: whyTcl rather than some other runtime ally need your code; it’ll be obvious.”Brooks1975a such as Perl, Python, Ruby,Java, or others? We Lint. It is impossible to write a syntax checker or a looked briefly at that question. Our need was for a lint-liketool for Tcl that works 100% of the time well supported, mature runtime that supported script- unless that tool is actually running the program it is ing GUI interfaces and was extensible from C. checking. Even an interpreter-based tool would have We dismissed Java because the runtime is too large the problem that it is not practical to force the applica- and the GUI toolkits are weak, both in features and in tion through all possible code paths. It is worth not- performance. The other runtimes addressed the GUI ing that this problem is present in all dynamic lan- issues mostly by providing Tk bindings (and in some guages and object-oriented languages have the same cases Qt or Gtk bindings). Anysystem that is using problem; you can’tjust look at the code and know Tk bindings is already dragging along a Tcl inter- what it is doing. preter to run the Tk code. It seemed likeawaste to Reviewing. As mentioned previously,atBitMover have a different interpreter just for the GUIs. It has we do a lot of peer reviewaswell as other forms of also been our experience that the only way to build code reading. Forthe same reasons that it is difficult robust software systems is to have the minimum num- to write a lint-liketool for Tcl, it is difficult for a ber of ‘‘moving parts.’’ Having twointerpreters is an human to look at Tcl and understand what it is doing. unnecessary complication. The verbose style of basic operations in Tcl, e.g., But evenifthere were a good runtime with a good lset fib $i \ GUI interface, there was another requirement we felt [expr \ wasonly well addressed by Tcl. Tcl has been {[lindex $fib [expr {$i-1}]] + designed from the onset to be an extendable language. [lindex $fib [expr {$i-2}]]}] The original vision was that Tcl was glue and all the vs heavy lifting would be done by C extensions to the language. The internal Tcl code is fairly small and fib[i] = fib[i-1] + fib[i-2]; quite pleasant to use; adding extensions is straightfor- tend to obscure what is actually being said in the ward and natural. We needed to takeadvantage of code.