Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Variable Names
#11
mnrvovrfc - it was an error warning in my coding. I should have had the variable a1 and not 1a.

So it actually goes back to the width of 2 Roman war horses asses. thanks
Reply
#12
It reminds me of what little I read of the REXX processor in OS/2. :/

Could have code like this (sorry not familiar with this "batch" language):

Code: (Select All)
hello = 4
SAY hello everyone

Then "hello" would stop printing "hello" and instead the value of the variable of the same name. But I'll bet that was hell to parse for whoever created the "batch" language.

It must have required two or more passes, which I don't think was how the MS-DOS batch file processor worked. If not then be forced to look at every single token (except keywords and operators) to see if it happened to be a variable. (shrugs)

To scan something like this:

Code: (Select All)
DIM 20D AS LONG
20D = 50
A = 20D

would require some kind of preprocessor, or at least one extra pass only to pick up "special" variable names. Might as well allow also symbols like dollar sign and ampersand to be the first character of an identifier in that case. The problem with that is it would make compilation even slower, which is not tolerated very much except with C/C++ only because that is ubiquitous.
Reply
#13
it would be interesting to have support for Unicode characters, I think that python supports it
<edit> it's Julia that supports Unicode
julia> ?=123
123

julia> ?*2
246

julia> ?=456
456

julia> ?*?
207936
unfortunately this forum lacks the support for the above Unicode characters, the first 2 lines are thumbs-up and the next 2 a big-grin
Reply
#14
At one time Lua supported Unicode characters into identifiers, especially vowels with accents like it's common in Italian and Spanish. Also "c" with cedilla which is used in many Turkish words and other languages. But eventually that support had to be removed because it was causing a lot of trouble. Not necessarily because people used the interpreter on computers only capable of running WindowsXP or even older. In many cases there was C/C++ code to maintain and that required fighting with "locale" setting, which was usually set to English. That sucked for many people whose first language isn't English, which forced them to use their preferred language only in comments and which also forced them to use text editors that supported Unicode.

Julia is truly a modern programming language but one has to remain in that camp entirely. For example, using VSCode/VSCodium to compose programs for it. Many symbols used in Julia were actually demanded by mathematicians and scientists and people like that; they would have refused to use a programming language that didn't otherwise, no matter eg. how many places and how fast it could compute the circle-number. QB64PE and Lua rather recall the past. Python might be somewhere in between. It might not support Unicode in identifiers because many programmers are lazy, they just want the code to work and their great nightmare is hours of debugging.

I could reveal my experience with a music-creation application that I had used a lot 10 years ago but sadly, cannot use it any longer because it "loves" WindowsXP. Actually there's an "alpha" release of it now but the developers changed a lot of stuff, and have to use it on clunky Windows10 and therefore I'm not comfortable with it anymore. This application developed a problem showing the open-file requester because of an Unicode problem. It took about three years and three minor releases of the program for the developers to get to the bottom of it. This problem was a hinderance to work flow in that application. The head developer's favorite language is Spanish (maybe one of the dialects from Spain) which might have had something to do with it, as he had to deal with the C/C++ "locale" set to English as was necessary because the developers were stuck using Microsoft Visual Studio.
Reply




Users browsing this thread: 2 Guest(s)