START OF Tackle Programming Language Specification - Version 1 Draft (As At 25 April 2004).
Peter Newman 25 April 2004
INTRODUCTION
The Programming Language Tackle 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:-
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:-
we re-designed Tcl as:-
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...
THIS DOCUMENT
This document is the Tackle Programming 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:
My candidates:
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...
I've never used mailing lists, but in principle (bearing in mind that I currently know nothing about them,) I don't mind adding that. I like the Wiki, because hopefully it documents the whole thing, even for people that join in at some later stage. But if you still feel that mailing lists are worthwhile, can you let me know how it all works - or where I can go to find out. Thanks.
SS: 25Apr2004: David, I fully agree with you, but I've to note that worse is better works well if we are ready to change interface from time to time, in an incremental way, without to worry about 5 years old code that no-one is using will stop to work. Corporate's code can just use old versions of Tcl if they don't want to update the source code. Opensource projects MUST update the source to be compatible with a recent release of Tcl, if they don't do it, they are probably dead projects that no one is using anyway. I see a very big inertia in the Tcl comunity to change interfaces, so for the fear that old code will not work, we get that new code will never be written because we can't improve (fast) enough Tcl. This is a bit polemic but I force a bit the things to make my point clear.
daapp: Using Starkit for distribute modules will be a good idea, but this time standard library must include support for Starkits.
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.
TV Well, eehr, what is your angle, I mean where do you come from or think about proposing things like these? Maybe make a general (short?) page on yourself, so people can understand why you take this point of view?
a g(zip) file ? tcl is simply text...
Hmm, a small core is desirable for obvious reasons, tcl and tk can be seperated, or do you mean the distribution?
People seem to be looking into this, I gather your proposal would add something here? About things like bwidgets as a themable library and such issue, or a new Tk configuration possibility? Have you proposals on that?
Fine, for that no new language is needed, or do you propose a tcl-lib built in man command?
Seems like a big issue in the face of the various OS-es and make systems.
??
And what are you saying about this?
Peter Newman 25 April 2004: Thanks for your comments TV. I'm just another Tcl programmer. Prior to that it's been Pascal, Forth, 80x86 Assembler, Awk, Perl, and C - over the last 20 years or so. I been at Tcl only for just under a year. Tcl's great - but it also has some problems (listed above) that seem to have been endlessly discussed (in some cases for many years), and never resolved. During the discussion in Tcl Common Library it suddenly dawned on me how why these issues were occuring - and why they were never getting resolved - and how we could change Tcl so that individual Tcl programmers could fix things - so as to get what amounts to their own personal version of Tcl, exactly as THEY want it. But it's going to take a few weeks to document this clearly. And yes, I'll work through the issues listed above, and explain what I mean more clearly.
Lars H: You might want to create a [Peter Newman] page here on the Wiki with that information. Take a look at the Tcl'ers page.
Lars H: The claim above that "the parser and the interpreter" should be optional stand-alone extensions may look like moonshine, but in Tcl it really is possible! Or rather: nothing prevents you from adding another parser and interpreter (e.g. for Tackle) as extensions to a Tcl shell. (If they turn out to be good the next step would be to try and drop the Tcl parser and interpreters from the executable, just to shed the weight, but that is some time away.) I don't know if this has ever been done (most people probably prefer to just add commands to the existing language), but it is certainly possible. You could just go
tackleproc mycmd {args} { ... The body is all Tackle ... }
and define a command in a language that doesn't have to have anything in common with Tcl -- not even the bytecode executor. Or you could go even further and not even create the mycmd as a command in the Tcl interpreter, but only make it available to the Tackle interpreter. This really is an interesting concept, even though I doubt I will do any work on it.
The most intriguing point is probably: How much can one drop? Would it be necessary for Tackle to support the same basic concept of values as Tcl does? Or at least contain that part of the Tcl C library that implements Tcl_Objs?