Paul Isaacs wrote:
As it is I was thinking function-access would be accessing a function, not a return value. Component-function-access with array and records was providing clues but I just couldn't figure out the meaning.
Am I correct in now thinking that 10206 will not provide any way to get the address of a function the way that the @ extension does in gnu pascal without the --extended-pascal restriction?
In ISO Pascal you have variable parameters and procedural parameters. They allow you to do most things possible with address operator, but not all and in a different way.
I am chugging away writing a 10206 compliant compiler using GNU pascal and suddenly thought that using extensions to enable the writing of a compliant compiler was not a great way to advertise 10206. I recognize that the extensions are there because they are useful - but - do they also flag 10206 as a poor standard to use?
Well, 10206 was deliberately limited. Practically, decent compiler should allow writing runtime library. But ISO 10206 misses extentions needed for writing functions like 'new'. This does not mean that this is poor standard, just that for some purposes you may need extentions.
I am hesitating to use extensions because the target of the compiler will be embedded processors.They are problematic to debug so you want to have the compiler produce code that is as bug free as possible. I though that sticking to the standard would be the safest thing to do.
The Arduino and Raspberry-pi users will be attracted to a compiler that is safe but does not have a language as challenging to learn as ada.
I was using the @ operator to jump back to a known place in the parse to re-sync after a syntax error. I will use jumps if I have to but they are far from handy.
Some comments:
- I would just abort parse after first syntax error, so no need to re-sync - @ operator alone is safe. One can even claim that it is less error prone than var parameters. What is unsafe is pointer arithmetic as typically done in C (one can implement safely C pointer arithmetic but due to slowness and incompatibility with common practice safe implementation it is almost unused). - For Arduino you will need extensions to access hardware and on Raspberry Pi you will need to access foreign libraries.