To use this website fully, you first need to accept the use of cookies. By agreeing to the use of cookies you consent to the use of functional cookies. For more information read this page.

Jamie Balfour'sPersonal blog

A long-awaited feature in the ZPE was the request for an updater built-in to the interpreter and parser. So now with ZPE you can, although a minor update, it is actually a big update for it.

This is a long awaited feature and it's very easy to do. ZPE is now also available to download from my website as of today. To run the update, simply type:

zpe --update

By reference-style variables have yet to be fully implemented and are partially implemented in ZPE 1.6.8.x. They've been disabled within the release versions.

With 2019 just around the corner, ZPE 1.7.0 is also just about ready to be started and readied for release. ZPE 1.7.0 is bringing some performance improvements and one or two new syntax features that aim to make ZPE even better. ZPE 1.7.0 will also bring an automatic updater, expanding on what ZPE brought. Unfortunately, ZPE 1.6.9 which I had hoped to bring out before the end of the year, has been scraped due to the lack of time.


ZPE has very recently made objects a staple part of the language. But did you know that all variables within an object are actually references? What I mean is that if you change a variable (property) within an object in ZPE it will actually update the object.

$o = {$x : 10}
//Will print 10
$o->$x = 50
//Will print 50

So what does this mean and just how can it be brought further into ZPE? Well this exact concept will be used in ZPE 1.6.8 (December 2018) to bring forward by reference variables. These variables have sort of existed since some version 1.5.x but have found very little use. They work on a different system to ordinary variables however and a system of trust between the function itself returning what is necessary.

Whether or not ZPE 1.6.8 completely adds support for by reference or not is dependent on how much I manage to get done with regards to it, but I can say for a fact that it will be very useful as both a learning tool and as a feature of the language when it is done.


ZPE 1.6.7 is definitely set to make an uproar in comparison to many of it's predecessors. That's because of the fact that it adds more than 5 new major features ranging from the TYPO system to quick lambda functions and changes to the way references expressions work.

But now another new feature has been added - a feature that will benefit the TYPO engine considerably but has also been requested since the early days of the language development. The addition of these new types of lists has had considerable implications on the language itself too, fixed size lists are often faster to work with.

The syntax for writing one of these new lists, let's say of type string and one of type integer, each with five elements, would be:

$strings = [""] * 5
$ints = [0] * 5

TYPO is finally here in version 1.6.7 of ZPE. To be specific, TYPO has been in ZPE for a while but it's not been in use. Now ZPE is fully in support of TYPO. Take a look:

Variables can be declared (lines 8, 14, 17) using a type and then assigned with another value of that type (lines 11, 20). If you want to reuse the variable with a different type in it, you need to redeclare the variable (line 14). On top of that compilation errors are now thrown when a different type is assigned to a variable. Also, as seen on line 24, TYPO can evaluate internal methods for the return type and compare it to the type of the variable, hence why it will stop compiling at line 24.

This adds a bit more time to compilation, but helps in several ways:

  • From a learning/teaching perspective, TYPO encourages use of typing in programming
  • From a programmers view this is a good way to ensure that you are sticking to principles of programming

TYPO is by default turned off in all versions of ZPE but you can turn it on by changing the settings of the compiler. I recommend trying it out but do not suggest all programs written use typing! ZPE is primarily an untyped language and will likely always remain this way!

ZPE 1.6.6, the version which I never believed I'd ever finish working on, is now available for download. I don't often post the changelog straight onto my blog but here's a look at it:

-- Version 1.6.6 --

  • Fixed an issue with for loops
  • Added the circumflex syntax for power e.g. 5^2 is 25 (five squared) and 5^3 is 125
  • Added the variable mode to the -r ZAC. This mode is like single line mode except that variables and their values are persisted.
  • Removed the Program read mode and the Multi line read mode
  • Fixes with comments in the Zenith Parser
  • Fixed an issue in for loop with reading lists
  • Fixed an issue that caused negative numbers to convert to strings when parsed
  • Added binary parsing into the compiler e.g. $v = 0b0101. Binary values always start with a 0b
  • Added the to_decimal method to convert a string of binary, octal or hexadecimal characters to an integer
  • Command line arguments are now separated from program arguments using a -args command line
  • Added object inheritance
  • New if statement optional syntax using the THEN keyword: $x = 10 if $x == 11 then print("Yes") end if
  • Added the built-in object methods `inherit`, `serialise` and `get_definition`. Removed the general serialise and object_get_definition methods.
  • Fixed an issue where in the single line interpreter variable values were not actually retained properly
  • The single line interpreter no longer exits on an error but displays an error and continues.
  • Fixed an issue in which new ZPEObject would set their values and variables to the FRIENDLY only access
  • Added the optional 'code' parameter to the exit method
  • Small performance improvement with the LAMP parser
  • Added the cache_value and read_cache_value methods which read a value from a special secured file
  • Added the get_version method which obtains the version number of the ZPE instance it is running within
  • Added an option to disable methods from the runtime environment (using the properties file)
  • Added negation of variables such as -$v and improved the method of negative values being used
    Improved the way in which negative values are evaluated

It's quite extensive compared to other versions in terms of big features added. My favourite new feature is the improvement to the -r ZAC since it now uses the single line read mode but retains variable values between lines inlining it with interactive consoles in languages such as PHP. I also like the new power feature being a major part of the syntax and the new -args feature for the interpreter means that less time is spent figuring out what are ZPE command line arguments and what are program arguments making it run slightly faster (but also reducing the code base quite considerably). The to_decimal method is quite nice too, convert quickly between decimal and binary, octal and hex very quickly. Finally, I love the fact that it is now possible to quickly turn a positive value in a variable into a negative one with a simple - in front of the variable.

ZPE 1.6.6 will be the last version to use names from the Harry Potter universe, version 1.6.7 will be named Waverley after the railway station in Edinburgh and successive versions will take a similar approach being named after famous railway stations in Scotland.

ZPE 1.6.5 was a big update with lots of new features and bug fixes. The next version will bring even more interesting concepts to the my programming environment.

My favourite is the new Python style syntax. ZPE introduced way back in version 1.3.x the curly brace notation found in Java, C#, C and many more languages to allow function declarations to be created in a short hand way that follows the C style of doing this. Well, version 1.6.6 will now begin the introduction of Python colons to represent functions. I intend only to bring it to functions at present. I very much doubt this will be in version 1.6.6, but I'm looking to have it in version 1.7.x. But will the Python inspired syntax therefore encourage indentation? Probably not.

I'm also working on a ZPE to Python transpiler - this is because although it may not seem like it, Python has quite a similar syntax to ZPE (both languages share a bunch of syntaxes).

I will also be looking into a major restructure of the LAMP parser and looking to moving from it to a new parser I call Exparse which will parse all expressions regardless of being logical or mathematical.

ZPE 1.6.5 is now available to download from the Download Center on my website. This version is a pretty decent update with some great new features including what was mentioned in the previous post about the way in which pre-increment and pre-decrement syntax has been updated.

As well as this I'm very pleased to announce the new syntax for the for each statement. The first sample show the only way it was possible before now and the second sample shows the new alternative method of defining for each statements:

for each ([44, 66, 77] as $num)
end for
for each ($num in [44, 66, 77])
end for

As well as these new syntax updates comes a few performance updates and some bug fixes - particularly one that fixes an issue in the ZenCSV parser.


From the very early days when increment and decrement methods were embedded into ZPE, ZPE has always looked a bit, let's say, different, comparatively.

I say this because of the fact that pre increment and pre decrement syntax was, not like other languages. As you may know, ZPE is inspired by many languages such as JavaScript and PHP. A lot of influence in design came from PHP in particular, most crucially the way in which variables work. 

Without further ado, let's look at how pre increment works in YASS:

$x = 11

This has been the case since it was first introduced in version 1.3.4 in June of 2015. I updated the Zenith Parser to read a double character word differently back last year with the intention of updating this eventually, but today I just thought I might as well. You can see how it's different now:

$x = 11

Merlin will be happy with this update as he originally commented on this syntax design a few years back.


Back in the early days in ZPE I released tons of new versions almost weekly sometimes but often monthly. I suppose this release cycle was down to the fact that it was under a big development - things have slowed since.

But back then versions had multiple build versions (if we follow the ProductVersion.Major.Minor.Build pattern) Version 1.3.5 was the most obvious example (that's ProductVersion 1, Major version 3, Minor version 5) because it had,,,, Why so many versions?

I believe was one of the most significant upgrades to ZPE in it's history. That's because it added Real Math Mode, which is now part of what is called LAMP (Logical And Mathematical Parser) which allowed mathematical expressions such as 5 +5 to be evaluated straight from the interpreter. It was a huge improvement. In my new system, this huge upgrade would likely have sanctioned a new Minor version (so in this case, it would have become but back then my versioning was based on the number of compilations I made.

So why was this?

Well, back then a new Minor version came along when I had asked my testers to fully test the features of the previous version and assure that they work as expected. This way, a version with a Build of 0 was a stable version (or as stable as testing can assure). Nowadays, this is not the case. Versions are released when I feel that enough has changed to sanction the new version. I no longer keep the compiled version at the end of the version as the Build version unless something is fixed (but no new features are added as this would be a new Minor version).

New versions are now mostly released when something that worked before will no longer work in the new version. For example, the ZPE Standard Library is a bunch of ZPE based functionalities and is compiled prior to use. This means if any of the byte-codes are changed in YASS the whole library needs recompiled. This is why this indicates the need for a new version number.


As part of my continuous dedication to ZPE as of recent, I'm now happy to announce ZPE 1.6.3 which brings a major change across the system but also removes some things.

For example, the way that the negation worked in ZPE has totally changed. The previous version of ZPE would negate using the not command which was aliased by the ! command (or it might have been the other way around). ZPE now treats negation as a symbol it must acknowledge now as an actual negation symbol. What I mean by this is that it no longer compiles a function call from this (which is slower too) but simply negates the value. Again, this should have a small impact on performance. The LAMP Parser has been improved too, minor bits of code reuse have now been put in place of chunks of code, so it should be a bit faster too.

Another change is the way in which errors are now handled. An error in ZPE previously was a low level based error and whilst that same core principle still applies, errors can be handled a bit better now and are now an actual ZPE type.

However, the most important change is something no one will actually see (unless I've broken something in the process of building it) and that's the way in which chained functions work. Chained functions (such as a get call on a list) are now compiled completely different, so if you use compiled code, make sure to compile it again using ZPE -c. It's so important that after any update all code is recompiled anyway, this makes sure that all byte codes stay in line with compiled work - I always recompile the standard library for the ZULE archive to ensure it is up to date.

I look forward to bringing new features to ZPE 1.6.4 but I'm going to be bold and say that since adding the index brackets e.g. [0] I feel that ZPE is really on a role to looking like a proper syntax. I have also begun to update the formal specification of ZPE as this is so important. At some point, I also want to finally split the compiler and interpreter into different classes. This was something I have envisioned for a very long time but it's such a big job it's not been possible yet.

Powered by DASH 2.0 (beta)
Code previewClose