Pete's Dumb Idea of the Day! - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11) +--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2) +--- Thread: Pete's Dumb Idea of the Day! (/showthread.php?tid=3147) Pages:
1
2
|
RE: Pete's Dumb Idea of the Day! - TDarcos - 10-23-2024 (10-21-2024, 10:15 PM)TempodiBasic Wrote:I prefer something like TempodiBasic's solution to Pete's because it avoids one thing: adding "proprietary" extensions to the language. (I offer a simple alternative solution later in this posting.) Yes, I know QB64PE is open source, but I'm using it in a more classic sense: when one compiler/interpreter adds new features to the language, new keywords, new operators, etc. This now means that programs using that dialect of the language can't port it to a different compiler. Which can defeat the whole purpose of using a standard language. Which can lead to other issues. I have a bit of a long story to explain why it's not a good idea.(10-21-2024, 07:53 PM)Pete Wrote: Wouldn't it be nice to have this feature for Data Restore?Hi Pete Up until the late 1980s or possibly the 1990s, what was the most popular programming language in the world? I would say, hands down, no question, it was COBOL. Since up until the early 1980s there were no microcomputers other than ones intended for hobbyists, experimenters and home use. Business use was very rare. So what businesses had, were minicomputers and mainframes. And what programming language was available on all of them, in essentially the same dialect? That's right, COBOL. The reason being was in the mid 1950s, the U.S. Department of Defense (DOD) was sick and tired of having thousands of computers using dozens or hundreds of programming languages, and wanted one it could standardize on. So, in 1959, a committee was formed to develop one, led by Dr. Grace Hopper. Hopper, who then was a lieutenant in the U.S. Navy, aggressively pushed for the development of a standardized language that ordinary people could use, and would make business sense for use by civilian businesses. This became COBOL. Now, effectively every major computer manufacturer was involved in this, but for new ones, how to get them to offer the language? Very simple. The DOD announced that they would not buy any new computer unless it had a COBOL compiler. Now, everybody having a COBOL compiler was fine for the government, for the manufacturer, how do you distinguish your computer from everyone else's? Well, add new features and add proprietary enhancements to the COBOL compiler to take advantage of them. Well, this means programs again are being made non-transportable to other company's machines, so then the DOD promulgated a new rule: to be able to sell to them, your COBOL compiler had to be able to process ANSI Standard Cobol, and while you could still offer proprietary extensions, there had to be a compile-time switch to tell the compiler to accept programs that only used the standard language, and flag non-standard usage. So even 60+ years ago it was understood that adding special features makes it difficult to move programs elsewhere. Please do not fall for the siren song of adding "just to be nice" features when existing ones will do the job. And now, as I mentioned earlier, my suggestion on a solution: Code: (Select All)
Maybe I'm different, but I think it's simpler to understand, easier to implement, and keeps everything happening together in one place.
RE: Pete's Dumb Idea of the Day! - SMcNeill - 10-23-2024 Why not just make this the simplest thing in the world? Just read it into a set of arrays and forget about it. Code: (Select All)
There's no need to ON x RESTORE label1, label2, label3, label4. You read that data into your array, stored it there, and now it's indexed via that array. Doesn't get any simpler than that. RE: Pete's Dumb Idea of the Day! - TempodiBasic - 10-23-2024 (10-23-2024, 01:01 AM)Pete Wrote: Well with Select Case you would use... Yes Pete you're right please pay attention to the fact that the FOR loop starts with a value 0 that hasn't been managed by Select case and it triggers a runtime error, while in the complex and tortuose way of ON x GOSUB ... RESTORE /RETURN it goes on. In other words, 0 has been used to simulate an unpredictable value of X. Using Select case you must sure that X takes always a predictable value. Using the tortuose way you can avoid this task of predictable value. All the good and clever ways posted here need to know how many data field are in the code and must sure that it would be used the range of that value in the code. Please pay attention: the tortuose way is not better than the others, but it is nearer old fashion way of coding when DATA was a new great opportunity to bring informations into code. And in my mind DATA is a good resource of the past. It's fun and useful getting infos and experiences of professional coders. RE: Pete's Dumb Idea of the Day! - Pete - 10-23-2024 I'm glad to see Steve's apple crop is coming in nicely, but out out here in CA working with oranges! For some of my apps I use arrays, for some databases, and for some I use data statements. I mentioned apples and oranges because I was using data1, data2, and data3 as labels. Steve is using three data statements followed by numbers. TDarcos posted what I posted on the previous page, the Select Case method to use Restore. So basically for user input routines, we can have... Code: (Select All)
Pete RE: Pete's Dumb Idea of the Day! - SpriggsySpriggs - 10-23-2024 Here's an example of how I like loading my data: Code: (Select All)
Code: (Select All)
RE: Pete's Dumb Idea of the Day! - CharlieJV - 10-23-2024 (10-23-2024, 11:19 AM)SpriggsySpriggs Wrote: Select Case UCase$(DataName) Just because it helps me with focus/distraction and managing challenges with cognitive overload and overstimulation, I added this kind of ability to BAM: Code: (Select All) Restore Eval( UCase$(DataName) ) "Eval" not being a function, but just a keyword to let the implementation of "Restore" know that what is coming is not a line labels. RE: Pete's Dumb Idea of the Day! - Pete - 10-23-2024 I've loaded data into arrays using pretty much the same method as Spriggsy, so +1 for posting the example. I thought about posting what Charlie just implemented, because it does cover using Restore with strings, however it won't substitute for an On Restore statement. Still, a nice implementation of string variables to decide what data label to restore. + 1 Fun discussion, Pete RE: Pete's Dumb Idea of the Day! - CharlieJV - 10-23-2024 (10-23-2024, 05:37 PM)Pete Wrote: I've loaded data into arrays using pretty much the same method as Spriggsy, so +1 for posting the example. Well, that EVAL clause accepts numbers too, so happy with numbers for line numbers instead of strings for labels. The main reason for EVAL was to not be tied to an index (i.e. 1, 2, 3 etc.) when an index is a pain in the rear. So I could have a GOTO/GOSUB/RESTORE that will Branch to, say, a concatenation of x,y coordinates. Code: (Select All) branchline$ = 'x' + STR$( POINT(0) ) + 'y' + STR$( ( POINT(1) ) Definitely not "standard" BASIC, but I'm building a BASIC I wish had been there for me right out of the gate. Easy to do when one is one's own one-person standards committee? Oh sure, I can have some pretty wicked arguments with myself ... RE: Pete's Dumb Idea of the Day! - Pete - 10-23-2024 I never win arguments with myself... So I've learned to accept my own advice! Pete |