Hmmm....

You guys are not listening again... It would be useful to us developers for this to be a GEN error (not even a warning). It would help us to not spend time looking for stupid bugs where 1 = 2, and you would never expect that.

In relation to 'not listening', you are just making me (and probably others) more and more worried that when we get our development env. VIP and we are all forced to go to it and not to be able to write our own, that you will not listen to us then. Therefore, if the developers want something you'll just say 'Its not a bug' or 'We will change the documentation' or 'No response'.

Don't you want to make your language 'better' than Perl,COBOL or Fortran, or is this kind of 'bug' too hard for you guys to fix?

Rob D

Hi,

I believe you!!!

Bit of a bug with backslash n getting interpreted by either perl or the browser.

I'm going to upgrade the site soon with a few bug fixes so I'll try and get it done for then.

Or... maybe... this is not a bug and ...

Rob D

Ralph,

One tiny but fundamental point: C, Perl, et al are fairly low-level 3GL's, so if that happens in some versions of those languages I'll be a bit upset but not too bothered.

BUT PRO-IV is a 4GL. 3 = 2 being TRUE is NOT ACCEPTABLE, we're not talking about playing with memory locations and conveniently being able to use pointers and variables to reference and de-reference them, we're talking about being able to rely on a logic statement that says

IF #A = 3 THEN ...

being reliable - if #A = 2, it should NEVER be true. EVER. No argument about semantics of 3GL's. It's a design flaw in the handling of global function calls, and it needs to be fixed. It shouldn't even be that hard to fix

So it's a bug.

Dan Shannon

Dont know about Lisp & Perl but I can tell you from my experience that you cannot change Cobol literals. Mind you I only started programming in 1968 so I may be wrong. The entire point about this bug is that it is a bug, not a feature, and should be fixed immediately as it has a huge impact.

Could we at least agree that it is a hole if not a bug ?

PRO-IV may not be able to send some 6 shovel-toting, yellow vest wearing men around to fill the hole at this point in time. However, I would humbly ask that they dispatch a few more cones and flashing lights for use around the hole as a warning to those of us about to step into it.

Sigh.

Ability to modify a literal is not an INHERENT feature of call-by-reference. Is is POSSIBLE to have a language with call-by-reference which protects you from damaging your literals.

When I provocatively said 'self-respecting' language, I should undoubtedly have said 'language suitable for developing large, reliable, commercial applications'.

I would say that Lisp and Perl are not suitable for developing such applications (at least as the main tool). COBOL clearly was designed for that purpose and although I am not a COBOL programmer I would have been very surprised if most COBOL environments had the 'fault' we are discussing (I was thus relieved to see Macolm Fell's post).

You can simulate call-by-reference in any language which has pointers. Passing the value of a pointer in C provides the same capabilities and the same problems as call-by-reference. Whilst I am not famililiar with the original Stroustrup Cfront implementation of Cplusplus, it was a C code generator and I imagine must have implemented references using pointers.

Of course it is possibly to do many horrible things in C. These horrible things are not desirable and not useful. Features like const help one to protect oneself against these design oversights in the original language.

That's the key issue here - modifying a literal is very dangerous, very confusing and completely useless. As such it would be much better if the language prevented it or allowed the programmer to prevent it.

Rob, Your javascript popup for no email address crashes Konqueror. And escape in explorer loses your text. As a linux/vi fan this is a bit of a problem! It also doesn't let you post without an attachment

>You can simulate call-by-reference in any language which has pointers. Passing the value of a pointer in C provides the same capabilities and the same problems as call-by-reference. Whilst I am not famililiar with the original Stroustrup Cfront implementation of Cplusplus, it was a C code generator and I imagine must have implemented references using pointers

Call by reference and call by pointer are NOT the same

e.g

int callbyref(const int& v); // C plus plu
int callbyptr(const int* v); //

callbyref(1); //Legal Cp
callbyptr(1); //Legal C but it doesn't do what you want
callbyptr(&1); //Not legal

To achieve what you want in C you have to use a temporary

int tempvar=1

callbyptr(&tempvar)
callbyptr(&tempvar)

If callbyptr didn't take a const the second call could appear to have the literal redefined

Developer Studio does generate a gen warning for global functions if you pass a literal that you can change. Note that it doesn't generate a warning if you pass an input only variable which is the only instance that really makes sense although you can imagine perverse circumstances where you might genuinely want to pass a literal because you know it won't change for the particular parameters you are supplying in the particular case. Hence a warning does help those who do it by accident but doesn't hinder those who really know what they are doing

Developer Studio doesn't generate a gen warning for Global logics. Maybe it should but this is a slightly more difficult situation to handle properly. The only obvious solution is to make a separate copy of the 'literal' before passing it to the global logic but this will involve some performance hit. Currently the developer can make a copy of the literal into a scratch variable if they want to change it but don't have to suffer the overheads if they don't.

From the National Press...

'The trials and tribulations of NASA continue.

Following earlier blunders they contacted the world's leading mathematicians and scientists to ask if 5 could equal 7.

Representatives of the much respected high level programming language ProIV, said, 'Of course it does'.

Leading members of the 'C' community couldn't agree and went off in search of life on other planets having lost track of their own.

Following conflicting advice the Chief Controller at NASA in desperation asked his three year son.

Chief : Son, does 5 equal 7?
Chief's Son : Dad, don't be a donkey, 5 equals 5 I learnt that in kinder garden last week. Johnny told teacher that 5 equals 7 and she put him in the corner of the room for a whole afternoon.
Chief : Johnny is not so bright is he son.
Chief's Son : No Dad, he wants to do something with computers when he's older.'

PROIV does. The Developer Studio development environment explicitly warns the developer where arguments are being passed back to literals, which I think you will agree, is bad coding. This whole discussion thread only serves to outline the pitfalls of developing an 'alternate' development environment to the one supplied and supported by PROIV. As Rob stated, he works in a team of 25 developers, and they were able to track this down. If however, they had been using DS, they would have not got the fault in the first place. Can you imagine the support nightmare of a smaller development shop doing this and not being able to diagnose it and then calling PROIV support. Where do you start ?????

No one in our the team I work with wants to use DS.

There are reasons we do not go for DS.

It slows down development compared to PRO-AIDE and our utils. There are problems with it, for example, where you cannot 'cancel' because it says you must commit etc. and it is slowwwwww to navigate. Not many people like using DS.

Some have used it before, some have just looked at it.

In my development Env, I would fix this within about 5 minutes. I have no problem doing that and will.

It has probably taken the PROIV guys longer to argue about this than if they had just fixed it.

There is plenty of room for more than 1 development Env. and you guys should really try to understand that most people do not use DS.

And yes, we would have had this fault if using DS, because it only gives a warning , so someone can in theory accidentally enter it... Just like we accidentally put a literal as a parameter, it was not done on purpose.

Rob D

DS doesn't give the gen warnings if you turn the pre-gen checks off, if I remember rightly.

And since the pre-gen checks are generally irritating and slow you down, most people who I've seen using DS turn them off.

Please fix the problem, stop trying to justify yourselves.

If it was a Gen Failure, then any development tool would work.

As you are so keen on DS, Darren, I invite you to put a poll asking about it's popularity...go on I dare ya!

Dan, your memory does not serve you correctly. Developer Studio warns the developer at the time they define the literal (see attached). I do not want to drag this point out more than it has been already but the point that is trying to be made is that PROIV is NOT a scripted language like HTML,JAVA,'C' etc. It is a high level development language that translates parameters defined in source files into object code. This model is a very powerfull one but obviously relies on the the data in the source files being acurate. The old adage of Garbage In / Garbage Out applies. The 'gen' or compile process traps a large number of programmer error. It is, however, based on the premiss that the source code is in a reasonable state to begin with i.e. there are not alphas where it expexts numbers etc. and the development environment should not allow such instances in the first place. Just think of all the legal permutations of a PROIV program, never mind the illegal ones. Where do you draw the line????

Even if I were to concede this particular point becasue DS warns (which I don't as I use another tool also owned by ProIV which doesn't and have no desire to use DS!) how many other stupid errors like this are there floating around that no development environment warns about?

I'm sure we can be reasonably sure that VIP will at the very least warn about this after this thread but what about others like it that we don't find until later - will proIV then write all our little utilities to search the entire system bootstraps and find out the areas we need to change? I think the answer to that is probably no!

If something like this occurs in a 3rd party development tool then it's up to the supplier of that tool to sort it out - fine, but if it happens in VIP what the hell are we supposed to do without the bootstraps?? I really think this is far more of an argument towards public domain bootstraps than for VIP.

Cheers

Mike

Aha, I must be getting old! My plologies

It's still wrong to allow 1 = 2 in PRO-IV. As you say it's a high-level language, it SHOULD NOT ALLOW NONSENSE unless it's deliberately coded nonsense.

Allowing

GLOBAL_LSCALL(CHG1TO2,CALL)
IF 1 = 2 THEN UMSG('This can never happen',-1) ;

to issue the message is patently ridiculous. Why can't you just agree with that? Issuing warnings in one of 3 development environments (SL, @MODX, DS) isn't really a justification, it just says 'We know there's a problem, we're just not going to fix it'.

Could someone please point out how this behaviour could ever be construed as useful (not counting trying to win obfuscated PRO-IV competitions)?

Anyway, that's it from me. I can't handle this, it's too stupid. And Bond's on the telly.

Dan