Continue-parsing-on-next-line in Spin2
cgracey
Posts: 14,151
I want to add a way to continue parsing Spin2 code on the next line. Sometimes this is useful for making code more readable or just keeping line lengths down.
Here is what I am thinking about:
k := byte[Bp(i)][4].[7..5] << 3 | ... 'get lifecycle of this block
byte[Bp(j)][4].[7..5] 'and other block
The '...' tells the parser to ignore the rest of the line and continue parsing from the start of the next line. This does not reset the column counter for indention measurements which affect scope.
So, does '...' look best or does '``' look better?
k := byte[Bp(i)][4].[7..5] << 3 | `` 'get lifecycle of this block
byte[Bp(j)][4].[7..5] 'and other block
I kind of like the latter more.
This happens at the lowest level of the parser, so it would work for all code, including PASM.
I had started out thinking about just having rules for when things could continue on the next line, like after a comma, but then there are needs to break lines at many points. Rather than make a bunch of rules for when lines could continue on the next line, which could really complicate highlighters (not to mention the compiler), I figured some simple character combo to signal continue-on-next-line would keep things simplest.
Comments
I like ... because it feels more intuitive, like no explanation is required.
The other one seems like it should have some string operation or comment
Good point. I will make it that way.
FWIW, the backticks (if those are backticks) can be difficult to reach in a non-US keyboard.
The three dots, instead are more intuitive, because... you know.
Would two dots '..' be better? Or, would that be less intuitive? I think it would be syntactically okay to use '..' for that purpose.
EDIT: I just looked at the compiler and I think it would NOT be a good idea to use '..' because it would cause conflict.
do it the COBOL way, a - in column 7 of the next row...
Mike
or maybe ... on the beginning of the next row?
Mike
I'd just make it automatic. Needing a special token makes it no better than the current hack with the block comment.
Maybe just make it such that newlines are ignored when there's any unmatched brackets. That's fairly easy and applicable to most situations.
The other thing would be to ignore the newline if the last token on the line is an operator. I think those two simple rules should cover everything.
Except sometimes people do forget a bracket, and if the compiler doesn't recognize this on the correct line it can be really hard to track down. I think using
..., in a manner similar to how C uses\and BASIC uses_, makes sense.I like ... because ...
I hate backticks.
On the german keyboard there is no real backtick. There is a key that is used to put an accent grave (with shift) or accent aigu (without shift) over the following "e" or "a" which is required for some french words. When the forum text editor was changed to the current one using backticks for
codeI had to figure out that this key can also be used together with a space to make a backtick. I have nerver ever used that in my whole live before.It took me a long time to figure out that you can use it with space, lol. You can hit the dead key twice to produce two backticks. I figured out that much as a kid hitting all the keys on the board. My usual strategy for code blocks is to hit it six times and then navigate three spaces back and then insert the text there.
Reporting the top level open bracket in such a case is good enough I'd assume.
Agreed, because two dots are used to separate range endpoints. Perhaps to promote readability the token could be space dot dot dot space.
Why do you need anything? If last thing on line before comment is &, |, ^, +, -, etc., then continue on next line.
I'd like to replace this monstrosity
with this simplicity
long (SCASWr_0+1) << 28 | (SCASBr_0+1) << 24 | (LODSWr_0+1) << 20 | (LODSBr_0+1) << 16 | (STOSWr_0+1) << 12 | (STOSBr_0+1) << 8 | (MOVSDr_0+1) << 4The hams in the group are having a NSFW giggle at this one.
I’ll just see myself out… 🤣
I guess I have to look that up -- I'm not a ham and it was not a deliberate joke.
And TAB-dot-dot-dot is what I would type
There are many places where you might want to divide a line: after a binary operator or a comma or an open parenthesis, or even before a close parenthesis. These rules will affect how syntax highlighters work, too. It gets quickly complicated.
I am going to think about it more.
|at the end of a line is saying "there's more to come."If not a binary operator at the end then
...might be a necessity.Really? Not what I'd heard
What was wrong with {
} this?
It already works without additional syntactical gingerbread.
-Phil
I try to avoid using TAB characters in programming; I always configure IDEs to convert TAB to spaces.
'...' takes less formatting, only needs to be on one line.
That's not necessarily an advantage. If the continuation line gets deleted -- either accidentally or on purpose --- without deleting the prior ..., the next line becomes the continuation. Probably not what the programmer wanted. In the {} case, deleting the continuation line, immediately lights up the rest of the program as a comment as a visual warning, and it will not compile. Much safer, methinks.
-Phil
Safety. Perhaps a little danger would sharpen our minds, like double-underscored symbols documented in a proportional font - "a canon pointed at the user's feet" as Walter Banks of Bytecraft used to say.
Python uses \
I wouldn't be opposed to that either.
I like the … idea and glad to see @ersmith isn’t upset about it
Sounds like a winner.
I agree with Terry... \ is used in Python & C, so it is familiar for the kind of developers that you are trying to "woo" over to Spin2.
Spin already has uses for \ (for abort, and for post-effect operations in Spin2).
I'm not going to make any promises about updating Flexspin to keep up with all Chip's changes.
it is a give and take @ersmith and currently @cgracey should think about getting some those nifty extensions you have like optional parameter of a method, def/ifdef, and build his debugger as single application.
why replace the comment trick already working.
you need ... and CRLF, 5 chars.
you need { CRLF }, 4 chars
it is even shorter, already supported and no change is needed.
And it throws a visible error when deleting the second or more line
The whole .. or ... or .../ or whatever discussion is sort of moot, all of them require more typing, not less
You need the CRLF anyways for your new line so anything shorter as 2 chars will not work so why not stick to { and } ?
confused,
Mike
I can only use Flexspin. Would it be possible for it to continue parsing automatically if binary operator or just | at end of line?
I'd like to replace this
with this
long (SCASWr_0+1) << 28 | (SCASBr_0+1) << 24 | (LODSWr_0+1) << 20 | (LODSBr_0+1) << 16 | (STOSWr_0+1) << 12 | (STOSBr_0+1) << 8 | (MOVSDr_0+1) << 4No need for any new/extra chars.