Argh. Well a good point there. I think both of the above look pretty bad, and it makes me wish for //.
something: function [ ][ // start
foo: #bar // important
collect [ // collect
keep #foo // foo part not #baz
keep foo // bar part
keep #{DECAFBAD} // requisite binary
] // end collect
// would you *always* need a space? (URL!s embed //)
] // end
For comparison, double-semicolon:
something: function [ ][ ;; start
foo: #bar ;; important
collect [ ;; collect
keep #foo ;; foo part not #baz
keep foo ;; bar part
keep #{DECAFBAD} ;; requisite binary
] ;; end collect
;;no space required
] ;;end
Given that many non-C-like languages use it, it can't be completely my C++ bias that thinks that's visually decent.
In fact, I think your example is compelling enough I'm going to switch back to // as my vote for alternate-end-of-line-comment, which it was historically (before I was editing some Travis YAMLs a bit and decided # was kind of pleasing there)
Technically speaking you don't need the space after the //, just before it, for URL! to work. Otherwise http://thiswouldlooklikeacomment.com. But maybe for safety requiring a space after is good too. It's good practice for legibility, anyway.
//=//// THOUGH IN REBOL'S SOURCE I DO STUFF LIKE THIS ///////////////=//
//
// Because I think it makes for nice visual blocks of comment
//
//=//////////////////////////////////////////////////////////////////=//
-- Because it came up that some languages use "--"
-- it is interesting to consider what that would look like
--
something: function [ ][ -- start
foo: #bar -- important
collect [ -- collect
keep #foo -- foo part not #baz
keep foo -- bar part
keep #{DECAFBAD} -- requisite binary
] -- end collect
--would spaces be necessary, (would --would be a word?)
] -- end
We apply "--" today as an enfix decrement operator, e.g. foobar: -- 5 as equivalent to foobar: foobar - 5. But it does make for a pleasingly light-yet-separating comment.
Today's approximation is ;--
;-- Because it came up that some languages use "--"
;-- it is interesting to consider what that would look like
;--
something: function [ ][ ;-- start
foo: #bar ;-- important
collect [ ;-- collect
keep #foo ;-- foo part not #baz
keep foo ;-- bar part
keep #{DECAFBAD} ;-- requisite binary
] ;-- end collect
;--no spaces necessary
] ;-- end
Which I guess, all things considered, is not that terrible, but still noisy and three-characters-plus-space to start a comment is a bit heavy handed.
Well, as we know I'm an admirer of Haskell, it seems that Ada was a thought out language also in many ways. And as we've seen, people do ;-- often to try and make up for semicolon's weakness.
I think the -- operator is not used often enough to rule out this usage, when commenting is so fundamental.
Yes. So -- is a no for me because I don't think any comment syntax should use valid word chars.
This means // is OK (as is \\) for commenting. However I'm still very happy with semi-colon. But it would be nice for a true multi-line comment syntax. So perhaps?...
I really like the -- syntax (with a space required after it), but I am partial to it because I have been designing my own language for a while now, and it uses something similar (I use 6 dashes, but that's a whole other story). Anyway, I spent days trying out different combinations of characters, and dashes were one of the few characters that really make comments stand out, and they look nice too.
I think changing the enfix syntax, like @gchiu suggested, is a good compromise. Or what do you think about using 3 or 4 dashes to differentiate them? Yea, it's more to type, but I'm of the opinion that if you're writing comments then some effort should be involved, and so you should spend time doing it properly. Having to type more characters makes you think about this and nudge you in the direction of quality over typing something quick and useless. It also makes the comments stand out more from the actual code.
In addition, what do you think about a dashes + block syntax for multi-line comments?
---- [
Because it came up that some languages use "--"
it is interesting to consider what that would look like
]
something: function [ ] [
---- foo has something important to say,
---- see how this stands out from the actual code
foo: #bar
---- collect the values
collect [
keep #foo ---- foo part not #bar
keep foo ---- #bar part
keep #{DECAFBAD} ---- requisite binary
] ---- end collect
] ---- end
It looks good. We definitely should think about this.
Still on the table. I think @rgchris had a good argument against #. I try // now and again, and I guess I haven't completely been sold on it, even though it's used elsewhere.
There's a lot of pushback on this from people who want to use -- in identifiers. @draegtun voiced concern above, the usual peanut gallery of Rebol2 people don't like it.
I guess the real thing to think about is that while it looks nice, it leads to a situation where you either disallow things like --foo and foo-- and --foo--, or you run the risk of making something that is very easily mistaken for a comment. (Or you mean to type a comment and wind up with a WORD! instead.) It seems unsafe and confusing to have it as a comment and not forbid those things.
Yet if you look at things like command line switches in UNIX, they frequently look like --foo. That's a fairly legitimate use of a WORD! and dialecting to talk to command-line things.
On the other hand, if we look at //, here you have something that is lousy as a WORD! anyway (you can't put it in a PATH! easily). No one is clamoring for //foo// as a WORD! exemption, or protesting loudly for ///. It has clout in popular languages as a comment marker...perhaps not as "academic pedigreed" as those using --, but certainly known to more users.
Being able to lay out a command-line dialect is probably the Achilles Heel for dashes as comment for me. So I'll re-center my vote back to slashes. Not quite as "light" feeling, but the desirable qualities of dashes make them a commodity for non-comment purposes.
~~~~ [
@giuliolunati pointed out that there is also "~~"
which may have some of the benefits of -- while
being more "fringe" and not used much.
]
something: function [ ] [
~~~~ foo has something important to say,
~~~~ see how this stands out from the actual code
foo: #bar
~~~~ collect the values
collect [
keep #foo ~~~~ foo part not #bar
keep foo ~~~~ #bar part
keep #{DECAFBAD} ~~~~ requisite binary
] ~~~~ end collect
] ~~~~ end
It's awfully close to --, yet still the squiggliness makes it feel a little...messy. Un-confident, wishy-washy perhaps? We often associate this shape these days with spelling errors in what you're typing.
This debate perfectly illustrates my problem with Ren-C.
Just because @hostilefork does not like ; as comment and calls it "terrible abomination", there is debate what other character to use. This is not fixing some bug, neither it is improvement to the language (although some of previous fixes or improvements may be very questionable IMO), it just wants to replace ; use with some of the perfectly valid Rebol characters, therefore limiting Rebol's lexical space.
I know, this is not Rebol, it is hostile fork of Rebol called Ren-C, but anyway. It is not a fix, not an improvement, it's just another example of @hostilefork's hate for all things Rebol.
I can't speak for the other updates that have been made, but in this case, I respectably disagree. The suggestions discussed here and in the chat are definitely an improvement over the semi-colon. Code is read many more times than it is written, and anything that makes them more readable and stand out from the code the better. They should be aesthetically pleasing
I don't think a lot of language designers think about comments and they tack on whatever way they're used to, from the last language they worked in. I think it is very worthwhile to explore this, even if it does mean that we end up using //, like most everyone else, due to the constraints imposed by other parts of the language.
That's too bad, I was really rooting for this. I am going to think about this some more. I have one other idea I'll share a little later today. Been a really busy morning for me, and can't get into it right now.
Four out out five of these assertions are absolutely wrong and off topic.
Questioning and thinking about everything in Rebol is relevant and fair game in this project including aesthetics. Some people value aesthetics more than others, but if chosen well for a language they provide benefits to everyone.
I do not have strong opinions on comments expecting them to be chosen according to the needs of the language, but I don't think they're that great for comments. Yes the lexical space is important, maybe why Carl chose semicolon, because he didn't think he'd use it anywhere else.
I'm still suggesting that \ could be used for line commenting. It's not used in Rebol otherwise, and it's an invalid word currently.
It's solid, and not flimsy like ; and doesn't need double typing such as -- and doesn't remove from the lexical space. Why doesn't anyone like it? Because they're not used to it; it's a forth covention so Carl would be quite used to it since he wrote his own forth.
some (code [that looks]) kind of Englishy \ a Rebol comment
I do agree it stands out more boldly as a single character than semicolon, and it's true it doesn't have any other use today (outside of appearance in string literals).
However:
It is truly unfamiliar, the least common of choices we've spoken of (; is very popular among other languages by comparison). Regardless of any merits it may have, that can wind up being a liability when it comes to first impressions...when a more familiar choice like // wouldn't cause anyone to blink.
No matter what single character you use for a comment, just having a single unit of width may still be too thin and easily overlooked...considering that it completely shifts the semantics to "computer-not-reading-it-anymore".
The common usage of \ for escapes in several mediums means trying to paste code strings that use them can be a problem. I can't seem to reproduce the exact problems in SO chat I remember having when we were discussing it as expression barrier (e.g. [a \ b \ c]) so maybe they've changed it there. But it has problems other places, you couldn't put it in a C string literal without turning it into \\ for instance.
Note: **\\** in MarkDown comes out as a single slash here on Discourse, you have to put backticks in it, then what I actually had to write to get that was:
`**\\**`
And I don't know how to get MarkDown to show that inline with my sentences using asterisks and backticks. I could only get it by putting it indented on its own line as a code block, as above.
@MarkEye (or @Mark-hi, or whoever he is these days, could we consolidate those accounts?) raised a point that there is a value in the design to reserve a character that you don't use in the language at all. That gives templating systems a "meta" escape, so if you think there might ever be a reason to slip some backchannel information into a Rebol script when being processed by non-Rebol tools it could come in handy there. One could make ^\ an escaping for backslash in strings to further facilitate such applications (currently it is an escaping for ascii 28, or "file separator", which is not very useful by comparison)
e.g.:
Rebol [
Title: {Script munged by non-Rebol-LOADing preprocessor}
Purpose: {
The idea here is that you've got a dumb tool that doesn't
know anything about parsing Rebol, but is able to safely
mess around with a script written in Rebol using a basic
substitution mechanism.
}
]
// Preprocessor can use a simple check to ignore ^\
print {
Escaped ^\ could be another way of having backslash in
strings, which scripts geared toward having this kind
of substitution done on them would elect to use to bypass
the substitution and get a literal backslash. However
scripts not intended to be used in this way would just use
a plain backslash as today.
}
data: read %"/var/www/\$server.name\"
for-each x data [
print [\inject $php.or.whatever %<gibberish>%\ x]
]
When you combine these motivations, I think backslash may serve a higher calling staying under the radar as it is today.
The current comment delimiter is also okay if embedded into a literal string.
Or, if necessary we could make it \space
I do find using the caret ^ annoying I came across lots of carets in some JSON which we had to escape.
I'm only replying to what is probably rhetorical because I don't want to imply any support for any of the assertions. "not an improvement" was on topic if it was defending semicolon, but maybe I misunderstood that.
I agree, it's tempting, because it is so close, but it does feel a little messy / wishy-washy.
>>
Do you like this? Maybe these characters are already used?
This has typically been used for bit shifting in other languages.
It does draw your eye toward the comment, like it is pointing at
something you should pay attention to. There is a nice symmetry
if you were to use << for the closing of multi-line comments too.
<<
something: function [ ] [
>> foo has something important to say,
>> see how this stands out from the actual code
foo: #bar
>> collect the values
collect [
keep #foo >> foo part not #bar
keep foo >> #bar part
keep #{DECAFBAD} >> requisite binary
] >> end collect
] >> end
I have the impression from some long-forgotten source that Carl picked the semicolon for comments so he wouldn't have to remove his fingers from the keyboard. I myself do like that feature. However, I also would not mind if there were some comment character that was the same for all/most languages. That way, a person could make up some little embedded syntax for some as yet-undefined reason and embed it in code using the comment character which would be the same for all languages. Other than that I get along very well with the semicolon for comments.
