A horrible bug....
Posted 17 July 2001 - 06:21 PM
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?
Posted 17 July 2001 - 06:27 PM
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 ...
Posted 17 July 2001 - 06:44 PM
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.
Posted 18 July 2001 - 01:15 AM
Posted 18 July 2001 - 04:53 AM
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.
Posted 18 July 2001 - 08:54 AM
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.
Posted 18 July 2001 - 11:45 AM
>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
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
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.
Posted 18 July 2001 - 12:59 PM
'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.'
Posted 18 July 2001 - 04:12 PM
Posted 18 July 2001 - 04:35 PM
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.
Posted 18 July 2001 - 05:13 PM
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.
Posted 18 July 2001 - 05:38 PM
Posted 18 July 2001 - 07:07 PM
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.
Posted 18 July 2001 - 07:12 PM
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.
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.
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users