RE: Please VOTE! Changing keywords to functions

Lenard Lindstrom wrote:

>import  -- keyword
>from    -- keyword
>assert  -- function? (will there be a case where assert 
>                      statements can be optimized away?)

Yes they can, so assert will stay a keyword.

>raise   -- function? (but does it make sense to pass it as an 
>                      argument?)

Maybe not, but Greg's argument still holds.  There is no reason for "raise"
to be a keyword either.

>import and from are like the object statement in that they 
>assign values to identifiers. I would hate to have to do 
>import($foo). Or would it be foo = import("foo") ?

Yes, I hadn't thought "import" through.  I find it much easier to throw it
up on the mailing list and let you all do the thinking. :-)  

It would be especially onerous to tell the programmer that they cannot do
"from abc import *" and then make them type out all the functions they are
importing using "import(from="math","sin","cos","abs", ...".

This can be a general rule that anything that reuires l-values like "del"
and "import" should be keywords.

>break and continue are flow control statements that take 
>optional labels. They definitely are keywords. The parenthesis 
>were removed from the C return statement years ago. Should 
>they be put back in Prothon?

I would hate to have to change how the labels work on break and continue,
but I must admit that right now they work in a static way and my talk goes
on and on about the evils of static versus dynamic solutions.  Would there
ever be any advantage to having a construct like this?

    loop1: while True:
        loop2: while True:
            blah blah blah
            x = $loop2
            blah blah blah
            continue(x)    # x is calculated

Continue could be overriden.  It actually might also be nice to override
return:

      def return(value):
            print('leaving '+curFuncName()+' with value '+value)
            Object.return(value)