Is it a Bug or a feature?

karthik · Jun 18, 2006

Strange things...in PROGRESS 4GL

1) Logical variables can take 3 values yes,no & ?

:lol:

DEFINE VARIABLE x AS LOGICAL INITIAL yes.
DEFINE VARIABLE y AS LOGICAL.
DEFINE VARIABLE z AS LOGICAL INITIAL ?.

DISPLAY x y z.

2) Streams can take the same name.

:lol:

DEFINE STREAM str.
DEFINE STREAM str.

3) BREAK BY can also take the following form

BREAK BY [=<constant>|<variable>]

DEFINE VARIABLE lcHolder AS CHARACTER INITIAL <blah>.

FOR EACH <table-name> NO-LOCK
BREAK BY <field-name> = lcHolder:

DISPLAY <field-name>.
/*

The above display statement will always shows <blah> value at last.

*/
END.
4) FOR EACH <table-name> NO-LOCK:

RUN a.
END.
PROCEDURE a:
DISPLAY <field-name-of-the-above-table>.
/* Doesnt work it says it needs table name as prefix even though the procedure is excecuted within the scope of the buffer */
END PROCEDURE.

Lee Curzon · Jun 18, 2006

karthik said:
Strange things...in PROGRESS 4GL

1) Logical variables can take 3 values yes,no & ? :lol:

Feature.

Progress is based on modern (mediaeval) ternary logic rather than <sniff> old-school Aristotlean logic.

There are rumours OE 10.2 features female logic.

[Apologies to female PTers. I'm in someones dog house, and have not been able to figure out why.

]

Lee Curzon · Jun 18, 2006

karthik said:
2) Streams can take the same name. :lol:

DEFINE STREAM str.
DEFINE STREAM str.

I vote 'Bug'.

Lee Curzon · Jun 18, 2006

karthik said:
Strange things...in PROGRESS 4GL

4) FOR EACH <table-name> NO-LOCK:
RUN a.
END.
PROCEDURE a:
DISPLAY <field-name-of-the-above-table>.
/* Doesnt work it says it needs table name as prefix even though the procedure is excecuted within the scope of the buffer */
END PROCEDURE.

Incomplete feature.

The above functionality (buffer name needed) is fully documented.

It is incomplete in that all loose field references without table names should be banned outright as horrendous programming shortcuts.

Lee Curzon · Jun 18, 2006

karthik said:
Strange things...in PROGRESS 4GL

3) BREAK BY can also take the following form
BREAK BY [=<constant>|<variable>]

DEFINE VARIABLE lcHolder AS CHARACTER INITIAL <blah>.

FOR EACH <table-name> NO-LOCK
BREAK BY <field-name> = lcHolder:

DISPLAY <field-name>.
/*

The above display statement will always shows <blah> value at last.

*/
END.

Feature.

You are BREAKing BY an expression (as documented in the syntax Help). In the case you have given, the expression is TRUE for lcHolder, FALSE for the rest.

The lcHolder record therefore displays last (TRUE > FALSE).

If lcHolder doesn't match, the record order will be as expected.

I hadn't thought of this usage before - thanks!

joey.jeremiah · Jun 18, 2006

karthik said:
1) Logical variables can take 3 values yes,no & ? :lol:

DEFINE VARIABLE x AS LOGICAL INITIAL yes.
DEFINE VARIABLE y AS LOGICAL.
DEFINE VARIABLE z AS LOGICAL INITIAL ?.

DISPLAY x y z.

null. unknown or unapplicable value.

for example,

employee birthday is unknown or us tax info for non-us sales

karthik said:
4) FOR EACH <table-name> NO-LOCK:
RUN a.
END.
PROCEDURE a:
DISPLAY <field-name-of-the-above-table>.
/* Doesnt work it says it needs table name as prefix even though the procedure is excecuted within the scope of the buffer */
END PROCEDURE.

fields are resolved at compile-time.

exactly what field in what table ( including database ) is resolved when the
proc is compiled.

not everytime the proc is invoked.

joey.jeremiah · Jun 19, 2006

Lee Curzon said:
Apologies to female PTers.

i wish.

man, this place is a complete sausage fest.

Lee Curzon · Jun 20, 2006

Yeah, I know.

But tech forums in general don't seem to have a lot of women on.

Of course, it probably doesn't help when a woman comes here and sees a bunch of blokes being geeky and the occasional sexist joke. (Which is why I issued my craven, hurried apology - there is the occasional female poster and lurker).

One of the things I like about PT is it seems (I have no proof) to be a comparatively varied forum in terms of age and geographic demographic.

It would be nice also if we had more females here as well. I mean, it doesn't matter technically - a programmer is a programmer is a programmer, and - no offence - I don't come here to date; but it just would make it a bit more like the real world.

Unfortunately (?), I do not have your experience with 'sausage fests', but I am sure you are correct.

bulklodd · Jun 20, 2006

Lee Curzon said:
I vote 'Bug'.

What about that?

Code:

DEFINE NEW GLOBAL SHARED VARIABLE xxx AS CHARACTER  NO-UNDO INIT "yyy".
MESSAGE "<name>" ENTRY(1,PROGRAM-NAME(1)," ") SKIP
   xxx
   VIEW-AS ALERT-BOX INFO BUTTONS OK TITLE "DEBUG".
DEFINE NEW GLOBAL SHARED VARIABLE xxx AS CHARACTER  NO-UNDO INIT "zzz".
MESSAGE "<name>" ENTRY(1,PROGRAM-NAME(1)," ") SKIP
   xxx
   VIEW-AS ALERT-BOX INFO BUTTONS OK TITLE "DEBUG".
DEFINE NEW SHARED VARIABLE xxx AS CHARACTER  NO-UNDO INIT "aaa".
MESSAGE "<name>" ENTRY(1,PROGRAM-NAME(1)," ") SKIP
   xxx
   VIEW-AS ALERT-BOX INFO BUTTONS OK TITLE "DEBUG".

Casper · Jun 20, 2006

Creepy.

How about some unlogic:

Code:

DEFINE VARIABLE i AS INTEGER    NO-UNDO.
DEFINE VARIABLE j  AS INTEGER    NO-UNDO.
ASSIGN i = ASC('')
       j = ASC(' ').
 
MESSAGE '' = ' '
        i = j
        CAN-DO('',' ')
        CAN-DO(CHR(i),CHR(j))
        CHR(i) = CHR(j)
    VIEW-AS ALERT-BOX INFO BUTTONS OK.

Lee Curzon · Jun 20, 2006

bulklodd said:

What about that?

Code:

DEFINE NEW GLOBAL SHARED VARIABLE xxx AS CHARACTER  NO-UNDO INIT "yyy".
MESSAGE "<name>" ENTRY(1,PROGRAM-NAME(1)," ") SKIP
   xxx
   VIEW-AS ALERT-BOX INFO BUTTONS OK TITLE "DEBUG".
DEFINE NEW GLOBAL SHARED VARIABLE xxx AS CHARACTER  NO-UNDO INIT "zzz".
MESSAGE "<name>" ENTRY(1,PROGRAM-NAME(1)," ") SKIP
   xxx
   VIEW-AS ALERT-BOX INFO BUTTONS OK TITLE "DEBUG".
DEFINE NEW SHARED VARIABLE xxx AS CHARACTER  NO-UNDO INIT "aaa".
MESSAGE "<name>" ENTRY(1,PROGRAM-NAME(1)," ") SKIP
   xxx
   VIEW-AS ALERT-BOX INFO BUTTONS OK TITLE "DEBUG".

Hmmm. That's odd. It looks like the compiler treats GLOBAL as, no wait, non-GLOBAL, um...

I never and try figure out what is going on with shared variables. It always makes my brain hurt.

All shared vars are bugs imho. My older-fashioned colleagues love it when I point that out to them.

joey.jeremiah · Jun 20, 2006

lee, why are you acting like a 12 year old ?

i know you for a while now and i know you always mean well but you
sometime say things without thinking

well, talk to you soon

Lee Curzon · Jun 21, 2006

joey.jeremiah said:
lee, why are you acting like a 12 year old ?

Eh?

You mean the 'shared vars' obstinacy?

Or the 'sausage fest' reference?

If it's the latter, no offence was intended - it's just dry banter - perfectly normal in my neck of the woods.

I thought it was a funny phrase, but have no idea what it meant.

I would put the misunderstanding down to cultural differences, but as I have got into trouble on this forum before for my 'humour': sorry.

However, I will continue to post 'without thinking', because it is my sense of humour, and my posting style, and I'm pretty happy with it.

I will of course apologise also if I cause offence.

bulklodd · Jun 21, 2006

Lee Curzon said:
Eh?
....

I will of course apologise also if I cause offence.

buds, what are you two talking about?

as for 'sausage fest', joey, could you explain what that means?

it@flude.co.uk · Jun 21, 2006

Casper said:

Creepy.

How about some unlogic:

Code:

DEFINE VARIABLE i AS INTEGER    NO-UNDO.
DEFINE VARIABLE j  AS INTEGER    NO-UNDO.
ASSIGN i = ASC('')
       j = ASC(' ').
 
MESSAGE '' = ' '
        i = j
        CAN-DO('',' ')
        CAN-DO(CHR(i),CHR(j))
        CHR(i) = CHR(j)
    VIEW-AS ALERT-BOX INFO BUTTONS OK.

Now that is odd. I thought it was because of the literals, but it works if you use variables as well. It is disturbing that a space equates to an empty (non-null) string.

The shared variable one is less of a problem, but I would have expected it to error when the same variable was defined more than once. Once that was allowed, the other behaviour logically follows.

The moral is to define shared variables in an include file and only do it once per program. Not a very snappy moral, mind.

Simon

Lee Curzon · Jun 21, 2006

[Cross post]

On the other hand, if you are talking about my hostility to shared vars, I make no apology.

I have never come across a situation with them that hasn't caused me grief (I meant what I said about them taxing my brain), and I probably feel about them the same way BCM and the dark cohorts feel about Progress.

Perhaps you thought I was being disrespectful to Bulklodd? That would certainly never be my intention, but

1. The Shared Vars example was provided as light relief, in a light relief thread, not as a defence of Shared Variables. If it had been the latter, I would have (I hope) politely disagreed, but would not have got into a religious argument about them, as I don't have the time.

2. Bulklodd is more than capable of putting me to rights if he so wished, and doesn't need you to defend him.

Lee Curzon · Jun 21, 2006

Casper said:
Creepy.

How about some unlogic:

Code:

ASSIGN i = ASC('')

Another new thing I learnt:

ASC('') = -1.

Lee Curzon · Jun 21, 2006

Lee Curzon said:
Another new thing I learnt:

ASC('') = -1.

Something (completely OT) I remember (I hope my memory is correct) from my Maths degree, aeons ago:

e^(i*pi) = -1.

Now that is creepy.

joey.jeremiah · Jun 21, 2006

forget about it

bulklodd · Jun 21, 2006

i've just rembered one "cool" thing

Code:

.whatever /* it'll be compiled without any problem */

Is it a Bug or a feature?

New Member

Member

Member

Member

Member

ProgressTalk Moderator

ProgressTalk Moderator

Member

Member

ProgressTalk.com Moderator

Member

ProgressTalk Moderator

Member

Member

Member

Member

Member

Member

ProgressTalk Moderator

Member

Similar threads