Summary of language revision proposals

1 Approved revision proposals:

Top

Many thanks to those who have made these proposals.

1. Omit @ for the coroutine creation in the presence of yield statement.
   Andrew Cooke (python-list)
   After this changing:
   • calling to a function without yield statement will invoke that function;
   • calling to a function with yield statement will create and return a coroutine or generator object.
2. For the self increment or decrement operations ( ++i, --i, i++, i-- ), support only the prefix ones, to avoid confusion for people from other languages.
   Andor (newsmth.net), and others
3. double precision, change to use D suffix instead of 00 ending, which can become a pitfall in generated codes;
   Andor (newsmth.net)
4. multiple cases for the same code block in switch-case statements: use comma instead of colon to seperate the cases.
   Andor (newsmth.net)
   Without such modification, there will be a pitfall after commenting a code block:
   switch  (  value  )
   {
        case  C1  :
             #{ temporarily disabled
           do_sth();
           #}
        case  C2  :
        case  C3  :
             do_sth_else();
        default:
   }
   after the modification, it will be OK:
   switch(  value  )
   {
        case  C1  :
             #{ temporarily disabled
           do_sth();
           #}
        case  C2  ,
                 C3  :
             do_sth_else();
        default:
   }

2 Undecided revision proposals:

Top

1. list/map/tuple/array construction with keywords like:
   list(...), map/dict(...), tuple(...), array(...).
   Andor (newsmth.net)
   they are not absolutely necessary, but could be insteresting to somebody.
2. a few coding style enforcements:
   compulsory white space between statement keywords and brackets, and compulsory no white space between function name and brackets?
   Andor (newsmth.net)
3. Tuple construction: compulsory field operator => for the first item, like:
   
   tup1  =  (  x  =>  1.0,  2.0  )  # named first item
   tup2  =  (  =>  1.0,  2.0  )  # anonynous first item
   tup3  =  (  =>  1.0  )  # ok for one item tuple
   
   this will solve the problem that sometimes during code modifications, a tuple expression may be reduced to ( expression ) will not be treated as a tuple.
   However, this problem maybe is not serious, since Dao has a typing system, which can detect the error at compiling time because of the inconsistent assignment of ( expression ) to a tuple variable, or because of the inconsistent use of the variable that is supposed to be certain type of tuple.

If you have any suggestions or comments, please post them as follow-up. Many thanks in advance.