Shop Learn P1 Docs P2 Docs
Continue-parsing-on-next-line in Spin2 — Parallax Forums

Continue-parsing-on-next-line in Spin2

cgraceycgracey Posts: 13,873
edited 2022-11-11 07:08 in Propeller 2

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.

«13

Comments

  • TubularTubular Posts: 4,475

    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

  • cgraceycgracey Posts: 13,873

    @Tubular said:
    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.

  • maccamacca Posts: 507

    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. :smile:

  • cgraceycgracey Posts: 13,873
    edited 2022-11-11 09:11

    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.

  • msrobotsmsrobots Posts: 3,612
    edited 2022-11-11 11:48

    do it the COBOL way, a - in column 7 of the next row...

    Mike

  • msrobotsmsrobots Posts: 3,612

    or maybe ... on the beginning of the next row?

    Mike

  • Wuerfel_21Wuerfel_21 Posts: 3,310
    edited 2022-11-11 14:08

    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.

  • ersmithersmith Posts: 5,515

    @Wuerfel_21 said:
    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 code I 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.

  • @ManAtWork said:
    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 code I 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.

    @ersmith said:

    @Wuerfel_21 said:
    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.

    Reporting the top level open bracket in such a case is good enough I'd assume.

  • JonnyMacJonnyMac Posts: 8,314
    edited 2022-11-11 17:11

    @cgracey said:
    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.

    Agreed, because two dots are used to separate range endpoints. Perhaps to promote readability the token could be space dot dot dot space.

  • TonyB_TonyB_ Posts: 2,002
    edited 2022-11-11 18:05

    @cgracey said:
    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
    

    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

    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)<<4
    

    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) << 4
    
  • JRoarkJRoark Posts: 1,148

    @JonnyMac said:
    the token could be space dot dot dot space.

    The hams in the group are having a NSFW giggle at this one.
    I’ll just see myself out… 🤣

  • JonnyMacJonnyMac Posts: 8,314

    The hams in the group are having a NSFW giggle at this one.

    I guess I have to look that up -- I'm not a ham and it was not a deliberate joke.

  • cgraceycgracey Posts: 13,873

    @JonnyMac said:

    @cgracey said:
    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.

    Agreed, because two dots are used to separate range endpoints. Perhaps to promote readability the token could be space dot dot dot space.

    And TAB-dot-dot-dot is what I would type

  • cgraceycgracey Posts: 13,873
    edited 2022-11-11 19:20

    @TonyB_ said:

    @cgracey said:
    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
    

    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

    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)<<4
    

    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) << 4
    

    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.

  • TonyB_TonyB_ Posts: 2,002
    edited 2022-11-11 19:50

    @cgracey said:
    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.

  • @JonnyMac said:
    I'm not a ham ...

    Really? Not what I'd heard :smiley::blush:

  • What was wrong with {
    } this?

    It already works without additional syntactical gingerbread.

    -Phil

  • JonnyMacJonnyMac Posts: 8,314

    And TAB-dot-dot-dot is what I would type

    I try to avoid using TAB characters in programming; I always configure IDEs to convert TAB to spaces.

  • cgraceycgracey Posts: 13,873

    @"Phil Pilgrim (PhiPi)" said:
    What was wrong with {
    } this?

    It already works without additional syntactical gingerbread.

    -Phil

    '...' takes less formatting, only needs to be on one line.

  • '...' 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

  • cgraceycgracey Posts: 13,873

    @"Phil Pilgrim (PhiPi)" said:

    '...' 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.

  • RaymanRayman Posts: 12,924

    I like the … idea and glad to see @ersmith isn’t upset about it

    Sounds like a winner.

  • dgatelydgately Posts: 1,540

    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.

  • ersmithersmith Posts: 5,515

    @ke4pjw said:
    Python uses \
    I wouldn't be opposed to that either.

    Spin already has uses for \ (for abort, and for post-effect operations in Spin2).

    @Rayman said:
    I like the … idea and glad to see @ersmith isn’t upset about it

    I'm not going to make any promises about updating Flexspin to keep up with all Chip's changes.

  • msrobotsmsrobots Posts: 3,612

    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

  • TonyB_TonyB_ Posts: 2,002
    edited 2022-11-12 15:37

    @ersmith said:
    I'm not going to make any promises about updating Flexspin to keep up with all Chip's changes.

    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

    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)<<4
    

    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) << 4
    

    No need for any new/extra chars.

Sign In or Register to comment.