The three dots (ie. ellipsis) could be used for line continuation, but I know it is used in C++ for variable arguments and potentially could be used for the same purpose in SPIN2 if we ever get that capability officially extended to the language. The \ char is handy for continuation because people know it from C macros and it is short. Also using up three printable chars for continuation reduces the visible characters possible in limited column width screens.
How about a semicolon? It would make a statement -- a poke in the eye to syntactically cluttered languages, like C and Perl, that use it for just the opposite purpose.
@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.
; however, despite its well established meaning in common english, has long been associated with a statement ending by certain code styles. Ie. Not continuing.
Does the fact that \ is an operator mean you can't use it for something else? I mean can't you match
"\ whitespace EOL" as a continuing line during parsing when you see \ before attempting to handle the operator related stuff? Or does that break the parsing model somehow? Seems like it should be possible to do at least in my mind, but I don't know all the existing constraints.
The nice thing about {} is that it can put a line break anywhere, regardless of syntactical considerations -- except in the middle of a quoted string. But even then, a { at the end of an open string could be handled unambiguously with smarter compilation.
I'm thinking about going full-emoji, where emojis can replace a lot of operator syntax and they can be parts of labels. This could draw in the younger engineers.
@cgracey said:
I'm thinking about going full-emoji, where emojis can replace a lot of operator syntax and they can be parts of labels. This could draw in the younger engineers.
That'd bring 'em in. It would also be great for increasing engagement with a whole other group of people wanting to regulate what emoji's can and can't be used in the language and how it triggers them etc.
I'm thinking about going full-emoji, where emojis can replace a lot of operator syntax and they can be parts of labels. This could draw in the younger engineers.
That's a great idea! The entirety of a Spin program could be expressed as a rebus:
If you use a trailing ellipsis to continue to the next line, the next line should start with a leading ellipsis. That will cement the pairing and eliminate any chance of a semantic error due to a deleted line.
Still, though, {
}the solution is already in the language. No additions necessary.
I'll throw in my vote for just using the already built-in curly braces, too. I think the readability in the continued line really comes more from where you break it and where you place the continuation on the next line than it does from the character(s) indicating that it happened shrug
@avsa242 said:
I'll throw in my vote for just using the already built-in curly braces, too. I think the readability in the continued line really comes more from where you break it and where you place the continuation on the next line than it does from the character(s) indicating that it happened shrug
Well, you can't make everyone happy. These chars: { [ } ] |are on many EU-keyboards behind the Alt Gr-key which is cumbersome to use, at least when 10-finger typing, also backticks and frontticks are non-intuitive as well as somewhat difficult to see on the screen. Personally I'd prefer that the parser would be able to understand if it should continue parsing on next line or not, it would however not need to try to parse a string that is divided on several lines.
Three dots ... (or perhaps an underscore) would be my next choice, but as said, you can't make everyone happy, you just can try to make as few as posible unhappy.
Chip,
I bumped into this existing rather elegant solution in Roger's video driver:
' start a VGA display output, pointing it to the first (and only) region for its display list, and auto allocate it a COG
id := video.initDisplay(cog, { the cogid to use (-1 = auto-allocate)
} @display, { the display structure address in HUB RAM
} output, { video output type (VGA/DVI etc)
} basePin, { base pin number (hsync pin) of DVI pin group
} vsyncPin, { VSYNC pin (not used for DVI)
} displayFlags, { display flags
} @lineBuffers, { address of the consecutive two scan line buffers in HUB RAM
} LINEBUFSIZE, { size of a single scan line buffer in bytes
} timing, { obtain stock timing to use, (or create custom timing instead)
} 0, { optional external memory mailbox address in HUB RAM (0=none)
} video.initRegion( { setup a single text region as the display list
} @region, { region structure address in HUB RAM
} video.TEXT, { type of region is text
} 0, { size of region in scan lines (0=to end of screen)
} flags, { region specific flags (if enabled text flashes if BG colour > 7)
} @palette, { address of default palette to be used by region
} @font, { address of default font to be used by this region
} FONTHEIGHT, { number of scan lines in font
} @screenbuf, { address of screen buffer in HUB RAM
} 0) { link to next region, NULL = last region
} )
Yeah! That's what I'm talkin' 'bout! And it really clinches it: combines multiline statements with explicatory comments. You can't do that with "..." alone.
Comments
Try 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) << 4Mike
The three dots (ie. ellipsis) could be used for line continuation, but I know it is used in C++ for variable arguments and potentially could be used for the same purpose in SPIN2 if we ever get that capability officially extended to the language. The \ char is handy for continuation because people know it from C macros and it is short. Also using up three printable chars for continuation reduces the visible characters possible in limited column width screens.
Backslash is already an operator in Spin2, no dice
How about a semicolon? It would make a statement -- a poke in the eye to syntactically cluttered languages, like C and Perl, that use it for just the opposite purpose.
-Phil
+1
I still think {
} is the way to go.
I mean, it's already supported. Why add more cruft? (See my signature line below.)
-Phil
The same idea had occured to me a while back, but it just seemed so.... opposite of convention.
Should we just use ';'?
... or if a single char is desired then _
Both suggest something more.
; however, despite its well established meaning in common english, has long been associated with a statement ending by certain code styles. Ie. Not continuing.
I'd favor the dots or underscore.
The single underscore is used as a dummy variable to ignore unwanted method results.
x,_ := polxy(r,t)Oh hell no! I was just kidding! That would have to be {
} the worst choice.
-Phil
Deleted.
The semicolon is the only printable character that is unrecognized by the compiler. It means trouble.
Yeah, save it for something important.
-Phil
Sounds like the first idea was the best ...
Unless going full
APLwith custom chars and launching a custom Parallax keyboardhttps://en.m.wikipedia.org/wiki/APL_(programming_language)
Bonus: For those that prefer curly wurly braces, they can optionally use those too.
Does the fact that \ is an operator mean you can't use it for something else? I mean can't you match
"\ whitespace EOL" as a continuing line during parsing when you see \ before attempting to handle the operator related stuff? Or does that break the parsing model somehow? Seems like it should be possible to do at least in my mind, but I don't know all the existing constraints.
Regarding the backslash, save it to escape special characters in a string:
"This is a quote character: \"."
Easier to read than this:
"This is a quote character: ", $22
-Phil
I suppose backslash would still mess up the compile when someone chooses to break the line after a command using that symbol.
The nice thing about {} is that it can put a line break anywhere, regardless of syntactical considerations -- except in the middle of a quoted string. But even then, a { at the end of an open string could be handled unambiguously with smarter compilation.
-Phil
I'm thinking about going full-emoji, where emojis can replace a lot of operator syntax and they can be parts of labels. This could draw in the younger engineers.
That'd bring 'em in. It would also be great for increasing engagement with a whole other group of people wanting to regulate what emoji's can and can't be used in the language and how it triggers them etc.
That's a great idea! The entirety of a Spin program could be expressed as a rebus:
🐝 E
5
i.e. B := 5
-Phil
Ugh! Couldn't get the quails to stay on one line.
Chip,
If you use a trailing ellipsis to continue to the next line, the next line should start with a leading ellipsis. That will cement the pairing and eliminate any chance of a semantic error due to a deleted line.
Still, though, {
}the solution is already in the language. No additions necessary.
-Phil
exactly.
Mike
I'll throw in my vote for just using the already built-in curly braces, too. I think the readability in the continued line really comes more from where you break it and where you place the continuation on the next line than it does from the character(s) indicating that it happened shrug
Cheers
+1
Well, you can't make everyone happy. These chars: { [ } ] |are on many EU-keyboards behind the Alt Gr-key which is cumbersome to use, at least when 10-finger typing, also backticks and frontticks are non-intuitive as well as somewhat difficult to see on the screen. Personally I'd prefer that the parser would be able to understand if it should continue parsing on next line or not, it would however not need to try to parse a string that is divided on several lines.
Three dots ... (or perhaps an underscore) would be my next choice, but as said, you can't make everyone happy, you just can try to make as few as posible unhappy.
Programming in C must be especially painful, then!
-Phil
Yup, it is! That's why I chose to teach Python at university level instead of C, Java, Javascript, C# ...
Chip,
I bumped into this existing rather elegant solution in Roger's video driver:
' start a VGA display output, pointing it to the first (and only) region for its display list, and auto allocate it a COG id := video.initDisplay(cog, { the cogid to use (-1 = auto-allocate) } @display, { the display structure address in HUB RAM } output, { video output type (VGA/DVI etc) } basePin, { base pin number (hsync pin) of DVI pin group } vsyncPin, { VSYNC pin (not used for DVI) } displayFlags, { display flags } @lineBuffers, { address of the consecutive two scan line buffers in HUB RAM } LINEBUFSIZE, { size of a single scan line buffer in bytes } timing, { obtain stock timing to use, (or create custom timing instead) } 0, { optional external memory mailbox address in HUB RAM (0=none) } video.initRegion( { setup a single text region as the display list } @region, { region structure address in HUB RAM } video.TEXT, { type of region is text } 0, { size of region in scan lines (0=to end of screen) } flags, { region specific flags (if enabled text flashes if BG colour > 7) } @palette, { address of default palette to be used by region } @font, { address of default font to be used by this region } FONTHEIGHT, { number of scan lines in font } @screenbuf, { address of screen buffer in HUB RAM } 0) { link to next region, NULL = last region } )Yeah! That's what I'm talkin' 'bout! And it really clinches it: combines multiline statements with explicatory comments. You can't do that with "..." alone.
-Phil