Page 1 of 1
[Implemented] Undeclared Variables
Posted: Sun Mar 23, 2003 1:13 am
by BackupUser
Restored from previous forum. Originally posted by JohnDeHope3.
Does 3.61 provide a way to prevent undeclared variables from being automatically declared? What I mean is when you use a variable without first declaring (specifically, explicitly) it's data type.
Respectfully, as a teacher, I am waiting on this capability before I purchase PB. My students simply misspell their variable names too often, and their code happily keeps running, despite the fact that they have made a massive logic error.
(Implemented as 'EnableExplicit')
Thanks Fred
Posted: Sun Mar 23, 2003 5:14 am
by BackupUser
Restored from previous forum. Originally posted by El_Choni.
I think of it as a feature. What's wrong about your students' code running instead of crashing? I know that in real life they'll have to use C (damn it!), but it's not bad for them to know that there are better solutions to coding in C.
El_Choni
Posted: Sun Mar 23, 2003 9:46 am
by BackupUser
Restored from previous forum. Originally posted by Pupil.
This has been asked for before and i think Fred(the author of PB) has said that it is on his TODO list. Personaly i don't think it will be implemented until PB 4.0 (the planned compiler rewrite) comes out, this is just my opinion and may or may not coincide with Fred's plans.
Back to your question, there might be a way to have type check on current versions of PB, but mind you that it's a workaround and perhaps not as nice as having type checking build into the compiler. What you can to is simply use structues for all your basic types as well, so you could do something like this:
Code: Select all
Structure Long
Long.l
EndStructure
Structure Word
Word.w
EndStructure
; ... and so on
; Now you declare all you variables with these new structures
; instead of the basic types, then the compiler will complain
; if you're using an undeclared variable.
; Example:
variable.Long\Long = 120
variable\Long = varable\Long + 30 ; Undeclared var
debug variable\Long
It's a soultion maybe not a nice one but it's all you can do at the moment though, unless you write a pre parser yourself that do the checking...
Posted: Sun Mar 23, 2003 12:48 pm
by BackupUser
Restored from previous forum. Originally posted by fred.
Yes, it's planned.
Fred - AlphaSND
Posted: Sun Mar 23, 2003 3:45 pm
by BackupUser
Restored from previous forum. Originally posted by geoff.
What exactly are you planning Fred?
Will we have to insert a list of variable declarations at the head of all our procedures? Or will we need to use the type extension at first use? Or will this be optional?
The Help file says:
Variables do not need to be explicitly declared, as they can be used as "variables on-the-fly"
Should the Help file say?
But this will be changed in the future
I'm not too concerned whether we do this one way or the other, what concerns me is unexpected changes to the language. Changing code is an overhead, an no matter how carefully you check it, you inevitably introduce bugs. These take time to find and during this time you have unreliable code.
When I read things like this I am left feeling that I shouldn't use PureBasic now, but wait until the rules of the language stabilise.
Posted: Sun Mar 23, 2003 3:50 pm
by BackupUser
Restored from previous forum. Originally posted by freak.
I guess there will be a compiler switch for that, so no problem for old sources.
Timo
Posted: Sun Mar 23, 2003 4:03 pm
by BackupUser
Restored from previous forum. Originally posted by JohnDeHope3.
GEOFF Said: "When I read things like this I am left feeling that I shouldn't use PureBasic now, but wait until the rules of the language stabilise."
Hehe. It will never stabilize because Fred will always be improving it. Improvement requires change.
PUPIL: That's an interesting workaround that I hadn't thought of, thanks!
Posted: Sun Mar 23, 2003 4:14 pm
by BackupUser
Restored from previous forum. Originally posted by fred.
Yes, it will be a new '/EXPLICIT' switch, and 'Enable explicit variable declaration' in the compiler option panel of the IDE.
Fred - AlphaSND
Posted: Sun Mar 23, 2003 4:29 pm
by BackupUser
Restored from previous forum. Originally posted by geoff.
Excellent Fred.
I don't believe the trite statement, Improvement requires change Nor do Microsoft. I have Win3.1 software that still works perfectly under Win XP.
OK, sometimes changes have to be made, but with a sensible initial specification and a little forethought this should be the exception, not the rule.
Posted: Sun Mar 23, 2003 4:38 pm
by BackupUser
Restored from previous forum. Originally posted by JohnDeHope3.
GEOFF said "I don't believe the trite statement, Improvement requires change Nor do Microsoft. I have Win3.1 software that still works perfectly under Win XP."
Right, your old Win3.1 software has not changed, nor has it improved, it works just as it did all those years ago. No improvement and no change. But I think it is impossible to show an example of improvement where there isn't any change. My trite statement wasn't an idea or a theory, it was an observation about reality.
FRED: I can't wait, woohoo!
Posted: Sun Mar 23, 2003 5:35 pm
by BackupUser
Restored from previous forum. Originally posted by JohnDeHope3.
GEOFF: I think I see where we are missing each other. You are using the word "change" to mean something more specific than what the word actually means. By your examples it seems you mean "change" to be the "breaking of things that used to work". That certainly is one change, but it is too narrow a definition of change. Think of all the changes you left out of your examples: the gui of XP, the need for new picture tubes to be designed in televisions. You can't redefine "change" as "breaking old stuff".
You are correct, in that if you define change this way, then my statement is trite and wrong. But this is not what the word means, so I stand by my observation.
Posted: Mon Mar 24, 2003 3:44 am
by BackupUser
Restored from previous forum. Originally posted by Revolver.
(I haven't read any of the other posts here except the first, so excuse me if this has already been mentioned)
I agree this would be a good feature, but your argument that your students misspell variables names resulting in "massive logic errors" isn't a very strong argument! Compiler syntax checkers are for just that, checking syntax! If there was a compiler that could catch all the logic errors I made, I would be in heaven!
But like I said, requiring variable declarations would be a good feature, to help *prevent* logic errors
Posted: Fri Mar 28, 2003 8:28 pm
by BackupUser
Restored from previous forum. Originally posted by Amiga5k.
I'm fairly new to PB, so forgive me if this has been mentioned before..
Change is important sometimes. Actually, a better word would be progress. I think we would all agree that progress is more important. But change can be bad if it frequently breaks old code.
When commands are superceded by newer commands AND that old command is removed, then this can cause major headaches for the programmer. From what I gather, the way this is handled in the C/C++ world is that (as it relates to Win32 programming) when a command is replaced/superceded by another, the old command is still available but the docs will say that is has been replaced by such-and-such. That way, old code will still compile and the new command is available too.
Does source code written for PB version 2.x still compile under 3.62? Just wondering.
Russell
***Commodore 64 - Over one million cycles per second, 16 vibrant colors, 3 incredible audio channels and 38,911 Basic Bytes Free! Who could ask for anything more?***