FWD » Core Development » Base Language

This is a task that tracks the issues reported by Eric in #1985, note 19.
I tried to eliminate the issue by pinpointing where the null getter was created. During this dirty fix, I observed some strange thinks in the syntax, some widgets were not explicitly defined.

Working with Constantin we realized that the mesg1, mesg2 and mesg3 were defined inline, during the display statements that directly uses them.

The minimal test-case is:

DEFINE VARIABLE a AS CHARACTER NO-UNDO INIT "a".
DISPLAY a @ b AS CHARACTER.
b = "b".

character a = new character("a");
frame0.openScope();
FrameElement[] elementList0 = new FrameElement[]
{
   new Element(a, "x(8)")
};
frame0.display(elementList0);
b.assign("b");

Note that the following case is converted correctly by P2J:

display msg as char.
msg = "".

It seems to be a problem related to the @base-field specification.

I looked into manuals about the base-field specification, but they only describe how data is displayed into the respective place, I did not found any useful information into @4GL Reference and Progress Language Tutorial about these defined variables. However, some examples, exists, and I found even another form:

DEFINE VARIABLE c AS CHARACTER NO-UNDO INIT "C".
DEFINE VARIABLE a AS CHARACTER NO-UNDO INIT "A".
DISPLAY a @ b LIKE c.

DISPLAY a @ b LIKE c LABEL "blabel".
MESSAGE b:LABEL.

Ovidiu, for now try and fix the "display c @ b as datatype" case, leave that for later.

I can help with this.

Constantin: do you have any other findings to report?

We do support @-base fields already to a great degree. Majic uses them heavily. This feature of the 4GL is not well documented. Actually, our documentation in the P2J Conversion Reference is probably more useful but I suspect it is still incomplete. It is important to note that the conversion processing of these fields is fragile. For example, there is a strange precedence to how format strings for the base field are calculated. It is not straightforward and it must take into account multiple format strings across the entire file... My point here is that we already have a great deal of TRPL code written to try to deal with these fields (and some of the runtime is dedicated to this too). We must be very cautious in changing the parser because the current TRPL code will most likely break if the structure changes. I prefer to avoid this.

This code works in P2J:

def var txt as char init "something" format "x(10)".
display bf as character txt @ bf.

This is the functional equivalent of this:

def var txt as char init "something" format "x(10)".
display txt @ bf as character

Here is the Java:

         character txt = new character("something");

         character bf = new character("");

         public void init()
         {
            TransactionManager.register(txt, bf);
         }

         public void body()
         {
            frame0.openScope();

            FrameElement[] elementList0 = new FrameElement[]
            {
               new Element(txt, frame0.widgetBf())
            };

            frame0.display(elementList0);
         }

I thought this might be useful, because it shows how the tree would need to look to work with the code as it stands today.

I have to step out for a bit, but will pick this up again when I get back.

After looking at this in detail, it is clear that this is something that I need to work on. Both of you should work on other open issues.

The core of the problem lies in how the parser treats format phrases and various other syntax (@ based fields, aggregate phrases...) that can be somewhat intermixed with format phrases. More importantly, the more I look at the syntax that is possible, the more I find that our original parsing of @ base field should not be inside the format phrase. There are even some limits of what can appear before an @ base reference and these suggest that we need to treat things differently. We already handle things like LIKE clauses and so forth, but we don't properly handle that stuff after the @ base field, because we are treating the "widget" reference as the expression/lvalue that is before the @, but the 4GL is treating the reference after the @ as the widget. If I clean that up, it should solve most of the problems BUT it will most likely have major downstream impact on our frame processing rules.

I am also considering a quick and dirty fix, which will have much less impact but it will not fix all cases.

Regardless, this is so deep in the parser, that I really need to take the lead on this myself.

One other point: I think if we get the parser right, the downstream processing may be much simpler. Today, we have to do some strange "manual walking" of the tree to find the right nodes and process everything (e.g. format phrase processing). With the proper approach, this may be easier, but the cleanup is going to be very painful.

Passed conversion testing and is checked into bzr as revision 10226.