Auto new line

[ukcroupier]

There are many commands that could be seen as the end of a line and yet we still need to use a colon to denote a new line/command. eg.

endif (e.) else (el.) wend (we.) next (n.) etc

Would it be possible for the parser to do this 'auto new line'? and remove the need for many of the colons in 10 liners (I have over 200 colons in my current programme)

[dmsc]

Hi!

There are many commands that could be seen as the end of a line and yet we still need to use a colon to denote a new line/command. eg.

endif (e.) else (el.) wend (we.) next (n.) etc

Would it be possible for the parser to do this 'auto new line'?

This is not easy. Currently, the parser needs an ending : or an end-of-line to check if there is no parsing errors on all statements. Removing that, the parsing would become very hard to follow.

Check this program:

LOOPED=2
? LOOPED

Currently, it prints "2", as it defines a variable "LOOPED". With your new rules, it will result in a parsing error, as it will be interpreted as:

LOOP : ED=2
? LOOPED

[ukcroupier]

I don't understand how your parser works but I was thinking the auto line would only work on abbreviations as there's already an effective EOL in the full stop. Or maybe that the full stop in some abbreviation could use a semi-colon which would act as an abbriviation and an EOL.

[dmsc]

Hi!

I don't understand how your parser works but I was thinking the auto line would only work on abbreviations as there's already an effective EOL in the full stop. Or maybe that the full stop in some abbreviation could use a semi-colon which would act as an abbriviation and an EOL.

You are right, with the dot the parsing would not be ambiguous. Implementing this is currently not possible, as the parser "sees" the abbreviated and normal statements exactly the same, so you can't make a rule depend on the abbreviated state.

One way to implement this could be modifying the parser to store in a location if the parser sees a dot ending an abbreviation, and use this information in the rule to check for an end-of-line. But this has two problems:

• Somewhere in the parser that location should be cleared, and it is not evident to me where that should be;
• The parser rewinds when a rule is not accepted (for example, it tries SOUND with four parameters, then SOUND with one, and at the end SOUND without parameters), on retry the location should be reverted also, but that is not easy as it would need to be stored somewhere.
• The same as above, I would need to check every statement with variable number of parameters to see if the new rules don't break the parsing of multiple options: SOUND, PAUSE, PRINT, CLS, PROC, EXEC, INPUT, GET, DATA.

Have Fun!