[Peter Newman] 8 January 2005

"Unified Programming Language" is an attempt to create a programming language that combines the best features of all scripting and compiled languages - with none of their defects.

It arose from an idea suggested by [DKF] (I think,) on [Tcl/2], that it might be easier to improve Tcl if we started with a clean slate - and designed a new version thereof (called Tcl/2) - where backwards compatibility with traditional Tcl isn't a requirement. So we can take the bits we want, leave those we don't, and innovate to our hearts content.

Seems to me the best way to go. So this page and it's sub-pages are just an attempt to make that new '''Tcl/2''' happen.

Obviously however, it's too big a job for one person. So it'll die unless heaps of others - and that means YOU - pitch in.

I won't go on about what's right and wrong with existing Tcl. It's discussed exhaustively on this Wiki.

First thing we gotta do is get some concrete overall design down on paper. Here are the main features of the new language. Feel free to add more...

   * [UPL: No Core - No Core Team]
   * [UPL: The Bootstrap File]
   * [UPL: The Bootstrap Interpreter]
   * [UPL: Tcl, Perl, Python, C, Etc]
   * [UPL: The Language Parser(s)/Interpreter(s)]
   * [UPL: Command-Oriented & Object-Oriented Tcl/2]

----
[Gustav Ivanovic] Huh ? This reminds me about something called M$ dot net framework.

[SLB] Yes. The Java Virtual Machine also has compilers for other languages, for example see [http://www.jython.org]. 
Also note that [parrot] has a Tcl implementation, though it appears there's still a lot of work to do on it
[http://cvs.perl.org/viewcvs/cvs-public/parrot/languages/tcl/TODO?rev=1.30&view=auto].
Does the world really need another multi-language virtual machine?

[DKF]: Just noting that I didn't suggest that. (I don't know who did though).

To me, the idea of a unified programming language reminds me very much of the phrase "Jack of all trades, but master of none." You gain in one area by making trade-offs in another.

   * [Peter Newman]: ''Yeah the name "Unified Programming Language" really sucks. It's totally misleading.''

   * ''UPL isn't a programming language (because it has no pre-defined commmands/functions, data structures, operators or conditionals, etc). It's a system that allows the script-level programmer to have total control over the programming language they use. In Tcl terms, we're just extending the '''package''' concept into the '''core'''. In UPL, every data type; 'lists', 'arrays', 'scalars' (variables with a single value), etc - and command or group of commands (you know them all), is a single stand-alone entity that the script level programmer can add to or remove from the language at will.''

   * ''That same modularity goes for the parser, and byte-code executioner, etc. Every component of the language is a separate stand-alone module that can be analysed and understood and coded and re-coded and bug-fixed and extended and enhanced, etc) on it's own. The only thing is that they all swap information between each other. So we have to define who does what - and how they talk to each other. But I'd like the whole thing to be as flexible as possible.''

   * ''The modularity means that one can then completely re-define the language, simply by adding the new data types and commands/functions etc that you want. Even the parser for example can be replaced. So if you wanted a Tcl that didn't use {} and/or [], etc - but had a more C-like syntax (strings in double quotes, and commas between items), you can do it.''

   * ''As a result, you can add data types and commands and even syntax rules from other languages.''

   * ''UPL also supports multiple parsers. So you can code one part of your program in Tcl - and maybe another in Forth, and/or Perl, and/or C, and/or Haskell, and/or Scheme. Whatever you want.''

   * ''We get the modularity by insisting that every component of the language be designed from the outset as a separate stand-alone entity. And then implementing it as a separately loadable dll/so.''

   * ''Which is completely unlike Tcl and Perl for example - both of which are implemented as a single monolithic core. With Tcl and Perl, if you want to change anything - no matter how big or small - you've got to understand the entire thing - to ensure that by changing or fixing one thing - you're not de-railing another. Then you've got to recompile the whole thing. It's hopelessly time-consuming and un-productive. And IMHO, the root cause of why changes to and improvement to stuff in the core seems so agonisingly difficult and slow.''