# Scattering assignment

Michael Moore (mike@mail.datasys.net)
Mon, 18 Nov 1996 11:34:34 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    Chris Schlesiger wrote:
    >
    > I've gotten to really like the scattering assignment in the new server
    > version. I was wondering what people would think of adding on to it the
    > following:
    >
    >   Type requirements.
    >

    <snip>

    >
    > So for each of the types:  STR, INT, FLOAT, OBJ, ERR, LIST, we would need
    > a special character prefix. Now, I haven't given much thought to what
    > characters to use for each (though # immediately comes to mind for OBJ),
    > and I suppose that whatever characters are chosen would have to be noted
    > carefully so that people don't accidently start variables with them (and
    > unintentionally force their data type if used in a scatter assignment),
    > but I think that's only a minor problem.

    How about a new reserved word-- "as", used for type checking.

    In simple assignment,

         <var> = <expr> AS <type>;

    Or, in scattered assignment,

         {<var1>, <var2>} = {<expr1> AS <type>, <expr2> AS <type>};

    If the result of <expr> is not of type <type> then E_TYPE is raised.  (Or
    if the verb is !d then E_TYPE is assigned to <var>.)

    This eliminates the need for a bunch of new special characters that would
    undoubtedly conflict with existing code or make it a much bigger chore to
    add to the MOO code parser.

    Now that I think of it, I wouldn't mind being able to typecast, such that

         x = #3 AS NUM
         => 3

    but since tonum(), tostr(), etc. exist there really isn't a need to add
    new stuff to MOO for it.  :)

    > Now, the above suggests that it might be nice to combine the ? with the
    > type specifier so that z must to be either STR or NUM but not
    > both, but I think that's probably getting a bit complex.

    And probably unnecessary.  Though, maybe the above example could work like

        z = <expr> AS {NUM, STR};

    You could probably take it even one level higher and allow an expression
    to the right of the 'as', which should return a NUM or a LIST of NUM.
    But this leads to strangeness like which error should be used if that
    expression returns the wrong type?  E_INVARG?  (Remember, E_TYPE woule be
    reserved for when the assignment didn't match the specified type.)

    And, again, I personally don't see much use for it.

    That's my two bits' worth.  :)