---- START OF '''Tackle Programming Language Specification - Version 1 Draft'''. (as at 25 April 2004) ---- Peter Newman 25 April 2004 '''INTRODUCTION''' The Programming Language '''Tacke''' is an idea that arose from the April 2004 discussion on [Tcl Common library]. The idea of a ''Tcl Standard Library'' was floated, and generated a lot of interest. But there were so many ideas, so many issues! Lots of people want a ''Tcl Standard Library''. But there were many different ideas as to what that actually was. During that discussion, I realised that though Tcl is great, there are still lots of outstanding issues that haven't been resolved. For example:- * The lack of a '''standard distribution system''' - like Perl's CPAN and RPM. * The '''Tiny/Minimal Core''' versus '''Batteries Included Core''' issue. We seem to have a compromise solution at the moment, that neither side is entirely happy with. * The '''stagnation''' of certain aspects of Tcl - like skinning/theming of the core widgets, for example. * The '''poor documentation''' of many of the core commands, widgets and concepts. * Outstanding issues regarding TEA and CVS and how to create packages and enhancements to Tcl. In other words, the '''architecture''' and '''mechanics''' of how one goes about adding extensions to Tcl. * The continual talk about/work on '''megawidgets''' and ''MegaWidget Librarys''. * The continual calls for some '''object-oriented''' extension to be included in the core - and the debate about which one. * And there may well be many more. If there is, just let me know. These issues seem to have been discussed/debated for many years. But progress seems either painfully slow or non-existent. But what struck me about the debate in [Tcl Common Library] was that though these issues are always thought of as separate and un-related - they are in fact all connected (with perhaps a few exceptions). And that the reason there seems to be little progress in resolving them, is because you can't (in most cases,) do this - without changing other aspects of Tcl. And the changes required are in most cases so major, that hey... it's just not happening. Hence the lack of progress. But it also occured to me that these issues could easily be resolved - to the satisfaction of all parties - no matter what their position on any given matter - if, instead of thinking of and implementing Tcl as:- * A "core" of script level commands - burnt into Tclsh and Wish - with optional packages that may be added to extend the "core" functionality provided, we re-designed Tcl as:- * A "Standard Library" of script level commands and packages - where EVERYTHING - including the parser, the interpreter, and the current "core" level commands - is/are an optional and stand-alone extension. This needs clarification, and will get it below. But it's basically the motivation behind Tackle. ---- '''BUT WHY A NEW PROGRAMMING LANGUAGE?''' Quite obviously you can't just ''re-design Tcl'' at the drop of a hat. So I though a better way was to define a new programming language '''Tackle''' - which was what the re-designed Tcl would look like. Then those that are interested can either evolve Tcl into Tackle - or keep the two separate - as they see fit. ---- '''THE TACKLE PROGRAMMING LANGUAGE''' Tackle is a new programming language. It's a '''superset of Tcl'''. In other words, Tcl is Tackle - with some restrictions (listed below,) applied. Or put another way. Tackle is what Tcl could/would be - if those restrictions were removed. ---- '''WHY TACKLE?''' Well... * Tcl -> Tickle * Tickle -> Tackle * And Tackle, like any other programming language, is a tool for tackling problems with. ---- '''THIS DOCUMENT''' This document is the '''Tackle Programing Language Specification - Version 1 Draft'''. Once it's been worked into the situation where it seems worthwhile to do so, we'll rename it to ''Version 1 Final'' - and begin work on ''Version 2 Draft''. ---- '''TIME FRAME''' It's anticipated that it will take at least three to twelve months - from the current start date of April 2004 - before ''Version 1 Final'' will be ready. ---- END OF '''Tackle Programming Language Specification - Version 1 Draft'''. (as at 25 April 2004) ---- [daapp] 2004-04-24:I suggest to use following scheme: 1. the tcl standard library [[TSL]] should include only one object-oriented extension. This extension can be compiled or pure Tcl, it doesn't really matter from a specification point of view. From a performance and foundation point of view, it probably should be compiled, either initially or at least eventually. This extension should not be written in a way that other object-oriented extensions are made impossible to develop and use. 1. TSL should include a megawidget framework, based on the object-oriented extension 1. TSL should include the tools and modules for documentation creation and convertion into other formats 1. TSL should include the tools and modules to create skeletons for new modules and to work with a network archive of other code 1. TSL should include the tools and modules for easy compilation (where appropriate) and installation of extentions 1. [[fill in other needs here]] My candidates: 1. [XOTcl] for the OO framework [[anyone want to explain _why_ the choices here were made?]] 1. [Namespace MegaWidgets] or [Snit like Delegation in XOTcl] or create something new using [XOTcl] 1. [doctools], but with [xhtml] output included :) 1. modules framework, which needs to be created from stratch - perhaps based on starkits however as well as [TEA2] directory structure 1. [CriTcl] Well, it look like the Standard Tcl Library Specification :). Peter Newman 25 April 2004: ''Thanks for your feedback. It's my intention that Tackle will give you EVERYTHING you've asked for above. However, it'll be at least a few more days work before I've explained this...'' ---- [davidw] I'd rather create a mailing list than use wiki's for discussion, but here are some of my thoughts on the matter: '''[Worse is Better]!''' - let's get something working, and save the more contentious pieces until later. Every module should have one or more people willing to take responsibility for it. Every module should attempt to harmonize on a documentation standard. Every module should have some tests demonstrating its functionality. Every module (except where obviously not appropriate) should function on MacOS X, Linux/BSD/Unix and Windows. Every module should have a BSD or compatible license. Initial candidates: thread, TclX, XML stuff, tcl big number package, udp extension. Peter Newman 25 April 2004: ''Thanks for your feedback. I agree with eveything you've said/suggested. However, it'll be at least a few more days work before I've explained how this magic is achieved...'' ---- [daapp]: Using [Starkit] for distribute modules will be a good idea, but this time standard library must include support for [Starkit]s. About choice that was made, it was only my vision (not a recommendation); nothing else. I agree with [davidw]; we need something that will '''work''', after that we can polish it. About license: I think because [Tcl] is under [BSD] license, every module '''must''' be under that license. About other modules, mentioned by [davidw]: let's look at this variant - we have small TSL that helps to develop not applications, but other libraries, and make other libraries using TSL: megawidget library, network library, text processing library, etc... What do you think about this?, Peter Newman 25 April 2004: ''See above. Also, I'm at a very general, high-level stage at the moment. It'll probably be at least a few weeks before we start getting down to the lower level specifics. Hang in there.'' ----