EQUATE : Compile-time vs Run-time

[Tony Gravagno]

Rex asked about this in the thread about best practices. I think this deserves its own topic.

In Pick-based MV platforms the EQUATE statement is a compiler directive. Whatever is found in the EQUATE is baked into the object code.

This means we don't want to use something like @USER or @(0,23), as in:

EQU THIS.USER TO @USER

EQU ERR.LINE TO @(0,23)

or

EQU VAR1 TO 1

EQU VAR2 TO VAR1+1

D3 won't even compile that because the values are expressions rather than literals. If it did evaluate the expressions, the value for THIS.USER would be TG, and for ERR.LINE, VT100-specific escape sequences would get baked into the object. That is not the desired effect at runtime when another user on WY-60 gets screen output. That used to happen.

In other platforms, and I don't recall which except maybe for Universe? EQUATE is still a compiler directive. But it replaces the literal values into the code at compile time, not the evaluated expression. So with the above code CRT THIS.USER would be compiled as CRT @USER, which would then return the correct run-time value.

I'll be happy to accept embarrassment of citing old behaviours, but equally happy to learn specifically how each platform does this.

I'd also be happy to see a D3 enhancement, where rather than flagging THIS.USER TO @USER as a compile-time error, they generate the symbol table and then substitute the literal text @USER for all THIS.USER symbols, without evaluating it.

Corrections and good/current info is greatly appreciated.

T

[Rex Gozar]

In Universe, EQU THIS.USER TO @LOGNAME doesn't bake the result into
the object. Inspecting the VLIST output shows that the @LOGNAME is
referenced.

00001: EQU THIS.USER TO @LOGNAME

00002: DISPLAY THIS.USER
00002 00000 : 046 crtcrlf @LOGNAME

00003: END
00003 00006 : 190 stop

Also, expressions are also acceptable in Universe:

EQU ODATE TO OCONV(IDATE, "D4/")
IDATE = 19021 ; DISPLAY ODATE
IDATE = 18552 ; DISPLAY ODATE
IDATE = 1 ; DISPLAY ODATE
END

Outputs:
01/28/2020
10/16/2018
01/01/1968

> --
> You received this message because you are subscribed to
> the "Pick and MultiValue Databases" group.
> To post, email to: mvd...@googlegroups.com
> To unsubscribe, email to: mvdbms+un...@googlegroups.com
> For more options, visit http://groups.google.com/group/mvdbms
> ---
> You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/0729c0a4-1ef3-414e-afe8-087c093e7c41%40googlegroups.com.

[Tony Gravagno]

There ya go. That's what I was talking about in the other thread or the doc or wherever I wrote that. ;)

[Peter McMurray]

Hi I find the EQUATE to be the ideal file attribute identifier plus all my system files and controls in COMMON.

As for user etc. I simply set them into a COMMON attribute on logging in to the application and all subroutines use the EQUATE 

 INCLUDE A.BP A_EQU

 INCLUDE A.BP A_PRINTCON

 DIM A.FILNAM(10);MAT A.FILNAM = ''

 A.FILNAM(1) = 'COMPANIES'

      EQU COF TO A.FILES(1)

 DIM COMPANY(52)

           MAT COMPANY= ''

 EQU SHCONAME TO COMPANY(1)

 EQU CONAME TO COMPANY(2)

 EQU COADD1 TO COMPANY(3)

 EQU COADD2 TO COMPANY(4)

 EQU COADD3 TO COMPANY(5)

[Tony Gravagno]

On Tuesday, May 19, 2020 at 5:53:22 PM UTC-7, Peter McMurray wrote:

Hi I find the EQUATE to be the ideal file attribute identifier plus all my system files and controls in COMMON.

This thread isn't about how to use EQUate but how it works internally.

I think comments about technique are best suited in separate threads on best practices.

Peter, have you tried EQUATE VALUE TO VAR<N> ?

That doesn't work in D3 because of the topic discussed here. Might it work anywhere else?

What about EQUATE TODAY TO DATE() ? That doesn't work in D3 for similar reasons - what about elsewhere?

Thanks.

T

[Stefano Maran]

EQU ARRAY_P_ELEMENT TO ARRAY(P_ELEMENT)

DIM ARRAY(3)

ARRAY(1)="A"

ARRAY(2)="B"

ARRAY(3)="C"

FOR P_ELEMENT=1 TO 3

   PRINT P_ELEMENT, ARRAY_P_ELEMENT

NEXT P_ELEMENT

RUN...

1        A

2        B

3        C

[Will Johnson]

I think there is an error in thinking that EQU means "identify my equate at compile time" or "identify my equate at run time"

It means neither.

What actually occurs, is that the compiler, at compile-time, stores the equates in buffers literally, and then runs through the *rest* of the code actually replacing every instant of that variable with that literal and THEN compiles that.

This is why the object code doesn't actually have any command for equate in it.

So when you say Equate TODAY to @DATE it actually finds every instance of TODAY in the code *at compile time* and replaces that instance with the literal @DATE and only *then* compiles the glob

[timbered]

I seem to recall that in Universe, there was an EQU LIT as well, as in LITeral. I think that kept any expressions from being evaluated. I'm foggy on details...

[Tony Gravagno]

Will - the entire point of this thread is that different platforms process EQUATE differently. Yes, U2 does exactly what you say. D3 does not. How do other platforms do it? Or for U2 might there be a flavour-specific behaviour?

T

[Will Johnson]

Sorry I haven't seen any evidence that D3 does it differently

[Tony Gravagno]

Sheesh, READ the first post in the thread!

Nuf said : I won't bicker.

[Will Johnson]

I did read it.

D3 WON"T do something.

That has nothing to do with what it *does* do.

All platforms treat Equate in the exact same way as I specified.

The sole difference is that some allow (not deny) additional abilities