Rick Engebretson wrote:
Frank Heckenbach wrote:
Rick Engebretson wrote:
The EXPECT extension to TCL is made for controlling and communicating with other user specific programs. Pascal user specific programs would be perfect.
TCL was developed at UCBerkeley and Sun. Expect was developed at the US NIST. Nice, stable, well documented, public domain software.
Pascal is the weak link. You are very talented people with GPC. I really appreciate CBFalconer's concerns.
I'm sorry, but your mail is rather vague. I use Pascal (GPC) programs for various purposes all the time, including being called by as well as calling shell scripts or binaries written in other languages etc.
I use expect rather rarely, since for normal tasks, a shell (sh or bash) script seems less overhead and more portable. (And with one slightly more complex expect script, I had problems between expect versions which I never really figured out.) Expect's main use to me is when you need to control pseudo terminals. Anyway, I see no particular problems calling GPC programs from expect scripts.
What exactly are you calling for?
I think my first email described TCL and Pascal, quite some time ago. I've pushed various TCL extensions that add different things, especially on the linux platform. My message is consistent from the start and exactly reflects the TCL shell design and interface philosophy.
I don't doubt it's consistent, but please keep in mind that I can't remember all your previous messages when reading this one. (My memory is limited too. ;-)
Brent Welch's books are great references. TCL adds functionality by linking in packages, just like pascal is supposed to. They don't seriously mess with the core.
OK, well, GPC allows this too. Whether BP units or EP modules (the difference is mostly syntactical), they work and are widely used.
FPC has dozens of units. A Linux unit, ncurses unit, IPC unit.....
We probably don't have as many units, true, but it's up to everyone here to improve this. I have released several units on my web site (fjf.gnu.de) and probably will write more in the future, others do the same (partly on the "contrib" pages on the GPC web site which is unfortunately not available ATM, partly on their on web sites).
(BTW, please note that writing such units already requires some non-standard features. E.g., almost every interfacing to C code or OS directly does so, because it needs C-compatible or fixed-layout data types which ISO Pascal doesn't guarantee. Some interfaces need a way to treat arbitrary structures as a block of bytes, i.e. an untyped block of data. As Scott will point out if he reads this, it is possible to do such conversions in standard Pascal, but realistically, converting, say, a large integer array to an array of bytes by means of div and mod is not exactly the most efficient thing to do, compared to a type conversion with no actual data movement. Programs called from the shell or TCL scripts often need to access command line parameters, sometimes environment variables which ISO doesn't support. Of course, there are other dialect features that are not really needed, and sometimes are evil, and which I try to avoid too. But we have to acknowledge that ISO does have its limitations, though less than often assumed, and restricting ourselves to pure ISO Pascal won't work for many of us, including myself.)
And documentation....
That may be GPC's biggest problem. Again, it's up to everyone to help improve it. Realistically, I won't be able to do much, apart for smaller local changes, as I'm too busy with other things. I fear the same holds for many others here, but discussing the misery won't improve it either ...
What I'm calling for is this; If you want to work with a proprietary pascal vendor, that is your priviledge, and I'm sure it will be a great product. But why drag Gnu Pascal into this new business venture ??
How is it new? As I wrote recently, GPC has been doing this for ~10 years, and non-standard Pascals have existed for more than 20 years. We all know the unfortunate history of non-standard Pascal, and we can't just pretend it wasn't so.
Sure, we could write a pure ISO compiler. But how many people would use it?
A simple, core Gnu Pascal conforming to well defined standards is all I have asked for from the start. You have made progress to this end. I don't need flag bloat, and bells and whistles and "implicit pointers". For instrumentation, I need a pascal I can trust.
If you're worried about stability, you can actually help preserve and imrpove it. Even if you don't want to hack the compiler itself, you can write test programs. If you do this in the form required by our test suite (see the manual) and submit them so us, they'll help us ensure the tested features won't break, even if we add other stuff. Whether these test programs are just about ISO 7185 or 10206, or your own selection of features, that's just fine. And if you come across GPC bugs in the process, we'll try to fix them ASAP.
Frank