# Scattering assignment

Eric Mercer (mercere@netcom.ca)
Mon, 18 Nov 1996 12:06:34 PST

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

    At 08:23 AM 11/18/96 PST, 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.

    I agree this would be nice, primarily to prevent threads from failing
    outside the verb where the real bug is.  That's more of a problem in the -d
    verb world, which of course we're all moving away from with the great new
    error handling routines, but there's a lot of LambdaCore legacy code around.
    I wrote a small util to do this checking, but including a call to it in
    every executable verb I own seems like it isn't worth the processing time
    (unless your code is routinely buggy).  I'm thinkng if the checking was done
    by the server it might be much faster, but again, maybe not worth the
    processor time.  The in-db approach does let you also test the values of
    LIST elements, though, which the proposed type-checking system wouldn't.

    I'd like to see an automated type checking system eventually available (CASE
    tool) that could look over your code and that of verbs called and report
    that there is inconsistant typing, but MOO's weak typing and -d verbs
    probably make that a distant dream.  You'll note the top line in my sample
    code uses a common DU MOO documentation header, which is intended to help
    make that CASE tool work eventually, and for now makes it easier on
    programmers, at least.  The type can also have the form {LIST, INT} to
    indicate either a LIST or INT is acceptable for that arg.

    In any case, here's my type-checking util...

    "invalid_args(values LIST, template LIST [, template2 LIST ...]) -> result
    BOOL";
    "Checks the args sent to a verb for conformity to a data types";
    "template, or to any of a set of templates.  Returns true if none of";
    "the templates fit.";
    "A typical template might be {INT, LIST, {FLOAT,STR}} in which";
    "args[1] is an INT, args[2] a LIST, and args[3] a FLOAT or a STR.";
    "Note that the calling verb might subsequently test args[2] against a";
    "new template to insure that LIST itself has correct data types.";
    "ex: invalid_args(args, {INT, LIST, {FLOAT,STR}});";
    {values, @templates} = args;
    for template in (templates)
      for arg in [1..length(values)]
        if (typeof(template[arg]) == LIST)
          if (!(typeof(values[arg]) in template[arg]))
            continue template;
          endif
        elseif (typeof(values[arg]) != template[arg])
          continue template;
        endif
      endfor
      return 0;
    endfor
    "No template matched";
    return 1;

    Eric Mercer (EricM @ Diversity University and BioMOO)