grammarware / software-evolution Goto Github PK

In the whitespace insignificance examples on level 2 you say:

assuming that ACCOUNTNUMBER, ACCOUNT-NUMBER, ACCOUNT and NUMBER are all defined fields,
MOVE 42 TO ACCOUNT NUM BER. is invalid since whitespace information is not clear enough to disambiguate.

And in issue #2 you say:

the usual way to disambiguate is to look for the least number of "fixes" that the parser needs to do

The two possible ways to parse MOVE 42 TO ACCOUNT NUM BER. that I can think is:

1. ["MOVE", "42", "TO", "ACCOUNT", "NUMBER"]
2. ["MOVE", "42", "TO", "ACCOUNT", "NUM", "BER"]

However, we have NUMBER defined, so we can use this to disambiguate for the first way and not raise an error, right?

I am getting confused by how a picture clause is defined in the data structure and what should and should not be considered an appropriate representation.
Taking into account the following said in the paper:

More specifically that last sentence.
The way I understand it, the representation can be almost anything. And if any characters which are not part of the semantics are encountered, then they are taken as their exact value.
E.g. We could have "PICTURE IS XXCXX" which would represent any 2 characters followed by a char 'C' and then again any 2 characters.
Another question that came up is whether Fields composed of both digits and characters can have leading digits or signs.
Are the 2 following representations valid? 1)"S99999V999XXXXXX" and 2) "SXVXX999" where in the first example, the S and V become part of the digit representation of the number and in the second, they are part of the String representation and if soo, is their representation the character 'S', 'V' or is it '+/-', ' , / . '.

Currently we are revisiting the DISPLAY statement. We allow the DISPLAY statement to take string literals without quote strings, but this goes south if this literal could also be a keyword.

1. What should happen when executing the following program?

IDENTIFICATION DIVISION .
  PROGRAM-ID. FIB.
PROCEDURE DIVISION .
DISPLAY GIVING. 

2. Do we even need to support string literals without quotes outside of identifier names?

Hello, we of group 7 want to do a code review. Do you have time on Wednesday afternoon or Thursday afternoon?

What will be available for us during the exam, and what is allowed / required to take with you to the exam?

In LOOP statements, VARYING, WHILE and UNTIL clauses can be scattered across the body. However, my question is can there be multiple VARYING clauses or multiple WHILE or multiple UNTIL clauses? If the answer is yes what should be the control flow of such LOOP statement?

The remarks of the SUBTRACT page use a DIVIDE statement as an example.

How important are errors in this project? For example what if a piece of codes gives an error for the right reason but that is not representative of the actual issue or issued at the right line of code in the file.

What exactly should be covered in the BooleanExpression of an if statement in BabyCobol? This COBOL reference from IBM talks about quite a few options for the conditional expressions of an if statement. Is it sufficient if we support comparisons of arithmetic operations (both on atomic values and variables) and strings?

Furthermore, on this page of the same COBOL reference, there are specific keywords used in the condition of an if statement (e.g. AND, OR and NOT). Does it matter if we use such keywords, or can we just use the normal mathematical signs (i.e. <, >, =, etc.)?

We would like to request a review meeting, do you have available times this week after Monday? Thank you

For the data-division section it is said that "if neither the PICTURE nor the LIKE clause are used, such an entry defines a record". Does it mean that we can define a variable with no type? If so, how can the PICTURE be defined later in the program for such variable or will it always remain as 'no type'?

The graphic at https://slebok.github.io/baby/proceduredivision.html seems to indicate that at least one paragraph is required in a procedure division. However, many of the provided test cases only include one or more sentences in the PROCEDURE DIVISION without adding a paragraph with its corresponding identifier. Simple example would be

IDENTIFICATION DIVISION.
PROCEDURE DIVISION.
DISPLAY M.

from the recombined test test_403488.baby

Right now I'm following the test cases and set paragraphs to entirely optional, but that seems to contradict the diagram. Am I misinterpreting it?

Suppose we have the line: DISPLAY Something WITH NO ADVANCING
How should the parser differentiate between printing one variable (Something) and not putting a new line and displaying four variables (Something, WITH, NO, ADVANCING)? Also, can this line of code be written like: "DISPLAYSomethingWITHNOADVANCING"?

The MOVE clause support several figurative constants. On Canvas and the BabyCobol website, it is described how these constants behave for field variables, but what about composite fields? Would something like MOVE SPACES TO A (where A is a composite field) perform a MOVE SPACES to all leaves of A?

It is still unclear to me how the ambiguity around case sensitivity is resolved. The canvas page states 'in the face of ambiguity, words written in uppercase resolve to keywords, otherwise to field names'. This implies to me that the parser should find a path in the parse forest which has the least number of edits, i.e. keywords written in lowercase, and conflicting identifiers in uppercase.

If we apply this theory to the examples, it quickly falls apart. Take example 2:
ADD A to B ADD C TO D ADD E TO F.
Here, there is one 'imposter', the second 'ADD' downgraded from a keyword to an identifier. So this route would have a score of 1.
However, If we parse the sentence differently:
ADD A to B ADD C TO D ADD E TO F
There is also just one 'imposter', the 'to' upgraded to a keyword. This route would also have a score of 1, and therefore there is ambiguity. The example, however, says that only the first parse is valid.

If we take a look at the last example of the explainer:

First of all, the second and fourth lines are the same. Now if we plot out all up and downgrades of each line (there is an implicit upgrade for the last 'to' in all 5 parses):

1. Downgrade 'ADD', downgrade 'ADD'
2. Downgrade 'ADD', upgrade 'to'
3. Upgrade 'to', downgrade 'ADD'
4. (same line as 2.)
5. Upgrade 'to', upgrade 'to'

The theory would therefore hold for this example (and also the one before it).

The last two examples would imply that both upgrading and downgrading are penalised equally by the compiler: If there are two paths which have an equal amount of (up + downgrading), they are considered ambiguous.

In conclusion, I am very confused as to what the rules around the case and keyword ambiguity are and would like clarification

If I understand correctly, for EVALUATE clause and contracted expression for that it should support the following:
For regular EVALUATE:

EVALUATE X + 1 ALSO Y + 2
	WHEN X < 10 ALSO Y > 2
		blablabla
       ........

For contracted expression

EVALUATE X + (10 / 2)
	WHEN 10 
		blablabla
        WHEN > 20
                blablabla
        ....

My questions:

1. Is my intuition for the logic of EVALUATE right?
2. How should I deal in case of the following:

EVALUATE X = 1 ALSO Y = 10
	WHEN 1 ALSO 2
		blablabla
       .....

Also, the example you give in another discussion:

EVALUATE X ALSO Y
    WHEN 10 ALSO "FOO"
        DISPLAY "FOO10"
    WHEN 20 ALSO "BAR"
        DISPLAY "BAR20"
    WHEN OTHER
        DISPLAY "NO"
END

Suppose we have the following sentence:
IF BOOLEXPR1 THEN DISPLAY A IF BOOLEXPR2 THEN DISPLAY B END DISPLAY C.
Then the END can be part of either the outer IF, or the inner IF.
What is the correct way to interpret the END here?
Is the END keyword meant to end the innermost IF statement, like a break in loops for other languages, or is it an ambiguous thing and should we provide an error like the dangling-ELSE?

For the ADD and SUBTRACT statements, we are required to also add composite data, adding sub-elements if they have the same name. However, it is unclear what should happen when the sub-elements are different data structures.

We have 4 cases that can occur, and have assumed behavior for two of them, but we are unsure what should happen for the other two.

• copy composite into composite: recursively do this sub-element addition.
• copy composite into elementary: ??
• copy elementary into elementary: add the two together.
• copy elementary into composite: ??

An example where this would occur:

IDENTIFICATION DIVISION.
    PROGRAM-ID. EXAMPLE.
DATA DIVISION.
    01 A.
    02 C PICTURE OF 99 VALUE 11.
    01 B.
    02 C PICTURE OF 9 VALUE 2.
    02 D PICTURE OF 99 VALUE 33.
    01 E.
    02 C.
    03 Q PICTURE OF 999 VALUE 44.
PROCEDURE DIVISION.
    ADD A TO E.
    STOP

How are we supposed to handle this?

1. The provided test files contain quite a lot of 'numeric' boolean expressions. The BabyCobol Language Reference doesn't specify anything about boolean expressions, and the paper only mentions TRUE and FALSE as valid boolean literals. Examples:
   recombined_formatted/test_214204.baby
   LOOP WHILE 2
   recombined_formatted/test_262888.baby
   LOOP WHILE -12.121
   Should we add parsing support for this, or is this a mistake in test generation?

2. The provided test files (and the paper) use WHEN for subsequent WhenBlocks in EVALUATE statements. According to the diagram in the language reference, these should use the ALSO keyword. Example:
   recombined_formatted/test_66672.baby

EVALUATE CURRENT-YEAR - BIRTH-YEAR
           WHEN 1 THROUGH 17
           DISPLAY "NOT LEGAL AGE"
           WHEN 18 THROUGH 99
           DISPLAY "LEGAL AGE"
           WHEN OTHER
           DISPLAY "WRONG AGE"
           END.

Hi, we have a bit of a situation with our group and have sent you an email about this. I'm also notifying you here in case you miss it. The email comes from: [email protected].

I have the following questions about the Evaluate function:

1. What specifically does it do? And what is the role of having the keywords ALSO and THROUGH. I don't understand what they add to the statement.
2. The grammar posted in your paper is different than what is shown in the features website. Which keywords are relevant and are used in the language? For example, the keyword END in the grammar is shown as '.'. ALSO and THROUGH are ommited from the grammar completely, does this mean that they do not appear in the language?
3. Are keywords delimited from Expressions / Atomics etc. by white space? or is the following allowed: EVALUATEWHATEVER+WHATEVER1WHENOTHER

In one of the lectorials, you mentioned that we can request code reviews from you (or other professors). Before requesting this, is there anything we should prepare in particular for the session, apart from a list of currently supported features and how to run the code?

Me and my team has encountered a small (big) issue regarding the project and were wondering if could help us with it. Currently, we sent an email to your teacher email (from my email: [email protected]), however if you are unable to check your emails, let me know where I could reach you with the question we are having.

In basic operations such as ADD, DIVIDE and etc. there is a way to store the result in the variable defined by GIVING clause. However, this clause does not contain the picture, therefore it is not really clear what to do when this variable appears. For example:
...
ADD 1 TO 2 GIVING e.
ADD 3 TO e. // This crashes, because picture for e is not defined
...

Is this a legal way of writing code in cobol?

In the paper about BabyCobol, it is mentioned (in section 3.4) that keywords are demanded to be uppercase:

However on Canvas in the examples about keywords it is shown that it is not always the case:

Is the paper outdated and can keywords be lowercase, and if so when should they be read in lowercase?

For the ALTER statement, if the new target paragraph (so after the TO) is an identifier, is the value of that identifier evaluated at ALTER, or when the altered paragraph is performed?

In the following example:

...
DATA DIVISION.
    01 TARGET PICTURE IS X.
PROCEDURE DIVISION.
    MOVE "B" TO TARGET.
    ALTER A TO PROCEED TO TARGET.
    MOVE "C" TO TARGET.
    GO TO A.
A.
    GO TO A.
B. 
    DISPLAY "B" WITH NO ADVANCING.
    STOP.
C.
    DISPLAY "C" WITH NO ADVANCING. 

Would this display "B" or "C"?

Hey,
Do you have some opinion about the Crafting Interpreter from Robert Nystrom book?
I'm looking for a book to help me with the compiler implementation in this course and also give me a full view of the field.
Thanks!

A Like Clause is supposed to define a Variable of the same type as the mentioned variable and copy either its representation (if it is a Field) or its block of variables (if its a Record). However, how does one differentiate between 2 variables with the same name but on different levels (which I assume is possible)?
e.g.

Here we can see that there are 2 variables N one on level 10 and one on level 09 which are both defined before the LIKE clause.
Is this ambiguous and should thrown an error? The only difference between the 2 N's is the fact that the one on lv 10 can be represented as N of LAST3, however if we want our LIKE Clause to refer to the N on level 09, the only way would be to define it as N of LAST1 which is still ambigous.
Do we by default assume that the first defined N would be the one we are refferring to?