[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 its 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] * [UPL: The Kernel] ---- [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://svn.perl.org/parrot/trunk/languages/tcl/TODO]. 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 really 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 '''redefine 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'''.'' ''The modularity also allows UPL to support '''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 (or more precisely, whatever someone's implemented a parser, etc., for).'' ''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.'' ''So with UPL it's the '''modularity''' that's the important thing. Hopefully, that will create a language that, unlike Tcl and Perl, doesn't have a monolithic and inflexible core that makes enhancement and improvement increasingly difficult as it grows.'' ''That gives us the abilty to add useful features from other languages. And to freely innovate and improves any aspect of the existing language. It also allows the script-level programmer to freely select and/or create exactly the programming language toolkit they want to work with.'' ''It also makes development and distribution of even the low-level stuff that's currently in the core much easier. The developer simply creates or recomplies the dll/so concerned - and the user loads it.'' ---- [DKF]: I got the picture, but I suspect that what you're proposing isn't going to work as well as you hope. In particular, it doesn't seem to me that it will be easy to share the scripts created using UPL with anyone else; there's no way to determine if they have the same set of modules loaded. ---- [XX]: I am usually content to let the experts hash out the technical details, but feel compelled in this instance to comment on a couple of points... I did some experiments myself with modularizing an earlier version of the TCL core that had been ported to DOS. I have found, as others, that not only are there difficulties, but the payoff is not as great as anticipated. Perhaps a CVS branch "TCL-embedded" might be an interesting undertaking, and an attractive one for marketing to a certain audience. But facing facts: hard drive space and memory footprints simply aren't the issues they used to be in the majority of the deployments out there. Even having a "Site TCL" and individual deployments suited for particular purposes wouldn't even begin to make a dent in the resources of most systems. Further, this particular idea, while having some nice features on paper...I don't know. First, as [DKF] suggests, the actual shape that the implementation will take raises some questions. Next, after reading the descriptions herein, I am left without a clear picture of what the actual benefits are supposed to be...what is the problem that this solution is actually attempting to solve. I look at the reaction of the Perl community to the proposed Parrot engine...the .Net backlash. These might not be technically the same but they are similar in that they all add a new meta-layer of sorts to the mix. Why should TCL follow these bad examples with its core. Let us target their engines (as is being done) and compete with them there. I'm hardly a reactionary thinker, and actually do like some of the suggestions that are included in the UPL pages. And perhaps UPL has its place, but not as a replacement for the TCL core, in my opinion. Personally, UPL, Parrot, .Net etc... all make me a bit queasy. For those that have read "Mostly Harmless" the 5th book in the Hitchhikers Guide to the Galaxy Trilogy, I am reminded of the creepy new edition of the guide that takes the power out of the hands of the user. I'm sure I'm jumping at shadows, and I try not to let this queasiness cloud my opinions too much. But "managed" is to me a euphemism for "mangled" and "bastardized" I'll manage my own code, thanks. I do look forward to watching this all hash out, though. There are intelligent opinions on both sides of the discussion, and the subject of the future of TCL keenly interests me. ---- [LV] See also [TACKLE]. ---- '''[anand] - 2011-03-21 01:59:03''' I think we have already got a Unified Programming Language which is [XML] http://www.w3.org/TR/xpath-functions/ Anybody can write one's own programming language in XML and describe it neatly and completely using XML Schema. The input is a file in XML, rules to create input are in XML schema, the processing instructions are in XML (XSLT file), rules to interpret custom programming language are in another XML schema, the output is XML (XHTML) and the interface is a web browser with full HTML5 text/image/audio/video rendering capability <> Discussion