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

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.

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.  :)

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

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

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

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

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..

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

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