Re: Scattering assignment

• Date: Mon, 18 Nov 1996 11:34:34 PST
• From:
  Michael Moore <mike@mail.datasys.net>
• Content-Transfer-Encoding: 7bit
• Content-Type: text/plain; charset=us-ascii
• References: <Pine.ULT.3.93.961118110643.5807E-100000@geni16>

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

• Re: Scattering assignment
• From: Michael Brundage <brundage@laurel.ipac.caltech.edu>

• Scattering assignment
• From: Chris Schlesiger <cschles@lamp0.arl.army.mil>

• Prev: Re: Scattering assignment
• Next: Re: Scattering assignment
• Index: MOO-cows
• Thread: MOO-cows