SOAPI itself dates back several years now. The first SOAPI code was put together sometime in 2000, although it wasn't until 2001 that it was given the name SOAPI. (For those that care, SOAPI stands for Smart Object API. It did originally stand for SMART Object API - the SMART being an acronym - but that's another (boring!) story.) The first version was little more than a collection of useful scripts, on the PHP side at least, as SOAPI was originally intended to be a JavaScript library, providing a rich interactive experience that emulated non-web applications. Indeed, AJAX is nothing new - the original SOAPI libraries can still be seen in the archives of the SOAPI SVN repository, and SOAPI was certainly not the only place that AJAX-like behaviour could be found before "AJAX" was coined as a buzzword.
Anyway, for all manner of reasons that are best left buried in history, SOAPI gradually became a predominantly PHP-based API. SOAPI 2 saw the emergence of a structured set of classes, and it was at this stage that the first PTP engine was put together. It was very rudimentary, in that it did little more than replace text that it found inside placeholders. By 2002, Dan Williams (the creator and maintainer of the SOAPI library) had started on PTP 3, with the help of Andrés Angulo (the co-creator of PTP 3). Over a period of months the PTP engine took shape, and by the summer of 2003, PTP 3 was declared finished, and stable.
And that's the way it stayed until April 2006. In the years in between, various enhancements and adjustments had been made to PTP as certain shortcomings and missing features were discovered. However, the engine was not very good at working out expressions, and had a lot of idiosynchrasies due to the way the design stage had taken place. PTP 3 was originally planned to have a hard-coded, core feature set, but ended up having overloaded operators, four kinds of variable (each with its own scope/namespace!), custom functions, and many more bolted-on "extras" that turned the engine into something it was never intended to be, and wasn't able to cope with very well. It also had a non-intuitive internal array structure that caused frequent grief, and was painfully slow in some cases, as it worked on a purely interpretive basis. That is to say, every bit of code was parsed, evaluated, and executed in real time, as the template was needed. This meant that templates with lengthy looping operations were parsing the same bit of PTP code over and over again, drastically increasing the runtime.
Despite all this, PTP gained a small but loyal following - restrictedly small, due to the fact that no documentation was ever really produced (although the code itself has always been impeccably laid out and commented). And although PTP 3 was slow, it did work, and work well. Indeed, it is at the heart of systems in use by certain blue-chip companies such as BMW, Mercedes-Benz, Océ, and Ford (to name but a few). The main reason for this is despite the various shortcomings of PTP 3, the rest of SOAPI 3 was enterprise level, and big companies were always happy to throw faster computers at it if the templating side was too slow. After all, SOAPI itself is a great time saver, and therefore a cost saver too. Plus, the way that PTP works (and its feature set) has always been superior to other popular solutions (such as Smarty).
It was inevitable that this would change at some point, and so in late 2005 the plans for SOAPI 4 were put together. There was some lively discussion on the SOAPI DevNet about what PTPScript 4 should be like, as well as the other areas of SOAPI. Work finally began in April 2006, and by mid-May the most important SOAPI modules, including PTP 4, had been completed.
With SOAPI 4, the difference between "PTP" and "PTPScript" is distinct. Previously, the whole "PTP-ish thing" was always referred to as "PTP", and when disambiguation was required, the terms "the PTP engine" or "PTPScript" would be used. This is because the two were inextricably one - the engine had the language hard-coded into it. PTP 4 changes that, because PTP is now "just" a template engine. On its own, PTP has no language definition at all. It knows about variables, numbers, and operators - but that's it. It doesn't have any predefined operators, functions, or anything. PTPScript is essentially a language implementation, extending the core PTP engine (which consists of a sophisticated parser and compiler). This means that not only is PTPScript itself changeable and extensible, it doesn't even have to be used. Someone could make up their own, unique language (or emulate another language of their choice) by providing the necessary language definitions and handlers. That's why there is a totally separate section for PTPScript, away from all the SOAPI libraries.
PTP 4 is not only far more sophisticated than PTP 3, it is also extremely fast. It compiles templates at speeds that no-one would complain about, or have to wait for, and once compiled, the template code produced can be cached in order to skip parsing and compilation next time round. The compiled code produced by PTP 4 is hardly any slower than native PHP. This means that for the first time, PTP is a serious contender, because it not only has the best feature set, it also is no longer a slouch. Smarty, eat your heart out!
The operators and functions in PTPScript are inspired by a variety of sources, with the key aim being that everything makes sense, is straightforward to learn and use, and is as helpful as possible.
Some functions have obviously come almost straight from PHP - for instance, htmlencode() and date() are very similar and the tables on the documentation pages for those functions have been lifted almost unaltered from the PHP Manual. (Zeev, Andi, Rasmus - I hope you guys don't mind!) However, there are often key differences - for instance date() has an added parameter, to remove the need for a second, GMT-specific, date function.
In other areas the functionality will be the same but the order of parameters will be different to that of PHP - this is to ensure that PTPScript always has a consistent approach to syntax, rather than copying PHP's rather random style. Some functions have been merged, and others are just totally different. As a rule of thumb, if a required action fits into the scope of a particular function, then that's where it belongs, rather than having a myriad of slightly different functions (the sort() function is a case in hand - it combines the functionality of no less than eight separate PHP sort functions).
In other areas, actions that have functions in PHP instead use operators in PTPScript, such as type casting and type checking. The aim is to make PTPScript code easy to read, write, and above all, understand.
Many operators have been inspired by the architecture design documents for the forthcoming Perl 6 - for instance, the symbols used for the bitwise operators; the way that the logical operators return the value that made the expression true, rather than Boolean true; and more besides. It would be very nice to have junctions in PTPScript, but they would be tricky to code and are not likely to be used very much, so they have been left out for now (although the operator symbols are reserved in case they are added in the future). Similarly, it would have been nice to chain the comparison operators, but this wasn't possible.
Still other areas of the language have been influenced by Ruby - the way in which arrays are created, for example; and there are even hints of Visual Basic, in the form of directives (think Option Explicit, etc.). Using => for key/value pairs in PHP/Perl style wasn't liked, and so colons are used instead, which again is very Ruby/Python-esque.
One area in which the ideas of Perl 6 has been firmly rejected is that of whitespace "dwimmery". PTPScript is very relaxed about whitespace, whilst being strict on context and order so writing a . b will give variable a.b, ignoring the whitespace. (This flexibility extends to other areas too, so that writing (5).5 will actually work, and give the number 5.5.) By contrast, Perl 6 is becoming stricter in some areas, which gives inconsistency, no matter how important the motivation.
Overall, it is hoped that the syntax chosen for PTPScript is well-thought-out, sensible, and will meet with approval from all who use it. And if it is disliked - well, it's easy to customise!