Author Topic: Parser doesn't recognize ALIAS as keyword, a will or a bug?  (Read 2634 times)

0 Members and 1 Guest are viewing this topic.

Offline TempodiBasic

  • Forum Resident
  • Posts: 1792
    • View Profile
Parser doesn't recognize ALIAS as keyword, a will or a bug?
« on: February 24, 2019, 03:22:03 pm »
Hi guys
I fall into this issue some days ago when I tried the code of the game posted by Cobalt.
please copy and paste into QB64...
Code: QB64: [Select]
  1. TYPE ContractData
  2.     Villain AS STRING * 24 '      Villains name
  3.     Alias AS STRING * 24 '        Villains Alias if one
  4.     Bounty AS _UNSIGNED INTEGER ' How Much Villan is worth
  5.     LastSeen AS _BYTE '           Continent villain was last seen on
  6.     Castle AS _BYTE '             Castle Villain is held up in
  7.     Is_Known AS _BYTE '           Triggered if player knows which castle villain is located
  8.     Description AS STRING * 130
  9.     Crimes AS STRING * 146
  10.     Caught AS _BYTE
  11.  
  12. DIM alias AS LONG  '<---- also this doesn't trigger the output "name already used in this line of code"
  13.  

the strange that I have found is that alias is colored with the color of Keywords and I can use it as name of variable with no warning or error.

What do you think of this?
In QBasic is ALIAS exclusive for Keywords?
Programming isn't difficult, only it's  consuming time and coffee

FellippeHeitor

  • Guest
Re: Parser doesn't recognize ALIAS as keyword, a will or a bug?
« Reply #1 on: February 24, 2019, 04:25:32 pm »
Alias is a keyword. Therefore, it is properly colored.

It is exclusively used in DECLARE LIBRARY blocks in QB64, as it was used with CDECL in QuickBASIC. Being used only in that context, it's ok to use it elsewhere.

I see it as intended here.

FellippeHeitor

  • Guest
Re: Parser doesn't recognize ALIAS as keyword, a will or a bug?
« Reply #2 on: February 24, 2019, 07:27:12 pm »
Now that I'm back home with QB4.5 at hand, I see that back in the day ALIAS could not be used as a variable name.

From the point of view of retrocompatibility, allowing it to be used won't cause incompatibilities because old code won't have used it.

From the point of view of adding another error to QB64, it is easily doable, but it doesn't seem like a necessary thing to be done, since there's no harm using the name.

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: Parser doesn't recognize ALIAS as keyword, a will or a bug?
« Reply #3 on: February 24, 2019, 07:34:31 pm »
Heck, I always thought you could even use keywords as names in TYPE statements...

TYPE foo
    PRINT AS STRING
END TYPE

DIM foofer AS foo

^ The above seems to me that it should work as the variable is actually foofer.PRINT and not just PRINT...  (Not tested at all on my part, however.)

One thing that I know WON’T work:

TYPE foo
    INTEGER AS INTEGER
END TYPE

^ QB64 rejects the statement completely.  You can’t use a variable type as a type name...  Whether that mimics QB45 or not, I have no idea.
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

FellippeHeitor

  • Guest
Re: Parser doesn't recognize ALIAS as keyword, a will or a bug?
« Reply #4 on: February 24, 2019, 08:03:28 pm »
Quote
Heck, I always thought you could even use keywords as names in TYPE statements...

TYPE foo
    PRINT AS STRING
END TYPE

DIM foofer AS foo

Doesn't in QB64, as it didn't work in QBasic.

TempodiBasic is surprised by the use of alias as a variable name though, not as a type element (although he is surprised it gets colorized):

Quote
Code: QB64: [Select]
  1.  DIM alias AS LONG  '<---- also this doesn't trigger the output "name already used in this line of code"
  2.  
« Last Edit: February 24, 2019, 08:05:08 pm by FellippeHeitor »

Offline TempodiBasic

  • Forum Resident
  • Posts: 1792
    • View Profile
Re: Parser doesn't recognize ALIAS as keyword, a will or a bug?
« Reply #5 on: February 25, 2019, 05:42:27 pm »
Thanks for your feedbacks

1.
yes Fellippe has hit the center of my thinkings
Why does the parser  colorize (recognize) Alias as Keyword and it doesn't restrict its name like it does for the other keywords?

2.
yes it is not a Qbasic behaviour in wich ALIAS is a language token


3.
yes  it (alias) is a restrict keyword to use in restrict area  so it is difficult to generate misunderstandment for parser/compiler :
 3.1 in QB64 in DECLARE LIBRARY,
 3.2 in QB45 in help I find this
Quote
DECLARE (Non-BASIC Procedure) Statement Details  [ You are not allowed to view this attachment ]  

Syntax 1
  DECLARE FUNCTION name [CDECL] [ALIAS "aliasname"][([parameterlist])]

Syntax 2
  DECLARE SUB name [CDECL] [ALIAS "aliasname"][([parameterlist])]
......
ALIAS          Indicates that the procedure has another name in the
                 .OBJ or library file.
.........
like also here it is explained
https://qb64.org/wiki/DECLARE_(non-BASIC_statement)
also if Alias has been restricted to a very little area it is forbidden as name of variable or of label.

4.
yes like Steve says  it is logic that in TYPE ...END TYPE block Alias cannot be a keyword of QB64, but with the same logic also GOSUB cannot be a keywork of QB64 because in that block we can only define the list of variables of the TYPE wich we are building up
so i find not congruent the QB64 behaviour in this 
Quote
TYPE c2
     Alias as Integer
     Gosub as Single
     Long as Double
END TYPE
in specific  the second line is not congruent with the third and the forth lines
because
4.1 if I must think about this like
      DIM c2.Alias AS INTEGER, c2.Gosub AS SINGLE , c2.Long as DOUBLE
      I should be able to write all these statements with no error from the parser/compiler...
4.2 if I must think about this like
      DIM Alias AS INTEGER, Gosub AS SINGLE, Long AS DOUBLE
      I shouldn't be able to write any of these statements with no error from the parser/compiler.

Copy and Paste in QB64 to do this experience...
Code: QB64: [Select]

Attachments are for those that don't want to copy an paste.
Programming isn't difficult, only it's  consuming time and coffee