Re: defaults

In my experience with applications of CLASSIC, a number of real applications did
require some kind of defaults.
Input completion was the most common form of solution.  As others before have
mentioned, no one particularly loves this solution, but we do have
1 - indisputable need for some kind of defaults
2 - empirical evidence that input completion can be made to work (by "normal
users" and not just rocket scientists).

I actually had a section on input completion for defaults in an early version of
the tricks of the trade section i wrote on using classic  but ended up taking it
out before broad publication because it was a little messier than what I normally
think of as clever ways of using conceptual modeling to capture intended meaning.

We did have some users of CLASSIC use procedural attachments to handle
defaults.   Actually some of them used defaults this way BEFORE we became very
specific about the contract peter mentions below.  We wrote down the conditions
under which they could use procedural attachment without causing trouble for the
internal truth maintenance system to keep them from using procedural attachments
to handle defaults and then not giving the system enough information to provide
truth maintenance when things change.

so this is just another email supporting
input completion for default encoding.

d


"Peter F. Patel-Schneider" wrote:

> From: tim finin <finin@cs.umbc.edu>
> Subject: Re: defaults
> Date: Tue, 22 Jan 2002 11:44:04 -0500
>
> >
> > I think the only answer to providing some support for defaults is to do it
> > they way it's been done in KL-TWO (as I recall) and Classic.  The idea was,
> > if I remember right, to include conventions for providing defaults that
> > was outside the core of the language and for which no semantics was given.
>
> My memory may be failing, but I don't remember any support for defaults in
> any version of Classic.  It would be possible to achieve some of the effect
> of defaults by using procedural attachment in Classic, but that would
> violate the procedural attachment contract, unless all that was done was a
> kind of input completion.
>
> > Tim
>
> peter

--
 Deborah L. McGuinness
 Knowledge Systems Laboratory
 Gates Computer Science Building, 2A Room 241
 Stanford University, Stanford, CA 94305-9020
 email: dlm@ksl.stanford.edu
 URL: http://ksl.stanford.edu/people/dlm
 (voice) 650 723 9770    (stanford fax) 650 725 5850   (computer fax)  801 705
0941

Received on Tuesday, 22 January 2002 13:13:13 UTC