Getting into the Pascal groove

By Colin Hoad | Aug 25, 2025
RSS
The Free Pascal cheetah

After the recent breakthrough I had with getting my language server working, I decided to invest some time into refactoring what I've built so far - partly to make the work of extending the language server easier as I move forwards and also as a useful exercise in getting closer to Pascal and how to write better code.

I read up on the correct naming conventions for Pascal variables, classes, types and general code hygiene, and did a once-through of everything I'd written up to this point to get it aligned to how it should look. One of the interesting aspects of writing programs in a new language is shedding some of the instinctive naming habits picked up by association from more familiar ones. Out with snake_case and in with… well, Pascal case!

The next thing I needed to do was identify some areas for object oriented improvement. For example, my logger procedure was reliant upon various hard coded constants, and I decided it would be better to have a configuration file to store these values. That configuration file would need its own management functions, and so I defined a class for the configuration file and then another class for my logger. This was a useful lesson in writing what I hope are good classes, with the appropriate privacy surrounding the methods and instance variables. I even managed to squeeze in a little bit of inheritance, as I figured my configuration class might be useful in other programs, so I pushed all the language server specific functionality into a subclass.

Incidentally, I ended up defining my own key:value syntax because I wasn't happy with the other libraries I found. I initially wanted to use TOML format, but the only TOML library I could find for Pascal came with a lot of unnecessary code, slowed down my compiling and threw a bunch of warnings. I like a clean and tidy house when I'm coding, and even though warnings won't prevent code from running, I work hard to ensure I don't get any during compilation. I'm also a bit of a control freak about my own programs and don't particularly like relying on code that I don't understand. Given one of the reasons I chose Pascal was for speed - and to keep the language server as lightweight as possible - I decided that writing my own simple class for managing configuration values was the best course of action. It's also one of the luxuries you have when coding for fun rather than for work: nobody is going to tell you to go faster by using existing libraries, you can choose what you are and are not willing to tolerate! 

Well, with the configuration and logger classes sorted, I decided it was a good idea to write some very simple unit tests for checking they behaved as I wanted them to. As a pure compiled language, Pascal doesn't have the REPL feature of languages like Python, so if you want to check if code is doing what it should, you really do need some simple test programs to put your classes through their paces. It's also just good regression testing practice: as you define new classes and units, you should have a program you can quickly re-execute every time you make changes, to validate you've not broken anything that was working previously. They don't have to be particularly sophisticated, just a set of simple WriteLn statements that verify the functions and methods do what you expect them to do.

Finally, I moved a few functions out of the main Oplls program that controls the language server and off into a helper unit. Not only is this a bit neater, it also makes things easier if and when I decide to refactor any of that procedural code into something more object oriented. It's no longer sitting in the body of my main program, so abstracting it a little further is that bit less bothersome.

I've still got one particular function doing a lot of the heavy lifting, and I believe it will need to become a class of some kind in the near future; but I need to do a bit more thinking first about how I want to build out the functionality that handles request parsing and response generation. In the meantime, I've reached a point where I'm happy to share the actual code, and have thus created a new repo on GitHub, which you can find here as well as via the GitHub menu item at the top of my website.

Pascal really is a great language to code in, and I am enjoying it more and more as I continue to use it. Not being spoilt by Python's seemingly infinite set of modules, it's much more like coding from first principles… but with a bit more help than you might get trying to write a language server in C (or assembly!) It makes me feel more in control of what I'm developing. Suffice to say, I'm really happy I chose Pascal for this project, and look forward to more coding adventures in the weeks and months ahead.