Subject: Re: How about this for a built-in...

From: [email-masked] (Seth I. Rich)
Date: Wed, 7 Oct 1992 14:40:27 -0700

yduJ tells me:

  q = queued_tasks();
  index = task_id() in $list_utils:slice(q,1);
  if (index)
    return q[index];
  else
    return E_ARGS;
  endif

I -know- that it can be done that way.  (I do it that way on LambdaMOO.)
But the server has that information easily at hand and it ought to be 
available... is there any reason why a get_task_info() shouldn't be a 
builtin?

Seth / Blackbriar

---

From: Pavel Curtis <[email-masked]>
Date: Thu, 8 Oct 1992 10:33:30 -0700

> Date:	Wed, 7 Oct 1992 14:40:27 -0700
> From:	[email-masked] (Seth I. Rich)
> 
> is there any reason why a get_task_info() shouldn't be a builtin?

There is an important principle in language design, that of conceptual
parsimony.  In essence, it says you should make the set of primitive constructs
and concepts in the language as small and well-structured as possible.  One
should not, in particular, consider adding features to a language that can be
implemented in terms of existing primitives unless that implementation is
*intrinsically* too inefficient or too onerous for reasonable use.

In this case, the get_task_info() function can easily be written in MOO using
existing primitives, is very unlikely to be used in a context where the
difference in performance is noticeable, and is not significantly more
difficult to use as a verb than as a built-in function.  The principle of
conceptual parsimony, therefore, argues against making it a built-in function.

There are, of course, other principles of language design, other considerations
that should be taken into consideration, but I can't think of any that argue in
favor of making get_task_info() a primitive.  Let me therefore turn your
question around, Seth:

	Is there any reason why get_task_info() *should* be a built-in?

Conceptual parsimony says that new features are, if you will, guilty until
proven innocent.

	Pavel/Haakon