Jonathon,
I will take a good look at pax on the weekend. The list processing support in PAX is interesting. There is another free pascal script engine: PascalScript from RemObjects. It is used by the Inno Setup compiler to execute setup scripts. Having said that I don’t like RemObject’s PascalScript as the extensibility is poor, has no UTF-8/UTF-16 support and the underlying code quality is terrible.
I think what I need to do very soon is to write example code fragments showing what the script will look like, in the same style as the examples on the PAX website. Again, I’ll do this on the weekend. Whatever we end up choosing needs to fit in with our licensing goals.
Early thoughts/ Vision:
1. Script fragments would be embedded like PHP/ASP; as opposed to HTML templates with tags;
2. It would NOT be multi-threaded, however there would be some support for critical section protection of system resources: Eg. Two simulatenous hits on the same web page both wanting up update a log file or other common resource.
3. In relation to ISAPI, it will be an ISAPI plugin module; In relation to Apache it will be a handler-module.
4. The script engine will be invoked by the file extension – like PHP; in contrast to the normal way you would use a Delphi written web-module. I’ve been doing some preliminary research on how to do this on IIS.
5. Extensibility could be provided at two levels:
a. At the binary (provided by Host Administrator) level, the engine will have a plug-in infrastructure which could provide gateways to system services, such as leveraging a pre-existing library of PHP functions
b. At the script level, the script will have one feature that Delphi has that PHP does not: Redistributable component libraries, where components properties can be inspected and manipulated at design time without touching a line of code. This requires a language feature of published properties, and something equivalent in function to a dfm file.
6. How much of Delphi Syntax can be adopted? Tough question. I don’t know right now, but it is certainly something to think about.
One thing I am sure about, is that the language needs to be able to define compilands like Delphi units, with an exposed interface and hidden body. BTW, Ada goes a step further and enables you to define a hierarchy of compilands. Contrast this to PHP. In PHP code may be split into different files, but this split is an artificial one. From the interpreter’s point of view everything is global. PHP Files are linked together by include statements. The end result is that complexity of a PHP suite of files is proportional to the square of the code size – not a good result for large problems.
One dreamy thing I would like to do is create a bridge between PascalScript and PHP so script from either could call the other. But that is probably over-reaching at this stage, and may be even not technically possible.
Faithfully,
Sean
From: Jonathan Bishop
[mailto:bis...@bishopphillips.com]
Sent: Friday, 28 August 2009 16:33
To: Sean Durkin
Subject: Pascal Scripting Thingy
Sean,
Take a serious look at PAX Script. http://www.paxscript.com/ (It used to be free in an earlier version, but seems to be proprietary now). I am suggesting you look at it because it does the web scripting part of this problem, using a tag markup method similar to PHP. In fact it is almost a pascal version of PHP. Obviously, since it is now proprietary it is not appropriate as the scripting engine of this app, but we at least have a design model worth considering, and more importantly need to understand how this project is different – except perhaps that it is proposed to be open-source.
As an aside, we use the proprietary version of PAX script (along with a couple of others) and I can attest to it being very-very good.
Another one that is very strong (also proprietary) is the TMS Script Engine – we also use that (in the same application in fact!). We started using PAX because we wanted a javascript interpreter originally so we could drop IE as the browser plugin, but we ended up using PAX for other things, and kept IE (for now).
As an aside, I sued to teach language theory and compiler design (and a few other things) at ANU – so language based computing solutions are a particular interest of mine. In the 80’s the central concept of ANU Com Sci was that you designed a language to solve your computational problem, and then wrote a library/interpreter/compiler for that language, then solved you original problem using it and simultaneously solved all similar problems. I still tend to write and design like that.
I don’t consider interpreters complex, nor in fact IDE’s (of course it depends on what you want the IDE to do I guess).
I do think that language design is complex – end it is important to spend the right amount of effort at the start getting it right – or the consequences are disastrous later.
I think there are therefore a bunch of issues that need to be understood early – regardless of whether we are using pascal syntax. These include:
And fundamentally what aspects of the language, make it unique? And by implication to what extent are we going to change the basic pascal language? For example some languages offer uniquely beneficial enhancements – eg Eifel has a contract model that is brilliant for creating bug minimal code (you can assert conditions that maust be true at the start and/or true during execution and/or true at the end of a procedure (or an error is raised) – equivalent to a contract between the calling routine and the executing routine. C, et al have the inline if-then-else and expression level assignment – both of which are code reducers, and potentially simple enhancements to the basic pascal syntax.
Regards
Jonathan Bishop
Managing Director
|
|
Bishop Phillips Consulting | Melbourne, Australia –
Vancouver, Canada
|