I like the design of comments in this language: <h...
# linking-together
k
I like the design of comments in this language: https://gist.github.com/jckarter/2839239
i
Yeah, that's a really good idea. Wow. Ah, it's Joe Groff. That makes sense.
w
I think Lua comments go like:
Copy code
--[[
--]]
And that you could nest them with something like:
Copy code
--[=[
--[[
--]]
--]=]
I might be getting this confused with some String syntax.
k
Indeed, I've seen this idea for strings. The basic benefit is to grow the number of escape characters linearly rather than exponentially like happens with backslashes.
@Ivan Reese where do you know Joe Groff from? I think I've encountered the Clay language at some point.
i
He was one of the people at Apple working on Swift when it first launched, and was a center point of the early community.
👍 2
e
the use of a signature line is an intriguing idea, the same technique is used in MIME sections. However if you repeat the same signature in your code, and mistakenly delete one of them you will have trouble figuring out what happened. This is why Lua uses symmetrical sequences; so a duplicated beginning or end can be detected.
k
The best of both worlds may be to just allow string literals at the top level, and use Lua's scheme above to simulate comments.
Copy code
[ comment name [
...
] comment name ]
i
A step further and you have literate programming... which is available in my main language (CoffeeScript) but not something I've ever embraced.. I suppose because I want to indent my comments to match the code. If only there were a way to do bare text comments at any indentation in a whitespace language. Perhaps, a font-aware language and rich text editor?
k
We're going a bit far afield now, but I think calling systems like CoffeeScript's LP makes it harder to see what's truly powerful about LP: perfect flexibility in ordering code fragments. More elaboration: http://akkartik.name/post/literate-programming (Literate CoffeeScript is one of the quasi-literate systems I refer to there.)
❤️ 1
d
I don't like this block comment syntax because the sequences marking the start and end of the comment are identical. It is more robust, and less visually ambiguous, if the start- and end-comment sequences are different. I don't like signature lines, for the same reasons that @Edward de Jong / Beads Project gives. If you convert an existing block of code into a block comment, you have to search all the lines in that block to make sure you aren't using the same signature as an existing block comment within the block you are commenting out. I don't like that requirement. The simplest design that works is to only provide line comments like
#
in Python or
//
in C. If you are using a smart editor designed for programming, then you already have high level commands for commenting or uncommenting a block of code using line comments. My preferred block comment syntax would use distinct start-comment and end-comment tokens. The syntax would be designed so that any syntactically valid block of code can be commented out, simply by wrapping the block of code in start- and end-comment tokens. Implementing this last requirement correctly is tricky, in the presence of nested comments, and I'm not sure if I've seen a language with block comments that works the way I want.