Announcement

Collapse
No announcement yet.

Problem reading DATA

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem reading DATA

    I've encountered a most annoying problem, that being the inability to store constants in DATA statements and read back the numeric values they represent. I understand this is because any non-numeric DATA statement "value", quoted or unquoted, is interpreted as a string. I would like to suggest that this be remedied in the next PB/DOS by either;
    * Creating an EVAL or similar function to enable evaluation of a string, which in this case could be used to return the numeric value a constant name represents, or
    * Altering the function of the READ statement so that non-numeric "values" are checked to determine if their first character is a % (or $ for string constants ) sign and if so, the "value" can be interpreted as a constant and the value the constant represents be returned instead of the name of the constant (as a string)

    Come to think of it, an EVAL-type function would be useful in many other situations - please ensure that it is put on "the list" for consideration.
    If you try to make something idiot-proof, someone will invent a better idiot.

  • #2
    Because PowerBASIC is a true compiler, there are no variable or equate symbol names in the compiled code - they are only used by the compiler during the compilation process.

    Therefore, it is not possible to implement such a suggestion in PowerBASIC. It would be quite possible to implement such a feature in an 'interpreted Basic' dialect.

    If you want to be able to determine a given target "value" for a given "index" value, then I suggest you use an array to hold the possible values you need to return at run-time, or consider using a disk-file to hold the information. Whicle these require additional coding to implement, they have the advantage of being truely "random-access" - something that is difficult to implement with DATA statements.

    If you can describe what you want to achieve, then we may be able to offer more definitive solutions.

    ------------------
    Lance
    PowerBASIC Support
    mailto:[email protected][email protected]</A>
    Lance
    mailto:[email protected]

    Comment


    • #3
      Because PowerBASIC is a true compiler, there are no variable or equate symbol names in the compiled code - they are only used by the compiler during the compilation process.
      So why can't constants in DATA statements be replaced at compile-time then?
      If you try to make something idiot-proof, someone will invent a better idiot.

      Comment


      • #4
        You are asking for two things:
        1. String and/or float equates (constants)

        2. "EVAL" to convert DATA from READ statments.

        #1 you'll have to speak to Carmel.

        #2. How 'bout VAL?

        BTW, I have read "numeric" values from DATA statments without VAL in PB/DOS 3.x (In fact, I won the 1998 International Obfuscated Basic Code Contest with such a technique).

        Have you tried this?
        DataLabel:
        DATA 1,2,3,4

        RESTORE DataLabel
        Read A,B,C,D




        ------------------
        Michael Mattias
        Racine WI USA
        [email protected]
        Michael Mattias
        Tal Systems Inc. (retired)
        Racine WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          Have you tried this?
          DataLabel:
          DATA 1,2,3,4

          RESTORE DataLabel
          Read A,B,C,D
          I did have something along the lines of (this is not the actual code, obviously):
          Code:
          %Test = 1
           
          DIM sTest AS STRING
          DIM nTest AS LONG
           
          RESTORE Info
          READ sTest, nTest
          ...
           
          Info:
          DATA "Data Test", %Test
          except that when I ran it, I got a syntax error when the program attempted to read the "numeric" value (should have read the manual, Doh!) I then changed the numeric variable to a string, and that worked, well sort of - the second DATA value was returned as %Test, not 1 as I had hoped. So I just changed the DATA statement to read:
          Code:
          DATA "Data Test", 1   '%Test
          and if I ever change the value of the constant I'll just have to remember to change the DATA statement also. As I said, it is an annoyance, not a critical issue.

          2. "EVAL" to convert DATA from READ statments.

          #2. How 'bout VAL?
          I was thinking of something along the lines of the EVAL command in the old Acorn BBC Micro BASIC where if you had something like:
          Code:
          %Test = 127
           
          nTestValue = EVAL( "%Test" )
          then the string parameter to the EVAL function would be evaluated and, in this case, a numeric value returned. As you can see, this is not quite the same as VAL. Or perhaps you might come across a situation like this:
          Code:
          TYPE structUDT
             nMember1   AS INTEGER
             nMember2   AS INTEGER
             nMember3   AS INTEGER
             ...
             nMember255 AS INTEGER
          END TYPE
           
          DIM oUDT AS SHARED structUDT
           
          ...
           
          nMemberIndex = 127
          nMemberValue = EVAL( "oUDT.nMember" + LTRIM$( STR$( nMemberIndex ) ) )
          I'm sure there are other similar situations and examples where an EVAL-like function could be useful. It would seem however, that PowerBASIC are unwilling to "compromise" their compiler to incorporate such a function, and I'll live with that decision. Again, a "nice-to-have" feature, not a critical issue.

          [This message has been edited by Matthew Berg (edited April 06, 2000).]
          If you try to make something idiot-proof, someone will invent a better idiot.

          Comment


          • #6
            Um, if the value of %Test is constant in a program, why bother putting it in a DATA statement? This is the purpose of equates - to create what brand M DOS-BASIC would call a CONST. IF the value changes in the future, you change it once (often in an $INCLUDE file), recompile and Voila! the program is ready to run with the new value.

            Equates can be used anywhere in in the source code of a module - inside procedures, outside procedures, across procedures.

            PB Equates are *not* LOCAL in PowerBASIC/DOS as they are in brand-M DOS BASIC.



            ------------------
            Michael Mattias
            Racine WI USA
            [email protected]
            Michael Mattias
            Tal Systems Inc. (retired)
            Racine WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              Um, if the value of %Test is constant in a program, why bother putting it in a DATA statement?
              Because if I have code like so:
              Code:
              %ACTION_1 = 1
              %ACTION_2 = 2
              %ACTION_3 = 4
               
              DIM sDescription AS STRING
              DIM nAction AS INTEGER
               
              READ sDescription
              DO UNTIL sDescription = "END"
                 READ nAction
               
                 SELECT CASE nAction
                    CASE %ACTION_1
                       'Do something
                    CASE %ACTION_2
                       'Do something else
                    CASE %ACTION_3
                       'Do whatever
                 END SELECT
               
                 READ sDescription
              LOOP
              
              DATA "Description 1", %ACTION_1
              DATA "Description 2", %ACTION_2
              DATA "Description 3", %ACTION_3
              DATA "END"
              I want to associate a value with a string. I don't want to have to worry about what number signifies what action, I just want to use a constant so the number is irrelevant. I don't want to have to rely on the string to determine what action should be taken, as that may change.

              Sure, I could create arrays and put the strings and constant values into them, but that would require the typing of alot more code. How hard could it possibly be for the compiler to detect, at compile-time, a constant in a DATA statement and replace it with the value that had been assigned to that constant?

              Equates can be used anywhere in in the source code of a module - inside procedures, outside procedures, across procedures.
              Except, it would seem, in DATA statements.
              If you try to make something idiot-proof, someone will invent a better idiot.

              Comment


              • #8
                "How hard could it possibly be for the compiler to detect, at compile-time, a constant in a DATA statement and replace it with the value that had been assigned to that constant?"

                What if I have a string value that I wish to store in a DATA statement that just happens to be the same as the name of an equate? For example, a financial analysis program might need a label on the screen named "%Change" (to show the percentage change in value of a security), but I might also have an equate named %Change that is used to set the value of a flag for a datafile item that has been updated in this session. (For example, if my record is stored in a UDT named Record, and the field name is Modified, I might use Record.Modified = %Change or Record.Modified = %NoChange to set the values of this field.)

                If the label text is stored in a DATA statement, and the compiler changed the value at compile time, I would get a number on the screen instead of the text "%Change". I would not like to have to track down that bug, and I would probably not have kind words for the compiler authors when I found the problem.

                Microsoft originally implemented DATA to allow strings to be included without surrounding quotes, and PowerBASIC followed their lead for compatibility. Thus, the compiler *must* treat equates as strings. To do otherwise would risk breaking many programs and incurring the wrath of their existing customers.

                Besides, your example really does not require "alot [sic] more code." A pair of simple arrays would probably actually simplify your code example (which really did not make a lot of sense to me, but this version actually won't require much more typing, especially if you use copy and paste actions to build the array assignments):

                Code:
                %ACTION_1 = 1
                %ACTION_2 = 2
                %ACTION_3 = 4
                
                DIM Item$(1:3), ItemCode%(1:3)
                Item$(1) = "Description 1" : ItemCode%(1) = %ACTION_1
                Item$(2) = "Description 2" : ItemCode%(2) = %ACTION_2
                Item$(3) = "Description 3" : ItemCode%(3) = %ACTION_3
                
                FOR i% = 1 TO UBOUND(Item$())
                  SELECT CASE ItemCode%(i%)
                    CASE %ACTION_1
                      'Do something
                    CASE %ACTION_2
                      'Do something else
                    CASE %ACTION_3
                      'Do whatever
                   END SELECT
                NEXT i%
                Alan

                ------------------
                Alan C. Earnshaw
                Information Management Systems, Inc.
                Alan C. Earnshaw
                Information Management Systems, Inc.
                http://www.infoms.com

                Comment


                • #9
                  I want to associate a value with a string. I don't want to have to worry about what number signifies what action, I just want to use a constant so the number is irrelevant.
                  In your case, how about....
                  Code:
                  %Action_1 = 1
                  %Action_2 = 2
                  %Action_3 = 4
                  GLOBAL ActionDescription(MAX,1) AS STRING
                  
                  FUNCTION WinMain....
                      REDIM ActionDescription (number)
                      SetGlobalStrings
                  
                  END FUNCTION
                  
                  SUB SetGlobalStrings
                  
                    ActionDescription (%Action_1) = "Action Description 1"
                    ActionDescription (%Action_2) = "Action Description 2"
                    ActionDescription (%Action_3) = "Action Description 3"
                  
                  END SUB
                  I do this all the time in both BASIC and COBOL.

                  MCM

                  Michael Mattias
                  Tal Systems Inc. (retired)
                  Racine WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    What if I have a string value that I wish to store in a DATA statement that just happens to be the same as the name of an equate?
                    So you'd put such a string inside double quotes, just like you currently have to do with strings containing commas or colons. As you presently aren't allowed to have double quotes or CR/LFs in DATA strings, why should % prefixes be treated any differently?
                    If you try to make something idiot-proof, someone will invent a better idiot.

                    Comment


                    • #11
                      Alan outlined the some likely side-effects of a DATA behavior change very well. Another likely problem that comes to mind could be shown in psuedo-code:
                      Code:
                      %ACTION_1 = 1
                      %ACTION_2 = 2
                      DATA %ACTION_3, %ACTION_2, %ACTION_1
                      Under your proposed DATA scheme, this code would be a problem because the 2nd data element could either be an undefined equate (it may have been unintentionally undefined) or it could intentionally be a DATA string - there is no simple way to be sure, unless it was enclosed in quote marks. To change the compiler to force quote marks on strings beginning with % means that there is a definitive risk of breaking existing code.

                      That said, I'll stil be passing your comment on to R&D who have the last word when it comes to implementing new features.


                      ------------------
                      Lance
                      PowerBASIC Support
                      mailto:[email protected][email protected]</A>
                      Lance
                      mailto:[email protected]

                      Comment

                      Working...
                      X