Peter N Lewis wrote:
Adding a dummy variable in the variables section does not make the code:
dummy := revstring(thestring)) any clearer than nil := revstring(thestring)) or ThrowAwayResult( revstring(thestring)) )
Personally, I think the middle one is the clearest - it is clear that revstring is a function returning a value and clear that it is being discarded.
I already stated the problems I see with this syntax. Unlesss you can address these concerns, just repeating the suggestion is quite pointless.
The first one is unclear in that the value might possibly be used later (and indeed some crazy graduate programmer might come along later and modify the code to use it without changing the name of the variable).
Agreed.
The last one is also unclear as to what, if anything, ThrowAwayResult actually does, whether a procedure really gets called or whatever - only reading documentation and looking at the assembly code would explain this.
Well, if you're so paranoid about optimization, you'll always have to read the assembly code, anyway. ;-)
If you don't trust the programmer of the RTS (or any module used) to not name a procedure `ThrowAway...' or `Ignore...' and not really ignore things, you could just as well be paranoid about any `+' or `=' operator having been overloaded or any number of other things ...
I don't know, but if your concern is that anything that looks like `identifier (...)' might be a routine call, my advice is to "get over it". It's already not true in C (think of macros and inline functions), even less so in Pascal (built-in routines, also inline routines (which any Pascal compiler is free to use), type-casts (BP), macros (GPC), etc.).
Also the converse is not true -- neither in C (again, macros), and even less so in Pascal (routine calls without arguments, implicit calls e.g. for string assignments, some built-in operators e.g. string `+' and many set operators (EP), user-defined operators (PXSC), macros (GPC), etc.).
What I want to say it that associating a syntactic pattern with some runtime behaviour is in general misleading (already), so I don't see this as an important argument against using such a pattern.
Indeed, I prefer such a pattern because it entails no new syntax. A user of another compiler could implement it by defining a regular procedure (sure, with an untyped argument (BP)). This might be worse at runtime (if not inlined), but in contrast a new syntax could not be emulated in Pascal code at all, so would be more incompatible.
Regardless, we live in a world with C programmers who return pointless errors because they can throw them away easily (and indeed clearly when using the (void) syntax), and it is a world we need to deal with. For example, what exactly are you to do if disposing an object returns an error? Or closing a readonly file returns an error.
Can this actually happen? It can't be excluded since the `close' function is the same for read-only and other files, and for other files it can indeed cause an error.
As I said, error status codes are not the main concern in Pascal, because they're (usually) not returned as function results but cause runtime errors. These can be handled more globally -- e.g., in batch style programs the default behaviour (aborting with an error message) is usually just fine; for interactive programs you might prefer to catch all I/O or all runtime errors, print messages in a suitable form and continue or shut down cleanly. In both cases, you don't have to worry about every single possible source of errors -- if closing a read-only file doesn't ever cause an error, fine, and if it does for some reason, the general error handling strategy should apply just the same.
Frank