Announcement

**Lance Edmonds** · 5 Apr 2000, 04:45 AM

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>

**Matthew Berg** · 5 Apr 2000, 12:21 PM

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?

**Michael Mattias** · 5 Apr 2000, 05:02 PM

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]

**Matthew Berg** · 5 Apr 2000, 06:16 PM

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).]

**Michael Mattias** · 6 Apr 2000, 04:11 AM

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]

**Matthew Berg** · 6 Apr 2000, 12:23 PM

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.

**Alan Earnshaw** · 8 Apr 2000, 08:49 AM

"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.

**Michael Mattias** · 8 Apr 2000, 11:33 AM

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

**Matthew Berg** · 8 Apr 2000, 09:52 PM

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?

**Lance Edmonds** · 9 Apr 2000, 05:00 AM

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>

Announcement

Problem reading DATA

Problem reading DATA

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment