standard colour for C++
Chor Lit
I asked Bjarne Stroustrup about the idea of adding colour standard for
C++, and he said that it is very difficult for compiler vendors to
change their IDE. But do you think it is possible ? Note that the
proposed colour standard is not just merely to ease the eye only as
what presently is in C++ compilers, but to aid in syntax disambiguation
and other advantages.
Here are a few advantages that I can think of:
1. By allowing keywords and literals in different colours, C++ can
introduce new keywords easily because they are now living in different
'space'.
2.Colours can even be used to differentiate between the operator '>'
from the angle bracket '>' in template.
3. Also, names such as '1ABC' and '.ABC' will be acceptable because we
can always differentiate character '1' and '.' from thier usual type,
no confusion.
4. We can even drop the comment '//' and '/* */' since comment can also
be assigned a unique colour.
5. We can also assign a special colour to all overloaded operators to
differentiate from normal operators and dropped the keyword 'operator'
in the definition.
I believe there are plenty more advantages in using colours in C++.
There are a lot of details in C++ that I can't think of that might
benefit from using colour scheme in C++. I hope this will spark an idea
to the committee. What do you think ?
Victor Bazarov
> I asked Bjarne Stroustrup about the idea of adding colour standard for
> C++, and he said that it is very difficult for compiler vendors to
Everything is possible. What you're talking about, however, has nothing
to do with the language itself, really. It has everything to do with
products (like IDE or text editors) that exist independently of C++ as
a language. Most of them nowadays, however, provide some kind of colour
differentiation for elements of the language[s] (keywords, operators,
punctuation, types, variables, literals, etc.)
There is no "adding colour to C++" or "standard colour for C++". C++
is a _language_ with a bunch of syntactic and semantical rules, just
like English. How do you set standard colour for English, for example?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Geo
And how would this work on my white on black VMS terminal ?
John Carson
news:enj5p0$j3j$1...@news.datemas.de
> Chor Lit wrote:
>> I asked Bjarne Stroustrup about the idea of adding colour standard
>> for C++, and he said that it is very difficult for compiler vendors
>> to change their IDE. But do you think it is possible ? [..]
>
> Everything is possible. What you're talking about, however, has
> nothing to do with the language itself, really. It has everything to
> do with products (like IDE or text editors) that exist independently
> of C++ as a language. Most of them nowadays, however, provide some
> kind of colour differentiation for elements of the language[s]
> (keywords, operators, punctuation, types, variables, literals, etc.)
>
> There is no "adding colour to C++" or "standard colour for C++". C++
> is a _language_ with a bunch of syntactic and semantical rules, just
> like English. How do you set standard colour for English, for
> example?
I believe that the OP was proposing that the user have the ability to
manually color source code and that the compiler would interpret source code
differently depending on the color chosen. Color can in principle be as much
a part of a language as letters.
--
John Carson
Eberhard Schefold
> I believe that the OP was proposing that the user have the ability to
> manually color source code and that the compiler would interpret source code
> differently depending on the color chosen. Color can in principle be as much
> a part of a language as letters.
You're contradicting yourself. Either the specific /markup/ (distinct
for "comment", "variable" etc.) is significant and stored and only
presented in the user's color scheme. Or the actual /color/ is significant.
In the first case the markup would become part of the language standard,
not the color. Since everything has eventually be stored as a digital
file, storing the markup would simply mean a change in the language,
like tags. I don't think that would be very attractive.
In the latter case we would all have to use the same colors which would
have to specified with the language. I can't believe that you're
actually contemplating this idea for just one second. What about
developing on devices that don't support color? What about printing
code? What about posting code to a newsgroup? Books? Photocopies?
Microfiche? What about colors that are reserved socially/religiously in
a given culture? What about people who are color blind? How do you even
store the colors in a file (we're back to the tags here)? What if I
don't like red for a comment?
It's a joke, right?
Simon G Best
> Hi,
>
> I asked Bjarne Stroustrup about the idea of adding colour standard for
> C++, and he said that it is very difficult for compiler vendors to
> change their IDE. But do you think it is possible ? Note that the
> proposed colour standard is not just merely to ease the eye only as
> what presently is in C++ compilers, but to aid in syntax disambiguation
> and other advantages.
>
>
> I believe there are plenty more advantages in using colours in C++.
> There are a lot of details in C++ that I can't think of that might
> benefit from using colour scheme in C++. I hope this will spark an idea
> to the committee. What do you think ?
Bad idea, I think, for various reasons (some of which are obvious, such
as colour-blindness).
One reason, that's perhaps not obvious to most people, is that it could
actually cause confusion for those with some kinds of synesthesia. It
would be like colour-coding the days of the week, and finding that those
with weekday-to-colour-scheme synesthesia (such as me) tend to miss
meetings, and turn up for meetings on the wrong days. Colour-code
something blue, on the basis that it's going to happen on Monday, and I
might actually miss it as a result. For me, Monday is most definitely
red. Depending on the shade of blue, I might even turn up for it on
Thursday!
Simon
--
What happens if I mention Leader Kibo in my .signature?
Julián Albo
> I believe that the OP was proposing that the user have the ability to
> manually color source code and that the compiler would interpret source
> code differently depending on the color chosen. Color can in principle be
> as much a part of a language as letters.
Given that the source code is a stream of characters, there are no other way
to "add color" than to codify it. There is no difference between that and
adding keywords or punctuations.
And if you like colors, the IDEs are already able to paint them. I see no
substantial difference between a menu entry called "paint in green the
selection" and other called "comment out the selection". You just need an
option to hide the "/*" and the "*/" when syntax coloring is on, if you
dislike to see him. Same for any other color usage. You can also draw icons
or colored shapes in the menu entries.
Certainly color, shape, or any other thing (even whitespace) can be used as
syntactically significant elements. There are a bunch of esoteric
programming languages that do. But mainstream languages use just streams of
characters.
And let's not forget the many types of color blindness. And monochrome
listing devices.
--
Salu2
Markus Svilans
I'm going to have to go ahead and get you to forget that idea.
Thanks.
Max M.
>
> What do you think ?
Not too funny. You should elaborate more, and write it in the form of an
academic paper. Stroustrup's article on whitespace overloading was much
funnier.
Max
red floyd
> Chor Lit wrote:
>> [ill considered proposal to mandate code coloring in the Standard redacted]
>
> And how would this work on my white on black VMS terminal ?
>
Or for anyone who is color-blind?
Kevin Hall
> John Carson wrote:
>
> > I believe that the OP was proposing that the user have the ability to
> > manually color source code and that the compiler would interpret source code
> > differently depending on the color chosen. Color can in principle be as much
> > a part of a language as letters.
>
> You're contradicting yourself. Either the specific /markup/ (distinct
> for "comment", "variable" etc.) is significant and stored and only
> presented in the user's color scheme. Or the actual /color/ is significant.
Well, I'm going to defend John Carson on this one. In *principle*
color could be as much a part of the language as the letters.
Obviously, either the C++ comittee or compiler vendors would have to
figure out a way (or ways) to encode color into a file. And XML type
document comes to mind.
Now, is this a good idea? I don't think so! Is John Carson advocating
it is a good idea? No. Does John Carson think it's a good idea?
Well, he didn't say -- but I'm going to give him the benefit of the
doubt and assume he thinks it is a terrible idea.
Eberhard Schefold wrote:
> In the first case the markup would become part of the language standard,
> not the color. Since everything has eventually be stored as a digital
> file, storing the markup would simply mean a change in the language,
> like tags. I don't think that would be very attractive.
>
> In the latter case we would all have to use the same colors which would
> have to specified with the language. I can't believe that you're
> actually contemplating this idea for just one second. What about
> developing on devices that don't support color? What about printing
> code? What about posting code to a newsgroup? Books? Photocopies?
> Microfiche? What about colors that are reserved socially/religiously in
> a given culture? What about people who are color blind? How do you even
> store the colors in a file (we're back to the tags here)? What if I
> don't like red for a comment?
I think we're all in agreement here! ;-)
> It's a joke, right?
Ask the OP!
I don't think that John Carson was joking though. I for one agree with
him -- it's possible. I just think it's a very bad idea.
Julián Albo
>> It's a joke, right?
> Ask the OP!
The OP is called Chor Lit... look for the expression "cabeza de chorlito" in
a spanish dictionary.
But in any case, never underestimate the power of jokes... Parrot started to
live as an April Fool's joke ;-)
--
Salu2
John Carson
news:1167952930.6...@v33g2000cwv.googlegroups.com
> Eberhard Schefold wrote:
>> John Carson wrote:
>>
>>> I believe that the OP was proposing that the user have the ability
>>> to manually color source code and that the compiler would interpret
>>> source code differently depending on the color chosen. Color can in
>>> principle be as much a part of a language as letters.
>>
>> You're contradicting yourself. Either the specific /markup/ (distinct
>> for "comment", "variable" etc.) is significant and stored and only
>> presented in the user's color scheme. Or the actual /color/ is
>> significant.
>
> Well, I'm going to defend John Carson on this one. In *principle*
> color could be as much a part of the language as the letters.
> Obviously, either the C++ comittee or compiler vendors would have to
> figure out a way (or ways) to encode color into a file. And XML type
> document comes to mind.
>
> Now, is this a good idea? I don't think so! Is John Carson
> advocating it is a good idea? No. Does John Carson think it's a
> good idea? Well, he didn't say -- but I'm going to give him the
> benefit of the doubt and assume he thinks it is a terrible idea.
Thank you. I was merely seeking to clarify the OP's intentions and pointing
out that the use of color can be part of a language in principle. Indeed
"color coding" is widely used to convey information (think traffic lights).
However, I don't see it as suitable for C++ for many of the reasons already
given in this thread.
--
John Carson
Eberhard Schefold
> Thank you. I was merely seeking to clarify the OP's intentions and pointing
> out that the use of color can be part of a language in principle.
I stand to my objection: If you allow the programmer to choose his/her
own color scheme, it's the markup that's actually significant, not the
color.
> Indeed
> "color coding" is widely used to convey information (think traffic lights).
You get the information from traffic lights in two ways: color and/or
position. Color is fine as redundant information when it helps you to
pick up the information faster. But it's not a good idea to use color as
the single means to transport information.
John Carson
news:enl303$7mr$1...@news4.fe.internet.bosch.com
> John Carson schrieb:
>
>> Thank you. I was merely seeking to clarify the OP's intentions and
>> pointing out that the use of color can be part of a language in
>> principle.
>
> I stand to my objection: If you allow the programmer to choose his/her
> own color scheme, it's the markup that's actually significant, not the
> color.
Good for you, but it is unclear whose views you are objecting to. Your
comments don't appear to be relevant to mine.
>> Indeed
>> "color coding" is widely used to convey information (think traffic
>> lights).
>
> You get the information from traffic lights in two ways: color and/or
> position. Color is fine as redundant information when it helps you to
> pick up the information faster. But it's not a good idea to use color
> as the single means to transport information.
As I have already pointed out, I am not advocating this for C++. You are
right that color coding is often used in conjunction with other signals, and
there are good reasons for this. You are wrong if you are claiming that
color is never used on its own as a signal.
My only point was that language can in principle take many forms. Your point
that some forms of language are more efficient and/or more widely
intellligible than other forms of language is correct but not in conflict
with anything I have said.
--
John Carson
Eberhard Schefold
> Good for you, but it is unclear whose views you are objecting to. Your
> comments don't appear to be relevant to mine.
Yes, I realize I misunderstood both you and Victor. I thought the
discussion was about "absolute" vs. "programmer definable" color coding.
Sorry for the confusion.
> As I have already pointed out, I am not advocating this for C++. You are
> right that color coding is often used in conjunction with other signals, and
> there are good reasons for this. You are wrong if you are claiming that
> color is never used on its own as a signal.
I did not claim that, I said it's a bad idea (which we all agreed to).
Color code for electronic components, e.g. resistors, comes to mind. I
read that up to 10% of males have difficulties discriminating red and
green. (http://en.wikipedia.org/wiki/Color_blind)
Chor Lit
Thanks for the feedback. Below are some of my opinion/suggested
solutions.
I have an idea of how to solve the difficulty for
1.)colour-blind people
2.)people that are using monochrome monitor
3.)people suffering from synesthesia ( as pointed out by Simon G Best
in earlier thread)
To solve 3 problems above, the C++ compiler can use tooltips to show
the 'type' when the mouse pointer lingers over the keyword or token.
Just like in Windows, there are tooltips appearing a moment after you
linger the mouse pointer over icons. Tips can be presented in other
ways though, such as showing type information at the bottom(or anywhere
suitable) of the the window when the cursor is adjacent to the keyword
or token.
Actually, using XML to code colour wasn't in my mind. I was thinking of
storing the colour information adjacent to the Unicode/ANSI character
set. E.g, if the Unicode/ANSI is 16 or 8 bits, then another 8 bits can
be added to each token as the colour information. Inevitably, the text
file will grow large, but after compiling, the object code is still the
same size as the present C++ object file. So, there is no penalty in
size and efficiency.
The only thing is that C++ text file must be edited in C++ compiler or
a kind of special editor in order to handle this kind of encoding. This
special editor will have the following features:
1.) will save C++ files in a standard, portable format. This standard
file format will be discussed by the C++ committee and when finished,
is an open-standard.
2.) This special editor will also have tooltips to show the type of the
keyword or token.
3.) User can also set prefered colours for keywords, tokens and
comments. So if you like red for comment, you can set it. No, this does
not contradict the standard colour. E.g, if you want the comment to be
red, but the standard colour for comment is green, then the editor will
still save all comments in green, but present them as red on screen.
This also have the advantage of giving colour-blind people to choose
colours that can be differentiated by themselves.
4.) A context menu in ambiguous situation to let user choose the
correct type. Eg. when typing the character '>', the contect menu will
show 4 choices:
i.)the text 'greater-than operator' in red colour
ii.)the text 'overloaded-operator' in orange colour
iii.)the text 'template's angle-bracket' in green colour
iv.)the text 'normal character' in black colour.
The 4th choice shows that it is possbile to use '>' as part of the name
of a function or variable.
5.) Other helpful features such as column-wise editing, hex-format
display, or any other useful features.
I think this special editor can be developed by C++ committee/community
and placed it at the C++ Standardization website to be downloaded for
free. Also, all the above features, except no. 5, applies to all C++
compilers as well.
Eberhard Schefold wrote that:
"...What about printing code? What about posting code to a newsgroup?
Books? Photocopies? Microfiche? What about colors that are reserved
socially/religiously in a given culture?..."
I answer them one by one below.
1.)printing code
The only way is to have a colour printer. Nowadays, colour printers are
very common.
2.)posting code to newsgroup
I must admit that the C++ community will have to suffer a little bit
in the beginning when posting to newsgroup. Later, if the standard
colour is used commonly in the future, things will change. Hosts like
Google will meet the market demand and add colour toolbar for editing
text in colour. I hope.
3.)Books
All publishers can print colour text. Colour-printing in books are very
common. Maybe Eberhard has thought of some situation that I missed or
can't imagine ? Can you please explain ?
4.)Photocopies
Well, I don't know whether there are colour photocopies ? Maybe there
is.
5.) Microfiche
I can't answer this confidently. According to the encyclopedia, there
are colour microfiche, but more expensive. I have not use or seen
microfiche before, so I don't know. Anybody?
6.)colors that are reserved socially/religiously in a given culture
I am unaware of this, and cannot imagine how? Can you please elaborate
? But anyway, as mentioned above, the special editor or C++ compiler
can allow user to choose thier choice of colour, but will still save
C++ programs in standard colour.
Eberhard Schefold
> Thanks for the feedback. Below are some of my opinion/suggested
> solutions.
Chor,
I see you mean this seriously, and I respect that. Possibly it's only my
own narrow-mindedness, but I don't think your idea will catch on. I
think there's a reason why human scripts, technical or mathematical
notations generally don't use color for carrying (non-redunant)
information. I believe the reasons are obvious. Yes, color photocopying,
newsgroups, scanners, microfiche etc. are all available or conceivable
(if at the price of money and/or compatibilty). However, I believe that
we should be able to create, transmit, document or archive over the
broadest variety of channels and media possible. Support for color /is/
a very strong constraint. If I have an idea sitting on the toilet, I
want to be able to write it down unambiguously with a single pen on
toilet paper. If I'm stranded on a desert island, I still want to be
able to write the text into the sand with a stick. Color on paper fades
and the information is lost faster than with simple black-and-white.
Fancy transmission channels do break down, and you're stuck with plain
ASCII support.
We can go on discussing all these detail aspects ad infinitum. I'm sure
there ultimately is a solution for everything. My own experience tells
me to follow the KISS principle.
jalina
editor for a new language where a table is declared and initialized by
inserting a "Table" in a document.
Victor Bazarov
> Chor Lit a écrit :
>> [..]
>> I believe there are plenty more advantages in using colours in C++.
>> There are a lot of details in C++ that I can't think of that might
>> benefit from using colour scheme in C++. I hope this will spark an
>> idea to the committee. What do you think ?
>>
> I agree with. Why use only colors ? I suggest to use OpenOffice as a
> editor for a new language where a table is declared and initialized by
> inserting a "Table" in a document.
The code should be formatted as a spreadsheet. With fonts.
IR
Victor Bazarov wrote:
We should also add fuzzy logic right into the language. IMNSHO this
must take the form of standardized smileys, so that the compiler can
guess our feelings about a peculiar code portion.
Indeed, every bell and whistle we can think of should be integrated
into C++. This would for sure make it the most powerful language of
these times, and would lay the foundation for next-generation
languages that support mind-reading.
As a side note, I find it amazing how people (me included) can jump
on a well written troll. ;-)
Best whishes to you all.
Cheers,
--
IR