6 ms·

C++ Resyntaxed

33 points by parenthesis 16y ago

eru 16y ago
Looks sane to me.
- deleted 16y ago
  [deleted]
daniel02216 16y ago
This looks fairly interesting, at first glance. Is there a similar document for C by itself?
tlb 16y ago
Changing the declaration syntax could be a big improvement, but changing assignment operators is a bad idea. (summary: a=b now tests for equality, a:=b is assignment). I know if I start using a language where a=b means equality test, I'm going to make that mistake in Javascript, Python, and every other language I use. When designing a new language, remember that people spend most of the time using other languages. So don't be gratuitously incompatible in dangerous ways.
- gte910h 16y ago
  Yeah, := should be assigns, and == should be equal, and = should be an error.
- MichaelGG 16y ago
  That does happen to me. F# uses = for equality and <- for assignment, and I end up doing the same in C#. Fortunately in C#, only boolean expressions can be used in predicates so it hasn't caused me any more than a compilation error yet.
- jimbokun 16y ago
  Go claimed := as the initialization operator, leaving = and == as before. Since you should avoid assignment after initialization when possible, anyway, I suspect = could be avoided altogether in a lot of code.
- contextfree 16y ago
  Somebody needs to take a stand at some point. The C-style equality and assignment operator conventions are awful things.
- wheels 16y ago
  The most honerous case of that that I've run into is in the ChucK programming language (for audio synthesis, MIDI processing, etc.). In general it's quite nice, but the assignment operator is "=>" and the assignee goes on the right, e.g.: 140 => int beatsPerMinute; http://github.com/scotchi/Chuckery/blob/master/MidiDelay.ck http://github.com/scotchi/Chuckery/blob/master/MidiDelay.ck It's really close to all of the other Java-ish family of languages for the most part, but I find myself having to fix a dozen auto-piloted assign errors every time I try to run the code.
jlangenauer 16y ago
I'm not a huge fan after a quick read - the new syntax adds too many new keywords for my tastes e.g. type, inherits, abstract, lang, obj, func etc. I'm of the school of thought that words with semantic meaning should be used as much as possible for expressing the logic and meaning of the program itself, rather than the language. Otherwise, it becomes harder to separate the actual program from the language - this is one of Java's problems. Particularly take the class declarations as an example: type ListClass : class inherits public ListBase, private virtual ListImpl { /* member declarations */ } adds nothing but verbosity to the C++ declaration: class ListClass : public ListBase, private virtual ListImpl { /* member declarations */ };
- alextgordon 16y ago
  "Make everything as simple as possible, but not simpler" seems a good rule to design languages by. The common case should be expressible with as little syntactic friction as possible, without making the language ambiguous or unreadable. ": class inherits public" is just 23 characters of pointless line noise.
  - eru 16y ago
    Perhaps inheritance shouldn't be the common case in the first place?
barrkel 16y ago
Unfortunately, most of the pathology of C++ lies in its semantics, not its syntax.
- eru 16y ago
  Yes. But it's better than nothing.
vorg 16y ago
C++ could use both syntaxes, old and new, just as programmers can use any syntax coloring scheme when viewing a program in an IDE. Anything sitting above a language's AST is customizable by programmers. It's just for historical reasons why programs in different languages are stored as consecutive text in files, instead of, say, tree structures on disk.
swah 16y ago
(not the author) Inside C++, there is a much smaller and cleaner language struggling to get out. - Bjarne Stroustrup Clay is an attempt at creating that language. Link: http://tachyon.in/clay/ http://tachyon.in/clay/
_sh 16y ago
A couple of notes: 1. This paper is from 1996 (oh my! 14 years), and so does not consider the syntactic clean-up performed with C++0X. 2. The paper is co-authored by Damian Conway (http://en.wikipedia.org/wiki/Damian_Conway http://en.wikipedia.org/wiki/Damian_Conway), perl legend, author of Quantum::Superpositions (http://search.cpan.org/~dconway/Quantum-Superpositions-1.03/lib/Quantum/Superpositions.pm http://search.cpan.org/~dconway/Quantum-Superpositions-1.03/...) 3. This seems to be part of research conducted on 'Human Factors in Programming Languages', which includes another paper on the design of SPECS (the syntactic clean-up mentioned in this paper), and another interesting-sounding one: 'Seven Deadly Sins of Introductory Programming Language Design' (see http://www.csse.monash.edu.au/~damian/papers/ http://www.csse.monash.edu.au/~damian/papers/).
roryokane 16y ago
I'm surprised and disappointed that this still requires a semicolon after each line, and parentheses around the conditions in for, if, etc. statements.
- eru 16y ago
  Yes, going closer to Python-style in this regard would have been nice.
kqueue 16y ago
seriously?

C++ Resyntaxed

33 points by parenthesis 16y ago

eru 16y ago

Looks sane to me.

deleted 16y ago
[deleted]

daniel02216 16y ago

This looks fairly interesting, at first glance. Is there a similar document for C by itself?

tlb 16y ago

Changing the declaration syntax could be a big improvement, but changing assignment operators is a bad idea. (summary: a=b now tests for equality, a:=b is assignment). I know if I start using a language where a=b means equality test, I'm going to make that mistake in Javascript, Python, and every other language I use. When designing a new language, remember that people spend most of the time using other languages. So don't be gratuitously incompatible in dangerous ways.

gte910h 16y ago
Yeah, := should be assigns, and == should be equal, and = should be an error.
MichaelGG 16y ago
That does happen to me. F# uses = for equality and <- for assignment, and I end up doing the same in C#. Fortunately in C#, only boolean expressions can be used in predicates so it hasn't caused me any more than a compilation error yet.
jimbokun 16y ago
Go claimed := as the initialization operator, leaving = and == as before. Since you should avoid assignment after initialization when possible, anyway, I suspect = could be avoided altogether in a lot of code.
contextfree 16y ago
Somebody needs to take a stand at some point. The C-style equality and assignment operator conventions are awful things.
wheels 16y ago
The most honerous case of that that I've run into is in the ChucK programming language (for audio synthesis, MIDI processing, etc.). In general it's quite nice, but the assignment operator is "=>" and the assignee goes on the right, e.g.: 140 => int beatsPerMinute; http://github.com/scotchi/Chuckery/blob/master/MidiDelay.ck http://github.com/scotchi/Chuckery/blob/master/MidiDelay.ck It's really close to all of the other Java-ish family of languages for the most part, but I find myself having to fix a dozen auto-piloted assign errors every time I try to run the code.

jlangenauer 16y ago

I'm not a huge fan after a quick read - the new syntax adds too many new keywords for my tastes e.g. type, inherits, abstract, lang, obj, func etc. I'm of the school of thought that words with semantic meaning should be used as much as possible for expressing the logic and meaning of the program itself, rather than the language. Otherwise, it becomes harder to separate the actual program from the language - this is one of Java's problems. Particularly take the class declarations as an example: type ListClass : class inherits public ListBase, private virtual ListImpl { /* member declarations */ } adds nothing but verbosity to the C++ declaration: class ListClass : public ListBase, private virtual ListImpl { /* member declarations */ };

alextgordon 16y ago
"Make everything as simple as possible, but not simpler" seems a good rule to design languages by. The common case should be expressible with as little syntactic friction as possible, without making the language ambiguous or unreadable. ": class inherits public" is just 23 characters of pointless line noise.
- eru 16y ago
  Perhaps inheritance shouldn't be the common case in the first place?

barrkel 16y ago

Unfortunately, most of the pathology of C++ lies in its semantics, not its syntax.

eru 16y ago
Yes. But it's better than nothing.

vorg 16y ago

C++ could use both syntaxes, old and new, just as programmers can use any syntax coloring scheme when viewing a program in an IDE. Anything sitting above a language's AST is customizable by programmers. It's just for historical reasons why programs in different languages are stored as consecutive text in files, instead of, say, tree structures on disk.

swah 16y ago

(not the author) Inside C++, there is a much smaller and cleaner language struggling to get out. - Bjarne Stroustrup Clay is an attempt at creating that language. Link: http://tachyon.in/clay/ http://tachyon.in/clay/

_sh 16y ago

A couple of notes: 1. This paper is from 1996 (oh my! 14 years), and so does not consider the syntactic clean-up performed with C++0X. 2. The paper is co-authored by Damian Conway (http://en.wikipedia.org/wiki/Damian_Conway http://en.wikipedia.org/wiki/Damian_Conway), perl legend, author of Quantum::Superpositions (http://search.cpan.org/~dconway/Quantum-Superpositions-1.03/lib/Quantum/Superpositions.pm http://search.cpan.org/~dconway/Quantum-Superpositions-1.03/...) 3. This seems to be part of research conducted on 'Human Factors in Programming Languages', which includes another paper on the design of SPECS (the syntactic clean-up mentioned in this paper), and another interesting-sounding one: 'Seven Deadly Sins of Introductory Programming Language Design' (see http://www.csse.monash.edu.au/~damian/papers/ http://www.csse.monash.edu.au/~damian/papers/).

roryokane 16y ago

I'm surprised and disappointed that this still requires a semicolon after each line, and parentheses around the conditions in for, if, etc. statements.

eru 16y ago
Yes, going closer to Python-style in this regard would have been nice.

kqueue 16y ago

seriously?