www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++ Resyntaxed

reply bearophile <bearophileHUGS lycos.com> writes:
This is a short article I have just found on Reddit that shows a possible
alternative syntax for C++:
"A Modest Proposal: C++ Resyntaxed", Ben Werther & Damian Conway:
http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html

It says:
The language was designed to ensure that the new syntax was LALR(1) parsable,
grammatically unambiguous and required no semantic feedback from parser to
tokenizer.<

That reminds me of D :-) Some C++ abstract declarators: int // integer int * // pointer to integer int *[3] // array of 3 pointers to integer int (*)[3] // pointer to array of 3 integers int *() // function having no parameters, returning pointer to integer int (*)(double) // pointer to function of double, returning an integer In this new syntax they are like this, they seem more readable to me: int // integer ^ int // pointer to integer [3] ^ int // array of 3 pointers to integer ^ [3] int // pointer to array of 3 integers (void -> ^int) // function having no parameters, returning pointer to integer ^ (double -> int) // pointer to function taking a double, returning an integer Are the the following D equivalents? (me being not sure shows that new syntax may be better than the current D one) int // integer int * // pointer to integer int*[3] // array of 3 pointers to integer int[3]* // pointer to array of 3 integers int * function() // function having no parameters, returning pointer to integer double function(int) * // pointer to function taking a double, returning an integer Notes: - I presume ^ comes from Pascal. - This new syntax uses := and = instead of = and == as in Pascal. - I like -> to denote a function, but how to denote a delegate? Another example, the declaration of set_new_handler in C++: void (*set_new_handler(void (*)(void)))(void); That you can declare in two stages too (C++ again): typedef void (*new_handler)(void); new_handler set_new_handler(new_handler); Their equivalents in this new syntax: func set_new_handler : (^(void->void) -> ^(void->void)); and: type new_handler : ^(void->void); func set_new_handler : (new_handler -> new_handler); Again they seem more readable to me. (This syntax has other differences too, that you can see in the article, but those ones are quite easy to spot and nice). Bye, bearophile
Mar 12 2008
next sibling parent Jascha Wetzel <firstname mainia.de> writes:
bearophile wrote:
 It says:
 The language was designed to ensure that the new syntax was LALR(1) parsable,
grammatically unambiguous and required no semantic feedback from parser to
tokenizer.<

That reminds me of D :-)

unfortunately, D isn't LALR(1) parsable. would be nice, though.
Mar 12 2008
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to bearophile,

 double function(int) * // pointer to function taking a double, returning 

not exactly int function(double) // pointer to function taking a double, returning an integer I'll assume that's a typo though. :)
Mar 12 2008
parent bearophile <bearophileHUGS lycos.com> writes:
BCS:
 double function(int) * // pointer to function taking a double, returning an
integer

int function(double) // pointer to function taking a double, returning an integer I'll assume that's a typo though. :)

I see little value in masking my ignorance among friendly people: that error of mine is part a typo (the swap of double and int) and part ignorance (the * I have put at the end). But I am learning (my point was that a better syntax like that new C++ seems more natural to me). Bye and thank you, bearophile
Mar 13 2008
prev sibling next sibling parent reply renoX <renosky free.fr> writes:
bearophile Wrote:
 This is a short article I have just found on Reddit that shows a possible
alternative syntax for C++:
 "A Modest Proposal: C++ Resyntaxed", Ben Werther & Damian Conway:
 http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html
 
 It says:
The language was designed to ensure that the new syntax was LALR(1) parsable,
grammatically unambiguous and required no semantic feedback from parser to
tokenizer.<

That reminds me of D :-)

For the second part yes, but not for the first part :-( [cut]
 Notes:
 - I presume ^ comes from Pascal.
 - This new syntax uses := and = instead of = and == as in Pascal.

Which is a bad idea here, I know nobody who is confused by =,== instead of := and = more than 5 minutes after an explanation, so let's keep the shortest notation.
 - I like -> to denote a function, but how to denote a delegate?

[cut]
 Again they seem more readable to me.
 (This syntax has other differences too, that you can see in the article, but
those ones are quite easy to spot and nice).

To me also, this syntax is more readable than C++ or D's one. I don't agree with some of their decision: - obj declaration feels weird for variable, they should have used 'var' like Scala which works both for variable and for objects variable. - ':=' for assignment: no that's the most usual case, use the shorter '=' - obj <variable_name> : <type>; and obj <variable_name> = <default> : <type>; I prefer Limbo's syntax which works nicely with and without type inference. var <variable_name> : <type>; // initialised to <type>'s default value var <variable_name> : <type> = <value>; // initialised to <value> var <variable_name> := <value>; // type inferred from <value> Maybe ^ could be used instead of return like in Smalltalk and could be used instead of ^ to mean 'pointer to'. Regards, renoX
Mar 13 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
renoX:
 Easy: use func param -> return for functions and delegate param -> return, not
just -> alone (or maybe -> alone is for functions)..

Maybe this for functions int -> float and this for delegates: int => float And maybe this one for closures (but that syntax for closures may suffice) :-) int ==> float It's shorter :-) Note that the same ->/=> syntax can be used to define anonymous functions too (it's a syntax like C# one). Bye, bearophile
Mar 13 2008
next sibling parent renoX <renosky free.fr> writes:
bearophile a écrit :
 renoX:
 Easy: use func param -> return for functions and delegate param -> return, not
just -> alone (or maybe -> alone is for functions)..

Maybe this for functions int -> float and this for delegates: int => float And maybe this one for closures (but that syntax for closures may suffice) :-) int ==> float It's shorter :-)

Shorter yes, but a bit too 'mysterious' for my taste.. That said, I'm also guilty of the same sin as I suggested replacing 'return' by ^ (like in Smalltalk), to my defense return is so common that the programmer will get used to the ^ notation quite quicky..
 Note that the same ->/=> syntax can be used to define anonymous functions too
(it's a syntax like C# one).

Sure. Bye, renoX
 
 Bye,
 bearophile

Mar 13 2008
prev sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
On Thu, 13 Mar 2008, bearophile wrote:

 renoX:
 Easy: use func param -> return for functions and delegate param -> return, not
just -> alone (or maybe -> alone is for functions)..

Maybe this for functions int -> float and this for delegates: int => float

 And maybe this one for closures (but that syntax for closures may suffice) :-)
 int ==> float

Closures? You mean for functions that heap allocate the context when scope exits? I thought D does that automatically now.
 It's shorter :-)
 Note that the same ->/=> syntax can be used to define anonymous functions too
(it's a syntax like C# one).

I guess Landin had the -> syntax in mind already in 60s (and possibly someone else before him). Many functional languages have used it ever since. It's a shame that most popular languages never started to use it (except now). Those who do not learn from history are doomed to repeat it..
Mar 13 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Jari-Matti Mäkelä:
 Closures? You mean for functions that heap allocate the context when scope 
 exits? I thought D does that automatically now.

That syntax allows the compiler to avoid doing things automatically, so it's *sure* the programmer wants a true closure. Bye, bearophile
Mar 13 2008
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
bearophile wrote:
 This is a short article I have just found on Reddit that shows a possible
alternative syntax for C++:
 "A Modest Proposal: C++ Resyntaxed", Ben Werther & Damian Conway:
 http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html
 
 It says:
 The language was designed to ensure that the new syntax was LALR(1) parsable,
grammatically unambiguous and required no semantic feedback from parser to
tokenizer.<

That reminds me of D :-)

I find it interesting that they simplify the language by *adding* at least 5 new keywords, maybe more even. Take that all you keyword accountants! More keywords == simpler! Although I have to admit, even *I* think they're going a little overboard when they define "pre" and "post" as keywords just to allow creating the operator overloads "operator pre ++" and "operator post ++". Surely there's a way to improve that syntax without introducing two whole new keywords. Like "operator <>++" and "operator ++<>" or some such. --bb
Mar 13 2008
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
bearophile wrote:
 This is a short article I have just found on Reddit that shows a possible
alternative syntax for C++:
 "A Modest Proposal: C++ Resyntaxed", Ben Werther & Damian Conway:
 http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html
 
 It says:
 The language was designed to ensure that the new syntax was LALR(1) parsable,
grammatically unambiguous and required no semantic feedback from parser to
tokenizer.<

That reminds me of D :-)

I took a look at the first reference. The 1980 paper called "Type syntax in the language "C": an object lesson in syntactic innovation". There you can see griping about inaccuracies and incompleteness of the spec which sounds all too familiar to anyone whose been around here long. Nice, in a way, to see that ~6 years out of the gate C was still having such problems. Means there's hope for D yet. :-) --bb
Mar 13 2008
prev sibling parent reply Jarrod <qwerty ytre.wq> writes:
Huh, that's the university I went to. Same campus, too. I even had a user 
account on csse.monash.edu.au
Odd to see it turn up in the D newsgroup I guess.

On a more related note: It's an okay syntax, I wouldn't say I'm a huge 
fan of it but it does appear it would make cleaner code.
Mar 14 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Jarrod:
 On a more related note: It's an okay syntax, I wouldn't say I'm a huge 
 fan of it but it does appear it would make cleaner code.

I think no one forces you to take it all. You can adopt the bits you like of it, like some of the things I have shown, for D. Bye, bearophile
Mar 14 2008