Is &H a compile time literal?

[Flyzone]

In the alphabetic documentation index and linked documentation on "Literals", the &H spec is defined as a "literal" which is further defined as a compile time only value. The implication I assume is &H.. cannot be used as a variable. However, &H can be combined with a variable which seems to make this definition improper or incomplete.

For example,

Code: Select all

#lang "fblite"
nxt:
input "hh ",s$
print CHR$(VAL("&H"+s$))
goto nxt

...works and &H.. is not specified as a compile time only Literal.

It's just a classification curiosity for me.

(This is NOT intended to drive fxm crazy)

[fxm]

'&H' is not a literal strictly speaking but a prefix to declare that what follows is in hexadecimal format (like '&O' or '&B' for octal or binary format).
This prefix can be used not only in literal expressions (evaluated at compile time), but also as an identifier prefix with 'VAL' which so parses the thus concatenated string (so parsed at run-time).

I think that in the alphabetic keywords list for "&H, &B, &O", one could add a link to 'VAL'.

[Flyzone]

Seems to me it is, or it isn't. Your explanation states that it could sometimes be a Literal and sometimes not. This applies not just to &H but to all of the prefixes. Perhaps they should be called that: Prefixes or Type Prefixes.

[paul doe]

Seems to me it is, or it isn't. Your explanation states that it could sometimes be a Literal and sometimes not. This applies not just to &H but to all of the prefixes. Perhaps they should be called that: Prefixes or Type Prefixes.

That's what he's telling you: it's a prefix for literals, not for types. It tells the compiler 'interpret the following literal as hex/oct/whatever'. The association with a variable comes from the fact that val can also parse literal prefixes.

[Flyzone]

I suppose we can dispute the meaning of a "literal". The fact that &H, a prefix, can have a variable attached to it (i.e. a value that is not fixed at compile time) makes it not a literal but a variable - unless the new definition for literal is something other than what I've known for about 50 years. I'm certainly aware the definition of a TYPE has changed over time, so I'll accept those definitions and leave it at that.

[adeyblue]

The easiest way to answer 'Is it a variable?' is 'Can you put it on the left side of a ='.

Code: Select all

dim as string helloVar
dim as Long six

"helloVar" = "Go away" '' no - error 119: Cannot modify a constant
hellovar = "Go away" '' yes
6 = 23.5 '' no
six = 23.5 '' yes

*cast(Long Ptr, 6) = 23.5 '' yes!? Oh bums

[Flyzone]

I'm not in agreement. A variable has a value that can vary during the course of execution of a program. A Literal cannot and its value is determined during compilation.

[fxm]

Code: Select all

Dim As String s = "FF"

Print Val("&h" + "FF")

Print Val("&h" + s)

Sleep

“&h” + “FF”:
- at compile time, this expression ("&h" + "FF") is evaluated as the literal "&hFF".

“&h” + s :
- during compilation, a temporary string variable is defined, which will be kept until the end of the execution of the line.
- at run time, when the value of 's' is known, then the result of the strings concatenation ("&h" + s) is assigned to this temporary string variable.

It is equivalent (after compilation) to the following code:

Code: Select all

Dim As String s = "FF"

Print Val("&hFF")

Scope
    Dim As String _s_
    _s_ = "&h" + s
    Print Val(_s_)
End Scope

Sleep

[caseih]

Seems to me it is, or it isn't. Your explanation states that it could sometimes be a Literal and sometimes not. This applies not just to &H but to all of the prefixes. Perhaps they should be called that: Prefixes or Type Prefixes.

Not quite sure why you're getting hung up here. Your initial example involved strings, which happened to contain the characters &h which, when interpreted by VAL() makes a number out of it. Is &h in the string "p&h" a literal? No of course not. But the entire token including the quotes is a string literal.

Literals by definition are static tokens that are meaningful to the compiler as data at compile time. Sometimes &h falls into that category, sometimes it does not. As fxm showed, the compiler will evaluate strings at compile time if it can, as an optimization.

[Flyzone]

Not quite sure why you're getting hung up here.

I'm no longer hung up.

[caseih]

haha okay good!