On 14 Dec 2003 at 21:04, Frank Heckenbach wrote:

[...]

...

This is the error I get (with gpc-20030830): "delphibug.pas:4: error: string concatenation without `Concat' or `+' is an extension delphibug.pas:4: error: of GNU Pascal"

This error should not happen. If you remove the embedded condititionals, the program compiles fine both under BP and all versions of Delphi.

Yes. Will fix it later.

Ok. While you are at it, there is another minor one. This program: program athen; {$delphi} begin If ParamCount = 0 then; Writeln ('OK'); end.

generates a warning: athen.pas: In main program: athen.pas:4: warning: `;' after `then'

Should this warning be generated in BP mode?

Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

What possible reason could there be for suppressing it? The only use I can see for such a statement is to discard the return value from a function named ParamCount that has side effects, and that is much more clearly done with: "junk := ParamCount;"

I always wanted the extended syntax

nil := ParamCount;

to get the benefits of being able to throw away the return value with the clarity that you are doing so and without the necessity to create junk variables.

Enjoy, Peter.

"Prof A Olowofoyeku (The African Chief)" wrote:

On 15 Dec 2003 at 9:16, Peter N Lewis wrote:

...

...

What possible reason could there be for suppressing it? The only use I can see for such a statement is to discard the return value from a function named ParamCount that has side effects, and that is much more clearly done with: "junk := ParamCount;"

I always wanted the extended syntax

nil := ParamCount;

to get the benefits of being able to throw away the return value with the clarity that you are doing so and without the necessity to create junk variables.

Precisely. However, such an extension would then mean loss of compatibility with other Pascal compilers. I think I will just suppress the warning.

IIRC the original complaint, since snipped, applied to BP and attempted to use a null statement after a conditional. It seems to me that there is absolutely no need for such a statement in BP, since ParamCount begins life there as a global variable, and it would probably not be good form to redefine it.

As far as an extended throw-away syntax is concerned, I have seen far too many C failures due to ignoring a return value (especially malloc/realloc, but including fclose, printf, etc) than is comfortable, and I see no need to encourage such bad C habits in Pascal.

"Prof. A Olowofoyeku (The African Chief)" wrote:

On 15 Dec 2003 at 8:39, CBFalconer wrote: [...]

...

IIRC the original complaint, since snipped, applied to BP and attempted to use a null statement after a conditional. It seems to me that there is absolutely no need for such a statement in BP, since ParamCount begins life there as a global variable, and it would probably not be good form to redefine it.

This focus on ParamCount is a red herring. That was just a trivial test program (as Frank always emphasises) that shows the problem. ParamCount is not the problem here. Rather, it is the warning about a ";" following a "then" that was being highlighted.

My point, which I probably did not make clear, is that the only use for a null statement after a then is to discard something in the conditional part. Having discarded the need for this by using clearer methods, such a null THEN clause is clearly a programmatic error and a warning can only be useful.

Prof A Olowofoyeku (The African Chief) wrote:

On 15 Dec 2003 at 23:35, CBFalconer wrote:

[...]

...

...

This focus on ParamCount is a red herring. That was just a trivial test program (as Frank always emphasises) that shows the problem. ParamCount is not the problem here. Rather, it is the warning about a ";" following a "then" that was being highlighted.

My point, which I probably did not make clear, is that the only use for a null statement after a then is to discard something in the conditional part. Having discarded the need for this by using clearer methods, such a null THEN clause is clearly a programmatic error and a warning can only be useful.

I am not sure how something is an error, if it is something that I intend to do, does not cause my program to behave in a manner that I do not expect or want, and does not violate the language.

(I suppose "programmatic error" was meant as "bad style".)

IMHO having to create any number of junk variables just for the purpose of discarding things is undesirable. I don't see how it is "clearer" either. It ought to be pretty clear to anyone that the value is being deliberately discarded when a "then" is followed by a semi-colon.

In this case yes. But people (including myself ;-) sometime make mistakes and put an semicolon after `then' or `else' where it doesn't belong. The compiler can't distinguish the cases, and the resulting bugs are often hard to find (because one tends to overlook the semicolon even when checking again). That's why I (and probably others) appreciate such a warning. But if you don't, you can always turn it off (`-Wno-semicolon').

In this example, all I want is to try to go somewhere before doing something else, and I don't need to know (or care) whether it happens successfully or not, because it is of no real consequence either way. I of course want to clear IOResult, and I don't want any complaints. This scenario is of course contrived.

I guess "If ioresult = 0 then begin end;" is the way to go in order to satisfy all compilers ...

In this case I'd recommend `InOutRes := 0' which says what you actually want to do -- clear the state, not query it. This will avoid the issue here, but not in general.

...

What I could imagine is a built-in procedure `Ignore', `IgnoreValue', `Discard' or so which takes one parameter of arbitrary type and does nothing.

Or perhaps (but less preferable IMHO) a type-cast to `Void' (as in C) ...

Do any other compilers have something like that?

FWIW, Delphi has something called a Variant, which is type-compatible with all sorts.

I don't think that's suitable. We don't actually want to declare such a dummy variable (which would have to be global, so assignments could not even be optimized away). And since it doesn't accept all types (as stated in the Delphi description), it wouldn't be general enough.

I still prefer the built-in procedure.

Adriaan van Os wrote:

CBFalconer wrote:

...

As far as an extended throw-away syntax is concerned, I have seen far too many C failures due to ignoring a return value (especially malloc/realloc, but including fclose, printf, etc) than is comfortable, and I see no need to encourage such bad C habits in Pascal.

I agree with that. Worse -- the whole Win32 API (and some of the later parts of Mac OS) are based on this bad habit. Many Win32 functions return values that are useless in most situations, simply because in C they can be ignored. Some functions return an error result code, but never consistently. The result is of course instable software, because very few programmers pay attention to all the details if tricky and variable from situation to situation.

Bad habits in programming tend to get worse all the time and then the final result is invariably a total mess.

I beg to differ. Error status results (as in `malloc', I/O functions etc. in C) are serious indeed. But in GPC many of them cause runtime errors instead anyway (which can be caught, but only by explicit action, not by ignoring a function result).

There are other functions which really return unimportant results -- e.g., some of the CString routines return a pointer passed as an argument back. This is to facilitate chaining them, but ignoring the result is perfectly safe as well. GPC now allows declaring such functions with the `ignorable' attribute, and many such functions in the RTS and included units are declared so now. So there's no problem either -- GPC will simply accept both procedure and function style use.

(Typical C functions fall in one of these categories, and when writing a Pascal interface it's useful to distinguish the cases by giving or not giving this attribute. Of course, this can never be automated by any header converter, since it depends on the semantics of the C functions ...)

But it occasionally happens that you want to ignore another function's result (or some other value, for that matter) -- of course, after due consideration whether it's safe to do. That's where a built-in ignore procedure would come handy.

Frank

contrary to expectations. The cure is to make revstring a void function, or a procedure in Pascal. Moral: discarding function results should be awkward.

I don' mind it being a bit awkward, but I dont see the need to further complicate the issue by adding dummy variables.

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.

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).

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.

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. The most you could do would be put up an alert or an assertion, but even as mad keen on assertions as I am I can't image putting an assertion from every single case whether an almost useless function (eg one where the user would hardly or never detect whether it was called at all) might return an error. Peter.

CBFalconer wrote:

This can lead to unexpected and baffling errors, especially in C. My classic example is:

char * revstring(char *s) { /* whatever, to reverse string in place, and return s */ }

....

char thestring[] = "whatever";

printf(""%s" "%s"\n", thestring, revstring(thestring));

which should print out:

"revetahw" "revetahw"

contrary to expectations. The cure is to make revstring a void function, or a procedure in Pascal. Moral: discarding function results should be awkward.

That's not primarily a problem of ignoring function results, but of (a) the existence of functions with side-effects and (b) mistaking semantics (in particular, thinking of C strings as string values rather than pointers).

(a) is inherent in Pascal as well. We could discuss whether functions should have been defined as having no side-effects, but this would be an academic discussion since we won't change the basics of Pascal.

(b) is true whenever using C strings (and in some other situations). That's why I generally recommend to avoid them. But if you use them, you'll just have to remember to look at semantics more carefully (which not every C programmer does which leads to strange errors, sure ...).

Frank

Peter N Lewis wrote:

...

What possible reason could there be for suppressing it? The only use I can see for such a statement is to discard the return value from a function named ParamCount that has side effects, and that is much more clearly done with: "junk := ParamCount;"

I always wanted the extended syntax

nil := ParamCount;

to get the benefits of being able to throw away the return value with the clarity that you are doing so and without the necessity to create junk variables.

Yes for semantics, no for the syntax.

`nil' is a constant, and it's of pointer type. This assignment would violate both rules (and basically create a completely different thing by the same name). I don't think we should follow the example of some other languages to squeeze out the last bits of unused syntax (usually accompanied by worse error recognition).

What I could imagine is a built-in procedure `Ignore', `IgnoreValue', `Discard' or so which takes one parameter of arbitrary type and does nothing.

Or perhaps (but less preferable IMHO) a type-cast to `Void' (as in C) ...

Do any other compilers have something like that?

Frank

Prof A Olowofoyeku (The African Chief) wrote:

Ok. While you are at it, there is another minor one. This program: program athen; {$delphi} begin If ParamCount = 0 then; Writeln ('OK'); end.

generates a warning: athen.pas: In main program: athen.pas:4: warning: `;' after `then'

Should this warning be generated in BP mode?

I think so. It's just a diagnostic. The construct is also valid in standard Pascal. You can use `-Wno-semicolon'.

For full BP compatibility turn off all warnings as BP has none (not really recommended ;-).

Frank