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 


an integer

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


 not exactly
 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?


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

[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


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



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



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