_{Jamie Balfour's}Personal blog

ZPE 1.8.11 is now available and is another small update in terms of the number of features but big in what the new features bring. 

The first big new feature is support for infinite parameters. This is done within the definition with the double dot notation such as function x($y, $z ..). There is more in the documentation.

Reference functions have been completely redesigned, as have objects. With objects, there is a 2x performance increase whilst with reference functions, there is a much larger performance increase as well as a stability improvement. Reference functions can now be chained to each other much easier and this change requires much less code to do it.

ZPE 1.9.1 might be over three months away following the version/year release cycle that I developed for it, but nonetheless, it is a good time for me to explain the new codename system chosen for this cycle of ZPE versions. 

After much debating with my brother over this one, I have decided to name them after places in the Scottish Borders. I thought I'd start off with a few version names:

• 1.9.1 - Kelso
• 1.9.2 - Selkirk
• 1.9.3 - Hawick
• 1.9.4 - Peebles
• 1.9.5 - Melrose
• 1.9.6 - St Boswells
• 1.9.7 - Galashiels
• 1.9.8 - Chirnside
• 1.9.9 - Duns
• 1.9.10 - Lauder
• 1.9.11 - Earlston
• 1.9.12 - Roxburgh
• 1.9.13 - Allanton

There may be more names in the future but that's all of them for now. You may also note that I am no longer starting on minor version 0, e.g. 1.9.0, but starting on version 1, e.g. 1.9.1. This is a change that makes sense to me when developing.

ZPE 1.8.10 is another big improvement with the new security sandbox being improved considerably. It also adds big new features to the ZPEClient and ZPEServer modes that allow SSH-like commands to be executed as well as SFTP-like commands.

I have also added in my own file system management tools to assist in correctly parsing file pathnames such as ../ on Windows systems as well as all other platforms for a consistent file management system.

The new logo has also been added to the GUI and I've improved the debug mode.

Once again, ZPE 1.8.10 is a big update like its predecessors were. It's now available for download from my website in the usual place.

SFTP is an amazing protocol. I've been using it for a good 7 or 8 years now and it's been one of the most useful tools I have ever used.

SFTP features commands like get and put. 

Well ZPE 1.8.7 added the send> command to the ZPEClient which allows sending a file to a ZENServer. Prior to this, I had been ensuring that all data between the client and server is secured using my own encryption system. Well, without hesitation, I knew that this had to come to file transfer too. So now ZPE can send and receive files that are encrypted and decrypted within the client and server. This breakthrough is a compelling reason to use ZPE since it offers a very strong alternative to SFTP. 

Further to this, to make it even more powerful the client now offers the ls (list files locally) command and the rls (remotely list files) commands. 

Past versions of ZPE have often contained flawed features such as the LAMP evaluator or minor things like performance glitches. This is often the case with any project. But any project will have flaws in it somewhere. ZPE is no different.

However, the stability of ZPE has got to the point where I believe that most of the flaws and errors that stop it being usable have been ironed out.

Over the last few months, ZPE 1.8.x has been removing old code and has cut down over 10,000 lines of code from both the runtime and compiler to make it more streamlined but also to improve stability. Further to this, features from very early versions have been revisited and revised to ensure much better performance and reliability - writing a programming language, compiler and runtime is quite tricky you know! Most of the issues actually come from the runtime, since I spent a lot of time in 2016 improving the compiler whereas the runtime just got a small bit of TLC.

Another major issue that often occurs is when new compiler features are added that actually could interfere with another feature. Now I spend a lot of time drawing up the ideas so don't get me wrong, I actually do plan. But sometimes it's difficult to see these potential collisions from the offset. For example, the move to the fat arrow syntax for lambda functions caused all sorts of issues until I decided to merge functions with lambda functions (that in itself caused further issues). More recently I discovered after going through the compiler that the generate_parameters function would allow values to be added in a function declaration's parameters: e.g. function foo ($x, 10) { print($x) } because the generate_parameters function was designed for both formal parameters and actual parameters. This has been fixed by separating these into generate_parameters and generate_arguments.

If you are writing programs using ZPE and compiling them, make sure to recompile them with the latest versions as soon as they are available as byte codes are constantly changing and being added. A new feature I'm adding into the runtime is to check which version compiled the program before attempting to run it since old versions may have different byte codes.

Since ZPE 1.8.8 was released as a fix for a bug in ZPE 1.8.7, ZPE 1.8.9 will be released on 05/08/2020.

ZPE is very flexible and powerful now. But there are still things that I've wanted to add since I started developing it. The compiler is very flexible and it's so easy to add new features that whenever one pops into my head I want to implement it. But sometimes a feature itself become complicated or changes the way the system works currently and I try to find a more standard approach to its implementation.

Two features I speak of are named parameters and infinite parameters. 

First, let's look at infinite parameters. Infinite parameters have been on the cards for a long time and actually existed for a short period of time in ZPE 1.5.x but were simply removed due to complications the features brought. In theory, they should be easy to implement because the syntax for them was something like:

$x, $y ..

On the compiler side, this is easy to implement. But on the runtime side, I wasn't sure how to represent it. Should $y be a ZPEList type? ZPEList would make sense so that $y[0] would be the first variable and $y[1] the second and so on and so forth. Infinite parameters are actually supported by internal native methods by default, but not by defined functions or external native methods added by plugins. This is why I feel this is a priority feature.

The other is named arguments. This is something implemented in ZPE 1.3.x for a period then removed before release. It's coming soon to ZPE (probably late this year) and it's one of my favourite up and coming features that will be released this year. 

Named arguments allow arguments to be specified in an out of order manner by specifying the name. This is roughly how it will look:

function makeperson($name, $age, $favourite_colour)
  print("Your name is " & $name & " you are " & $age & " and your favourite colour is " & $favourite_colour)
end function 
function main($args)
  makeperson (age = 10, name = "Jack", favourite_colour = "Purple") 
end function

Notice that the arguments are out of order and specified by their name. This is the main benefit of this new feature.