

  The <Language> Machine (c)
  Copyright 1994-2005
  April 25, 2008


 What it does.

  The <Language> Machine finds the answers that a given
description supplies to a given question; the given description
and the given question must be expressed in <Language>.


 How you make it do what it does.

  Here is a description in <Language>:

    /* Count runs of 1's in a nonempty list of 0's and 1's. */

    $topic @blocks(*{0;1},$number)
    $para @blocks
    $rule @blocks([0],0).
    $rule @blocks([1],1).
    $rule @blocks([0,0|L],N) $if @blocks([0|L],N).
    $rule @blocks([0,1|L],N) $if @blocks([1|L],N).
    $rule @blocks([1,1|L],N) $if @blocks([1|L],N).
    $rule @blocks([1,0|L],N) $if @blocks([0|L],M), $add(M,1,N).
    $end_para

  Here is a question in <Language>:

	@blocks([0,1,1,1,0,1,1,0,0,1,1,0,0,1,0,1,1,0],L).

  And here, according to The <Language> Machine, are the answers
that the given description supplies to the given question:

	Searching...
	L->5
	One <answer>.



 <notation>

  Words and phrases between "<" and ">" refer to <Language>.

  For example,

	<sentence>

means a sentence in <Language>.


	<this> <that>

means a <this> followed by a <that>.


	( <this> | <that> )

means a <this> or a <that>.


	<this>*

means zero or more <this>s.


	<this>+

means at least one <this>.


	[ <this> ]

means at most one <this>.



 <mark>s

  A <mark> is one of the following characters:

	@		(at)
	!		(bang)
	|		(bar)
	{ }		(braces)
	=		(equals)
	[ ]		(brackets)
	:		(colon)
	,		(comma)
	->		(hyphen & rcaret)
	( )		(parentheses)
	.		(period)
	"		(quotation mark)
	;		(semicolon)


 <digit>s

  A <digit> is one of the following characters:

	1 2 3 4 5 6 7 8 9 0


 <letter>s

  <letter>s can occur in either of two forms, called <uppercase>
and <lowercase>.

  The <lowercase> forms of <letter>s are the following:

	a b c d e f g h i j k l m n o p q r s t u v w x y z

  The corresponding <uppercase> forms are the following:

	A B C D E F G H I J K L M N O P Q R S T U V W X Y Z


 <underscore>s

  An <underscore> is written "_".


 <ident-char>s

  An <ident-char> is either a <letter> or an <underscore>.


 <functor>s

  A <functor> is of the form

	<lowercase-letter> <ident-char>*

  Examples:

	x  aBC  x12_T3  y_z4_456


  No distinction is made between the <uppercase> and <lowercase>
forms of <letter>s that follow the initial <lowercase-letter> in
a <functor>.



 <keyword>s

  The <Language> Machine recognizes the following <keyword>s:

	$map $var $name $number $quote $asciicode $scancode $term
	$topic
	$para
	$rule
	$if
	$add $sub $mul $div $neg $lt $key
	$get
	$show $expand $nl
	$make
	$repeat $until
	$yes
	$zap
	$pause $no_pause
	$trace $no_trace 
	$non
	$end_para

	$warn_singleton_variables 
	$warn_dummyvars
	$no_warn_singleton_variables
	$no_warn_dummyvars

	/* this is a comment */


  No distinction is made between the <uppercase> and <lowercase>
forms of <letter>s in a <keyword>.



 <term>s

  A <term> is of one of the following forms:

	<variable>

	<dummyvar>

	<name>

	<number>

	<quote>

	<asciicode>

	<scancode>

	<list>


  <term>s represent persons, places, things, and events.


 <variable>s

  A <variable> is either a <reporter> or a <nonreporter>.


  A <reporter> is a <variable> of the form

	<uppercase-letter> <ident-char>*


  Examples:

	X  Abc  X12_t3  Y_z4_56


  A <nonreporter> is a <variable> of the form

	<underscore> <ident-char>+


  Examples:

	_X  _Abc  _x12_t3  _Y_z4_56


  No distinction is made between the <uppercase> and <lowercase>
forms of <letter>s that follow the initial <uppercase-letter> in
a <reporter> or the initial <underscore> in a <nonreporter>.


 <dummyvar>s

  A <dummyvar> is written "#".


 <name>s

  A <name> is of the form

	<functor> [ "(" [ <term> ( "," <term> )* ] ")" ]


  Examples:

	cucamunga  temp( basement, 19 )  sentence([see,spot,run])


 <number>s

  A <number> is of the form

	[ "-" ] <digit>+

  Examples:

	0123  00  -0  -234


  Any leading zeros in a <number> are removed by The <Language>
Machine.

  -0 and 0 mean the same thing.


 <quote>s

  A <quote> is any sequence of characters between successive
quotation marks neither of which is immediately preceded by a
backslash ("\").


  Example:

	"The men shouted \"Heave Ho!\" and walked out.\n"


   <quote>s may contain the following <special character>s:


	Representation     ASCII
	inside <quote>s    equivalent
	
	\\                 '\92'
	
	\"                 '\34'
	
	\t                 '\09'
	
	\n                 '\10'
	
	\r                 '\13'
	


  Example:

	<question>:

	$show({$quote}:"\n\t/\\/\\/\\/\\/\\\n\t0123456789\n").

	<answer>s:

		/\/\/\/\/\
		0123456789

	Yes.
	One <answer>.
	<search> completed.


 <asciicode>s

  An <asciicode> is of one of the following forms:


	"'" <ascii character> "'"


	"'" "\" <decimal ascii code> "'"


  Examples:


	'q'      '?'


	'\101'   '\10'



  <description>

  $topic@write_chars(*{$asciicode})
  $para @write_chars
  $rule @write_chars([]).
  $rule @write_chars([C|Cs])$if
    $show(C),
    @write_chars(Cs).
  $end_para

  <question>:

  @write_chars(['\176','\177','\178',
                '\174',
                '\72','\101','\108','\108','\111','\33',
                '\175',
                '\178','\177','\176','\10']).

  <answer>s:

  Hello!
  Yes.


 <scancode>

  A <scancode>s is of the following form:


	"^" <decimal ascii code> "^"

  <scancode>s are generated when certain keys and combinations of
keys on the keyboard are pressed. <scancode>s are distinct from
<asciicode>s.


  Examples:

	^113^     generated by Alt-F10

	^81^      generated by PageDn



 <list>s

  A <list> is of one of the two following forms:

	[] 

	[ <term> | <term> ]


  Examples:

	[a|[]]

	[a|[b|[]]]

	[a|[b|[c|[]]]]

	[a|[b|[c|L]]]


 "," notation in <list>s

  For any <term> t,

	[ t ] 

means the same thing as

	[ t | [] ]

and for any <term>s t1, ..., tm, m > 0,

	[ t | [ t1, ..., tm ]

means the same thing as

	[ t, t1, ..., tm ]


 Example:

	[a|[b|[c|[]]]]
is
	[a|[b|[c]]]
is
	[a|[b,c]]
is
	[a,b,c]


  Thus, we could say that a <list> is of the form

	"[" [ <term> ( "," <term> )* ] [ "|" <term> ] "]"



 <index>s

  Every <term> has an <index>.

  An <index> is of one of the following forms:

	<logo>

	<domainspec>

	"*" <index>


 <logo>s

  A <logo> is of the form

	"!" <functor>


 <domainspec>s


  A <domainspec> is of the form

	"{" [ <typespec> ( ";" <typespec> )* ] "}"


  <domainspec>s represent collections of <term>s.


 <typespec>s

  A <typespec> is of one of the following forms:

	<namespec>

	<numberspec>

	<quotespec>

	<asciicodespec>

	<scancodespec>

	$name
	$number
	$quote
	$asciicode
	$scancode
	$term


 <namespec>s
 
  A <namespec> is of the form

	<functor> [ "(" [ <index> ( "," <index> )* ] ")" ]


  An <namespec> instructs The <Language> Machine to accept only
an instance of the specified class of <name>s or a <variable>
where a <term> is called for.


  Examples:

	holton   temp( !zone, {$number} )  sentence(*!word)


  Note: every <namespec> in a <domainspec> must have a different
<functor>. For example, in the context
  
	$map !item -> { i({$name}) ; i({$number}) ; l(*!item) }

the second occurrence of the <functor> "i" will cause the error
message

	unique <functor> expected.

to appear.


 <numberspec>s

  A <numberspec> has the same form as the <number> that it
specifies.

  An <numberspec> instructs The <Language> Machine to accept only
an instance of the specified class of <number>s or a <variable>
where a <term> is called for.


 <quotespec>s
 
  A <quotespec> has the same form as the <quote> that it
specifies.


  An <quotespec> instructs The <Language> Machine to accept only
an instance of the specified class of <quote>s or a <variable>
where a <term> is called for.


 <asciicodespec>s
 
  An <asciicodespec> has the same form as the <asciicode> that it
specifies.

  An <asciicodespec> instructs The <Language> Machine to accept
only an instance of the specified class of <asciicode>s or a
<variable> where a <term> is called for.


 <scancodespec>s
 
  A <scancodespec> has the same form as the <scancode> that it
specifies.

  A <scancodespec> instructs The <Language> Machine to accept
only an instance of the specified class of <scancode>s or a
<variable> where a <term> is called for.


 $name

  $name instructs The <Language> Machine to accept only <name>s
or <variable>s where a <term> is called for.


 $number

  $number instructs The <Language> Machine to accept only
<number>s or <variable>s where a <term> is called for.


 $quote

  $quote instructs The <Language> Machine to accept only <quote>s
or <variable>s where a <term> is called for.


 $asciicode

  $asciicode instructs The <Language> Machine to accept only
<asciicode>s or <variable>s where a <term> is called for.


 $scancode

  $scancode instructs The <Language> Machine to accept only
<scancode>s or <variable>s where a <term> is called for.
                
 $term

  $term instructs The <Language> Machine to accept any <name>,
<number>, <quote>, <asciicode>, <scancode>, <list>, or <variable>
where a <term> is called for.


 * <index>

  An <index> of the form

	"*" <index>

represents the set consisting of all <list>s of zero or more
<term>s that have the specified <index>.

  For example, the <index>

	*{0;1}

represents the set

  [] 

  [0] [1] 

  [0,0] [0,1] [1,0] [1,1] 

  [0,0,0] [0,0,1] [0,1,0] ... [1,1,1]

  [0,0,0,0] [0,0,0,1] [0,0,1,0] ... [1,1,1,1]

  Etc.



 <description>s

  A <description> is of the form

	( <mapping> | <topic> | <paragraph> )*


 <mapping>s

  A <mapping> is of the form

	$map <logo> "->" <domainspec>


  Examples:

	$map !flavor -> { chocolate ; vanilla }

	$map !dcons -> { nil ; d({$term},!dlist) }

	$map !bits ->  *{0;1}

	$map !byte -> { byte(!bit,!bit,!bit,!bit) }

	$map !memory -> *!byte

	$map !tree -> { leaf({$name}) ; node(!tree,!tree) }


 <topic>s

  A <topic> is of the form

     $topic "@" <functor> "(" [ <index> ( "," <index> )* ] "}" 
                                              
	                                           [ "->" <quote> ]
  Examples:

	$topic @prefers({$name},!flavor)

	$topic @concat(!dcons,!dcons,!dcons)

	$topic @size(!memory,{$number})

	$topic @gather(!tree,*{$name})

	$topic @faculty(!department,*{$name}) -> "faculty.dat"


 <paragraph>s

  A <paragraph> is of the form

	$para <rule>* $end_para


 <rule>s

  A <rule> is of the form

	$rule <claim> [ $if [ <test> ( "," <test> )* ] ] "."


 <claim>s

  A <claim> is of the form

	"@" <functor> [ "(" [ <term> ( "," <term> )* ] ")" ]


  Examples:

	@hot

	@cold()

	@length([plums,grapes,apples],Q)

	@faculty(philosophy,[leibniz,spinoza,newton])


 <test>s

  A <test> is of one of the following forms:

	<claim>

	<numeric>

	<filter>

	<equalizer>

	<equality>

	<if_else>

	<repeat_until>

	<cond>

	<get>

	<expand>

	<show>

	$nl

	<make>

	$yes

	$zap

	$non <test>


 <numeric>s

  A <numeric> is a <test> that invokes one of the following
system-defined <topic>s:


  $add({$number},{$number},{$number})           modes:(i,i,o)

  $sub({$number},{$number},{$number})           modes:(i,i,o)

  $mul({$number},{$number},{$number})           modes:(i,i,o)

  $div({$number},{$number},{$number},{$number}) modes:(i,i,o,o)

  $neg({$number},{$number})                     modes:(i,o)

  $lt({$number},{$number})                      modes:(i,i)

  $key({$asciicode;$scancode})                  modes:(o)


  mode 'i' means the corresponding value must be provided by the
user.

  mode 'o' means the corresponding value may be provided by the
user or may be returned to the user by the system.


 $add

 
  $add "(" <summand_1> "," <summand_2> "," <sum> ")"

calculates the sum of its first two arguments and unifies the
result with its third argument.


  Example:

  $add(123456,7890,X)
  X->131346


 $sub


  $sub "(" <minuend> "," <subtrahend> "," <difference> ")"

calculates the difference beiween its first two arguments and,
if possible, unifies the result with its third argument.


  Example:

  $sub(123456,7890,X).
  X->115566


 $mul

  
  $mul "(" <multiplicand> "," <multiplier> "," <product> ")"

calculates the product of its first two arguments and, if
possible, unifies the result with its third argument.


  Example:

  $mul(123456,7890,X)
  X->974067840


 $div


  $div "(" <dividend> "," <divisor> "," 
                              <quotient> "," <remainder> ")"

calculates the ratio of its first argument to its second argument
and, if possible, unifies the quotient with its third argument
and the remainder with its fourth argument.


  Example:


  $div(123456,7890,Q,R)
  Q->15, R->5106


 $neg


  $neg "<" <number> "}"

reverses the sign of a <number>.


  Example:

  $neg(-99,X)
  X->99
  No.


 $lt


  $lt "(" <number> "," <number> ")"

succeeds if the value of its first argument is less than the
value of its second argument and fails otherwise.


  Example:

  $lt(3,2)
  No.


 $key


	$key "(" <term> "}"

waits for a key or combination of keys on the keyboard to be
pressed and, if possible, unifies its argument with the 8-bit
byte that is generated by the event.


  Example:

	$key(User)

	$key(^65^)


 <filter>s

  A <filter> is of one of the following forms:

	$var "(" <term> ")"

	$name "(" <term> ")"

	$number "(" <term> ")"

	$quote "(" <term> ")"

	$ascii "(" <term> ")"

	$scancode "(" <term> ")"

  <filter>s require that the <index>s of all <variable>s that
occur in the given <term> be known at compile-time.

  For example, given the <question>

	$name(a(Z)).

The <Language> Machine will reply

	<index> not known: Z


 <equalizer>

  The <equalizer> <test> is of the form

	<index> ":" <term> "=" <term>


  Example:

  <question>:

  *{$name}: [a,X,Y] = [a,Y,c].

  <answer>s:
  
  X->c, Y->c
  One <answer>.


  The <equalizer> 

	!a: T1 = T2

is logically equivalent to

	@a_unifier(T1,T2)

where

  $topic @a_unifier(!a,!a)
  $para @a_unifier
  $rule @a_unifier(X,X).
  $end_para



 <equality>

  The <equality> <test> is of the form

	<index> ":" <term> "=" "=" <term>


  Examples:

  <question>:

  *{$name}: [a,X,Y] == [a,Y,c].

  <answer>s:

  No.
7
  <question>:

  !a:X==Y.

  <answer>s:

  No.

  <question>:

  !a:X=Z,!a:Y=Z,!a:Z==Y.

  <answer>s:

  X->~V2, Y->~V2, Z->~V2
  One <answer>.


 <if_else>s

  An <if_else> is of the form

	"{" <basis> "->" <basis> ";" <basis> "}"


  Example:

  { $div(X,2,#,0) -> 
    $show({$quote}:"even\n")
    ;
    $show("quote:"not even\n") }


  Note:

  {->;} 

always succeeds.


 <repeat_until>s

  A <repeat_until> is of the form

	$repeat <cond> $until <cond>


  Example:

  <question>:

  $repeat
  ($key(X),
  $expand(X),
  $nl)
  $until
  ($non$asciicode(X)).

  <answer>s:

  {$asciicode;$scancode}:q
  {$asciicode;$scancode}:w
  {$asciicode;$scancode}:e
  {$asciicode;$scancode}:r
  {$asciicode;$scancode}:t
  {$asciicode;$scancode}:y
  {$asciicode;$scancode}:^65^  (i.e., user pressed F7 key)
  X->^65^
  One <answer>.


 <cond>s

  A <cond> is of the following form:

	"(" [ <basis> ( ";" <basis> )* ] ")"


  Example:

  ( $div(X,2,#,0) ; $div(X,5,#,0) )


  Note:

  () 

always succeeds.

  (;)

succeeds twice,

  (;;) 

succeeds three times, etc.


 <get>


	$get "(" <index> ":" <term> ")"

reads <asciicode> characters from the keyboard until it receives
a RET character (decimal 13) at which time it parses the
resulting string of characters as a <term> of the given <index>.


  Example:

  $no_pause,$get({a;$name;$term}:Z).
  {a;$name;$term}:a
  Z->a
  Z->a
  Z->a
  3 <answer>s.

  $no_pause,$get({a;$name;$term}:Z).
  {a;$name;$term}:olga
  Z->olga
  Z->olga
  2 <answer>s.

  $no_pause,$get({a;$name;$term}:Z).
  {a;$name;$term}:1984
  Z->1984
  One <answer>.


 <expand>


	$expand "(" <index> ":" <term> ")"

displays the given <term> in "painted" mode, i.e., each <term> is
prefixed by its <index>.


  Example:

  <description>:

  $map !fancy_apples -> *{$number}
  $map !red_apples -> *!green
  $map !green_apples -> *!red
  $map !red -> {$number}
  $map !green -> {$number}

  <question>:

  $expand(*{$number}:[1,2,3]),$nl,
  $expand(*!red:[1,2,3]),$nl,
  $expand(*!green:[1,2,3]),$nl,
  $expand(!fancy_apples:[1,2,3]),$nl,
  $expand(!red_apples:[1,2,3]),$nl,
  $expand(!green_apples:[1,2,3]),$nl.

  <answer>s:

  *{$number}:[{$number}:1,{$number}:2,{$number}:3]
  *!red:[!red:1,!red:2,!red:3]
  *!green:[!green:1,!green:2,!green:3]
  !fancy_apples:[{$number}:1,{$number}:2,{$number}:3]
  !red_apples:[!green:1,!green:2,!green:3]
  !green_apples:[!red:1,!red:2,!red:3]
  Yes.
  One <answer>.


 <show>


	$show "(" <index> ":" <term> ")"

displays the given <term> stripped of <index>s.

  Continuing the example above,

  <question>:

  $show(*{$number}:[1,2,3]),$nl,
  $show(*!red:[1,2,3]),$nl,
  $show(*!green:[1,2,3]),$nl,
  $show(!fancy_apples:[1,2,3]),$nl,
  $show(!red_apples:[1,2,3]),$nl,
  $show(!green_apples:[1,2,3]),$nl.

  <answer>s:

  [1,2,3]
  [1,2,3]
  [1,2,3]
  [1,2,3]
  [1,2,3]
  [1,2,3]
  Yes.
  One <answer>.


 $nl


  $nl 

starts a new line on the current output device.


 <make>s

  A <make> is of the form

	$make "(" <index> ":" <term> "," <claim> "," <list> ")"


  Example:

  <description>

  $map !type -> {0;1}
  $map !item -> {$name}

  $topic @data(!type,!item)

  $para @data
  $rule @data(0,apples).
  $rule @data(1,carrots).
  $rule @data(0,plums).
  $rule @data(1,celery).
  $rule @data(0,mangos).
  $rule @data(1,zucchini).
  $end_para

  $topic@test(!type,*!item)
  $para @test
  $rule @test(Type,Items) $if
          $make(Item,@data(Type,Item),Items).
  $end_para

  <question>:

  @test(0,_items),$expand(*!item:_items),$nl.

  <answer>s:

  *!item:[!item:apples,!item:plums,!item:mangos]
  Yes.
  One <answer>.


 <variable>s in $MAKE

  Using

	$make( <item-index>:<item> , <claim> , <target> )

to represent the general form of a $make, <variable>s can occur
in relation to <item> and <claim> in the following ways:

	                             Ŀ
	                              <variable> is   
	Ĵ 
	 <variable> occurs           global  local  
	Ĵ
	 only in <item>                G1      L1   
	Ĵ 
	 in both <item> and <claim>    G2      L2   
	Ĵ
	 only in <claim>               G3      L3   
	

  Here is an example:
                                                   
	Ŀ
	Ŀ                 
	Ŀ                             >
	                                      
	         v     v           v     v        
	$make( f(G1,L1,G2,L2) , @p(G2,L2,G3,L3) , T )
	                  ^           ^           
	                                        
	                             
	<

  In this example, L3 acts like a <dummyvar> (anything it matches
is simply discarded) but L1 will generate an error message: any
<variable> that occurs in <item> and is not global must also
occur in <claim>.

  The dotted arrow indicates that any <variable>s that occur in
<target> may be either global or local. However, no <variable>
that occurs in <target> may occur in either <item> or <claim>.

  The output of a $make command of the form

	$make( <item-index>:<item> , <claim> , <target> )

is a <list> with <index>

	*<item-index>

consisting of <item>s constructed by combining any (constant)
global inputs to the $make with successive outputs from
successful instances of <claim>, which <list> is then unified
with <target>.


 $yes


	$yes

always succeeds.


 $zap


	$zap

always fails.


 $non


	$non <test>

reverses the sense of <test>:

   $non <test> succeeds if <test> fails;

   $non <test> fails if <test> succeeds.



 <question>s

  A <question> is of the form

	[ $if [ <test> ( "," <test> )* ] ] "."


 <answer>s

  An <answer> is of one of the following forms:

	<variable> "->" <term>

	Yes.

	No.

  The <answer> "No." means that the given <description> does not
supply any <answer>s to the given <question>.



 The "Colors" Model

  To The <Language> Machine, <domainspec>s represent input ports
and <logo>s represent distinctive "colors".

  The input port represented by a <domainspec> allows only
<term>s of the form given by that <domainspec> to pass through
it.

  The <mapping> of a <logo> to a <domainspec> directs The
<Language> Machine to read from the input port represented by
that <domainspec> whenever a <term> with that <logo> is required,
and to "paint" that <term> as it is being read in, using the
distinctive color associated with that particular <logo>.

  The <Language> Machine also has these three "public" input
ports: 

	$name  $number  $quote

  <term>s that enter The <Language> Machine through any of these
public input ports are not painted, but are merely stamped with
the name of the port through which they came.

  Thus, <term>s that come in through public input ports can
easily be distinguished from painted <term>s; <term>s that come
in through different public input ports can easily be
distinguished from one another; and <term>s that are painted
different colors can easily be distinguished from one another.

  For example, given

	$map !red_box -> *{$number}
	$map !green_box -> *!green
	$map !green -> {$number}

the text

	[1,2,3]

would look like this after having been read into The <Language>
Machine through the !red_box port:

	!red_box:[{$number}:2, {$number}:7, {$number}:0]

while the same text would look like this after having been read
in through the !green_box port:

	!green_box:[!green:2, !green:7, !green:0]

  We see immediately that, not only are the two <list>s  painted
different colors, the !red_box <list> contains unpainted numbers
that came in through the public $number port, while the
!green_box <list> contains painted numbers that came in through
the !green input port.

  Therefore, if The "Colors" Model correctly predicts the
behaviour of The <Language> Machine, we should expect (1) that
The <Language> Machine will reject the proposition that these two
<list>s are the same and (2) the proposition that they contain
identical sets of numbers.
  
  As to the first proposition, the only way it is possible to
express the idea that two things are the same in <Language> is by
using the same <variable> to mention both things in the same
sentence, like this:

	$topic @same(!red_box,!green_box)
	$para @same
	$rule @same(X,X).
	$end_para

However, when we give this text to The <Language> Machine, it
says this:

	!green_box:X conflicts with !red_box:X

  Much the same thing happens with respect to the second
proposition. If we try this:

	$topic @equate(!red_box,!green_box)
	$para @equate
	$rule @equate([],[]).
	$rule @equate([X|Ns],[X|Gs]) $if @equate(Ns,Gs).
	$end_para

The <Language> Machine says this:

	!green:X conflicts with $number:X

  For this interpretation to work, of course, we need to show
that it will never lead us to believe something which is not
true, nor to disbelieve something which is true.

  This is easier said than done.

  For starters, we must show that:

  1. The <Language> Machine cannot fail to paint a <term> that
should be painted.

  2. The <Language> Machine cannot paint a <term> the wrong
color.

  3. The <Language> Machine cannot paint a <term> that should not
be painted.

  4. The <Language> Machine cannot fail to distinguish <term>s
that are painted different colors, nor fail to distinguish a
painted <term> from an unpainted <term>, nor fail to distinguish
between <term>s that come in through different public input
ports.

  All I am prepared to say at this time is that if this version
of The <Language> Machine Prototype fails to meet these
requirements, or fails in any other way to satisfy The "Colors"
Model, I would appreciate hearing about it.

wdbh (c) 07dec03 [last revised 09dec03]


 Why <mapping>s are important

  <mapping>s allow us to formalize the conceptual framework in
terms of which we are thinking about the situation that we are
describing, in such a way that it becomes an operative part of
that description.

  This formalization of the conceptual framework that we are
(more or less consciously) using is in the nature of a promise
that the description which we are about to write will abide by
certain clear and consistent standards of usage; making this
agreement an operative part of the description itself makes it
possible for The <Language> Machine to effectively catch all
usages which violate that agreement.
  
  This in turn affects the writing process (quite dramatically)
in at least these three ways:

  First, because it prevents unintentional statements from
creeping into the description in the first place, it saves us the
time and trouble of tracking down and sorting out the mischief
they would otherwise be certain cause.

  Second, because unintentional statements tend to blur the
picture we are trying to develop, and the effect of eliminating
them from the picture has the opposite effect, eliminating the
unintentional statements makes it easier for us to find the
mistakes that matter most: intentional statements that suffer the
defect of being "the correct expression of a mistaken
understanding" [R.E.Davis].

  Third, because it is the rate at which we can find mistakes
that ultimately limits the rate at which we can correct them,
making it easier to find the mistakes that matter favors the
development of the very thing we are depending on to solve the
problem that we are engaged in describing: our ability to learn.

  The <Language> Machine is thus the very definition of a
learning environment: a safe place to experiment and to grow.

wdbh (c) 07dec03 [revised 24dec03, 08jun05]


 Who hates whom?

  Aligning the <index>s and <variable>s in <topic>s and <claim>s
helps prevent a common kind of mistake that, once made, can be
very difficult to pin down: writing <variable>s in the wrong
order.

  Example:

	$map !cat -> {$name}
	$map !dog -> {$name}
	
	$topic @loves(!dog,!cat)
	 $para @loves
	 $rule @loves(fido,felix).
	 $rule @loves(rufus,kitty).
	 $end_para

	$topic @hates(!cat,!dog)
	 $para @hates
	 $rule @hates(Cat,Dog) $if @loves(Cat,Dog).
	 $end_para

  Given this <description>, The <Language> Machine responds as
follows:

	Parsing...
	!dog:Cat conflicts with precedent: !cat:Cat

  Here, the use of <logo>s here to distinguish between cats and
dogs allowed The <Language> Machine to catch the substantive
error in the given <description>, but suppose the <description>
had been couched in generic terms:

	$topic @loves({$name},{$name})
	 $para @loves
	 $rule @loves(felix,fido).
	 $rule @loves(kitty,rufus).
	 $end_para

	$topic @hates({$name},{$name})
	 $para @hates
	 $rule @hates(Cat,Dog) $if @loves(Dog,Cat).
	 $end_para

  Now, as far as The <Language> Machine can tell, there is
nothing wrong with this <description> so, to the <question>

	@hates(Who,Whom)

The <Language> Machine responds with

	Who->fido, Whom->felix
	Who->rufus, Whom->kitty
	2 <answer>s

and because these <answer>s are plausible, only someone
well-acquainted with Fido and Felix or Rufus and Kitty
would be likely to question them.

  Nevertheless, it is sometimes argued that the way around this
type of confusion is by providing additional information about
the individuals involved and inserting appropriate caveats:

	$topic @dog({$name})
	 $para @dog
	 $rule @dog(fido).
	 $rule @dog(rufus).
	$end_para

	$topic @cat({$name})
	 $para @cat
	 $rule @cat(felix).
	 $rule @cat(kitty).
	$end_para

	$topic @loves({$name},{$name})
	 $para @loves
	 $rule @loves(felix,fido).
	 $rule @loves(kitty,rufus).
	 $end_para

	$topic @hates({$name},{$name})
	 $para @hates
	 $rule @hates(Cat,Dog) $if 
	   @dog(Dog),
	   @cat(Cat), 
	   @loves(Dog,Cat).
	 $end_para

  Now, in response to the <question>

	@hates(Who,Whom)

The <Language> Machine simply says

	No.

which is technically correct, but again, because it doesn't give
any clues as to the existence of the substantive error in the
original <description>, only someone well-acquainted with Fido or
Felix or Rufus or Kitty would be likely to question it.

  The fact of he matter is that, by requiring new information to
be added to the given <description>, this approach merely
increases the opportunities for making the very kind of mistakes
it is supposed to prevent. Furthermore, its use leaves the reader
with no choice but to *assume* that all of the the necessary
caveats have been unfailingly and correctly inserted in all of
the right places, an assumption that most reasonable people would
prefer not to be required to make, especially since the problem
that gives rise to the apparent necessity of making it is so
simple to fix.

  In the present case, when the error that The <Language> Machine
detected in the original <description> is corrected, we get

	$map !cat -> {$name}
	$map !dog -> {$name}
	
	$topic @loves(!dog,!cat)
	 $para @loves
	 $rule @loves(fido,felix).
	 $rule @loves(rufus,kitty).
	 $end_para

	$topic @hates(!cat,!dog)
	 $para @hates
	 $rule @hates(Cat,Dog) $if @loves(Dog,Cat).
	 $end_para

and to the <question>

	@hates(Who,Whom)

The <Language> Machine now responds with

	Who->felix, Whom->fido
	Who->kitty, Whom->rufus
	2 <answer>s

-- a very different tale, indeed.

wdbh (c) 26june05



 <warning>s

  A <warning> is of one of the following forms:
  
	$warn_singleton_variables

	$no_warn_singleton_variables

	$warn_dummyvars

	$no_warn_dummyvars

  <warning>s tell The <Language> Machine how to treat with
certain situations that may (but do not necessarily) indicate an
error.

  If a <warning> is enabled (which it is by default) and The
<Language> Machine encounters an instance of the corresponding
situation, you will be asked to resolve the issue: 

   press F10 if you want to skip it,

   press ESC if you want to fix it.


 Making a transcript

  At any point where The <Language> Machine is expecting input,
pressing Alt-P will cause the following menu to appear:

	
	Printer Off
	LOG fileOn
	

  If you toggle "LOG file" to "On", any subsequent output that
The <Language> Machine displays on the screen will also be
written out to a disk file named "PROLOG.LOG"; this will continue
to be the case until you toggle "LOG file" back to "Off".

  Similarly, if you toggle "Printer" to "On", any subsequent
output that The <Language> Machine displays on the screen will
also be immediately sent to the printer which it is assumed you
have connected to your computer.



 The technology represented by The <Language> Machine

  On some level, every system that is organized according to the
technology represented by The <Language> Machine looks like this:


    ͻ
     @system(How,go(from(A),to(B)))? 
    ͼ
                     
                     v
             ͻ         
                  The          ͻ 
               <Language>  <͹ <description>          
                 Machine       ͼ         
             ͼ                              
                                                        
                     v                                
      ͻ     
       A ->... How ->... B ->...       
      ͼ     
                                        
        Ŀ       
                    v                  
                 ͻ               
                  How                
                 ͼ               
                                                                         
        v            v           v                                         
      ͻ    ͻ    ͻ                                             
       A >  System  > B                                         
      ͼ    ͼ    ͼ                                       
                     ^                                                      
                                                          
                                                                            

                  Legend
        
         ͻ output/input ͻ 
             >     
         ͼ              ͼ 
         ͻ  describes   ͻ  
             >     
         ͼ              ͼ 
        
                                   

  The following analogy may be helpful in reading this diagram.

  You are trying to figure out how to make your computer do
something or other: your computer is "System", what you want your
computer to do is <go(from(A),to(B))>, what you need to know is
"How", your collection of reference manuals is <description>, you
are The <Language> Machine, and what you are doing is called
"computer programming".


 <Language>

  <Language> is about leverage.

                                               
                                               
                                                questions 
   language skills                            about 
                                               the system 
                                              
  V                                            
  
                                           /^\
                                           < "the computer"


  When we use <Language> to describe a system, "the computer"
becomes the fulcrum we use to bring our language skills directly
to bear on the problem of getting timely and reliable answers to
the two basic questions that have to be asked and answered about
any system:

	What is this system supposed to be able to do?

	How am I supposed to be able to make this system do that?

  The system in question can be anything that can be described in
<Language>: a subway, an organization, an insurance policy, a
computer -- in fact, anything it makes sense to call "a system".


 The hard way


          +  ͻ           ͻ  +
        > Doubts             Beliefs <Ŀ
                           
                                              
                    ͻ             
                >  Actions  <           
                     ͼ              
                                               
                           v                    
          Negative  Affirmative 
        Ķ  Experience  
                    
                            ^
                            
                       ͻ
                        Context 
                       ͼ


 Common ground between industry and labor

  To the extent that our private and public environments of
employment become organized in accordance with the technology
represented by The <Language> Machine, and to the extent that our
schools prepare students to function in that environment,
employers will have an objective basis for knowing that job
applicants are prepared to make a contribution to "the bottom
line" because the correspondence between employee skills and
employer requirements will be built into the system.


 No better investment

  According to the 1991 World Almanac, 40,192,386 students
enrolled for the 1988-89 school year in the U.S., and 2,316,428
classroom teachers greeted them on the first day.

  That's about 17.4 students per teacher.

  Today [c.1994], a computing system (hardware and software)
powerful enough to support the technology represented by The
<Language> Machine and to support any reasonable demands that
17.4 students and a teacher could put upon that computing system
in the process of learning how to apply that technology costs
less than $1000.

  Thus, even discounting the sizable hardware base that already
exists in our schools, it looks to me like an investment of less
than $2.32 billion would be more than enough to give every
student and every teacher in every elementary and secondary
school in the U.S. ample opportunity to learn these objectively
fundamental language skills.

  I can't think of a better investment.


 The smart way


         +  ͻ           ͻ  +
      > Doubts             Beliefs <Ŀ
                            
                                               
               v                     v            
          ͻ         ͻ    
           Specify             Specify       
       >  & Revise            & Revise <Ŀ 
         ͼ         ͼ   
                                             
              v                     v           
         ͻ        ͻ   
          Question          Description    
         ͼ        ͼ   
                  ͻ             
                      The                  
              > <Language> <ͼ          
                     Machine                 
                   ͼ              
                                              
                          v                    
                    ͻ              
                      Answers                
                    ͼ              
                                              
                          v                    
          Reject       Reject      
       Ķ Evaluate  
                                     
                            Accept              
                           v                     
                     ͻ               
                       Actions                 
                     ͼ               
                                                
                           v                     
          Negative  Affirmative  
      Ķ  Experience  
                    
                            ^
                            
                       ͻ
                        Context 
                       ͼ



 Science

"Organic biological activities end in overt actions, whose
consequences are irretrievable. When an activity and its
consequences can be rehearsed by representation in symbolic
terms, there is no such final commitment. If the representation
of the final consequence is of unwelcome quality, overt action
may be foregone, or the way of acting be replanned in such a way
as to avoid the undesired outcome." - John Dewey, Logic, 1938


 "Prolog"

  In 1951, Alfred Horn, a mathematician, published a paper
entitled "On Sentences which are True of Direct Unions of
Algebras" in the Journal of Symbolic Logic.

  The sentences to which the title of Horn's paper refers look
like this:

	P if Q1 & Q2 & ... & Qn.

where P and the Qs are simple (non-negated) sentences --
<claim>s, in <Language> terminology -- and the ampersands between
the Qs mean "and" without any regard to the order in which the Qs
happen to have been written.

  In 1951, computers were extremely expensive, few in number, and
very hard to use, but people were so happy to be able to compute
anything at all that they were willing to put up with having to
specify those computations by means of computing formalisms that
were unintelligible to anyone not familiar with the detailed
operations of the particular computer being used.

  With rapid advances in technology, computers decreased in cost,
increased in power, and became much more readily available; more
and more people wanted to use computers to solve substantive
problems that were unrelated to computers per se, and these
people were understandably dissatisfied with being required to
take their minds off the problems they were trying to solve just
to figure out how to make the computer do whatever it was
supposed to do!

  The 1960s saw the rise of software packages that were able to
anticipate certain computing needs, but unanticipated computing
needs spring from the nature of things; it was gradually
recognized that the real challenge was to discover a satisfactory
computing language, which is to say, a language that was also a
computing formalism.

  By 1970, some researchers were looking at the Horn Clauses as a
potentially universal computing language and, in 1974, Robert
Hill proved that Horn Clauses were computationally complete,
which means that anything that can be computed by (say) a Turing
Machine can be computed using nothing more than Horn Clauses.

  Hill's result strikes me as mysterious when I reflect on the
fact that most sentences -- for example, the class of all
sentences of the form

	P1 ; P2 ; ... ; Pm if Q1 & Q2 & ... & Qn.

where m>1 and the semicolons mean "or" -- are not Horn Clauses at
all.

  I also think it is interesting that the framers of the
definition of the language to which the sentences that captured
Horn's interest all belong appear not to have singled out that
set of sentences in any particularly special way, either.

		-----*-----
 
  The upshot of all this was a computing formalism dubbed
"Prolog" (PROgramming in LOGic) which, certainly by 1984, when I
came across it, had become available at every major university
computing center in the world.



 References

  The technology represented by The <Language> Machine is all
about responsible predication, a concept for which I am indebted
to WORKING OUT IDEAS: PREDICATION AND OTHER USES OF LANGUAGE, by
Josephine Miles [Bay Area Writing Project Curriculum Publication
No. 5, 1979].

  BAWP's address is:

	School of Education Business Office
	Publications Department
	1615 Tolman Hall
	University of California
	Berkeley, CA 94720

		-----*-----

  I am also indebted to the article "Runnable Specification as a
Design Tool", by Professor Ruth E. Davis, included in the
collection LOGIC PROGRAMMING, edited by K.L.Clark and S.-A.
Trnlund [Academic Press, 1982].

  I wouldn't attempt to paraphrase Professor Davis, so I will
simply recite the impression it left in my memory: the main
advantage of using an executable design specification language is
that doing so makes it possible for all parties to the given
design to answer any question pertaining to what the design
specifications actually say, without having to hire an
intermediary "expert" who presumably knows how (and can be
trusted) to "translate" question A into "input" A' such that,
when the same "expert" (or someone similar) translates "output"
B' into statement B, statement B is in fact the answer to
question A.

		-----*-----

  While I'm on this subject, I would like to recommend the
article "Verifying the Design Process", by Michael E. Stanley [AI
Expert, September 1992].

  Mr. Stanley was at the time he wrote this article an engineer
working for Motorola, Inc., on the production of
application-specific VLSI circuits.

  VLSI circuits are very complicated.

  Application-specific circuits involve risking a relatively much
greater investment in new design than non-application-specific
circuits.

  With application-specific VLSI circuits, therefore, it is
extremely important to make sure that a given set of design
specifications is correct before it is put into production, which
means that someone has to certify the given set of specifications
as being "manufacturable".

  This certification process is called "releasing the design".

  What is pertinent here is that, by electing to use Prolog as
the executable design specification language in which he states
the policy that stipulates the conditions under which a given set
of design specifications may be released, Stanley shows that the
advantages of using an executable design specification language
extend even to the production of design specifications!

		-----*-----

  For an epic view, I recommend the book STAR WARS, by Richard
Ennals, one of the pioneer advocates of "logic across the
curriculum" [Wiley, 1986].

  According to Ennals, research concerned with the use of logic
programming in education was first proposed in November 1979, by
Professor Robert Kowalski of Imperial College.

  The first systematic classroom test of Kowalski's proposal took
place in 1980-1983; it was conducted in an elementary school
connected with Imperial College and was called the "Logic as a
Computing Language for Children Project".

  For a participant's account of that project (with examples of
curriculum material), see Ennals' BEGINNING MICRO-PROLOG [Harper
& Row, 1984].

		-----*-----

  For a scientific assessment of the educational value of Prolog,
you might consult the work of Elizabeth Abbot and Dr. Geoff
Cumming of the Department of Psychology at La Trobe University.

  In one of their rigorously-designed and carefully-conducted
classroom experiments, involving students in grades 5 and 6, Ms.
Abbot and Dr. Cumming looked for evidence that this technology
might favor either male students or female students and found
this:

  "The conclusion must be that there was no clear overall sex
difference in [acquired] Prolog ability, with any slight
advantage going to the girls."

["Prolog and Social Aspects of Educational Computing", in Proc.
Fourth Australian Computer Education Conf., Melbourne (1986), pp.
238-244]

		-----*-----

  PEG is an informal alliance of people who share diverse views
about the educational value of language-based programming in its
broadest sense.

  PEG is an information and software exchange, a lobbying group,
organizes seminars and conferences, and publishes PEGBOARD twice
yearly.

  PEG's address is:

	PEG
	School of Education
	University of Exeter
	Heavitree Road
	Exeter, EX1 2LU, UNITED KINGDOM

  [I have not heard from these folks in a long while, so I am not
sure PEG is still in business. (28Jan95)].


 Acknowledgments

  I am indebted to the author(s) of Appendix K of the Turbo
Prolog Reference Guide and the programs PARSER and PIE described
therein.

  Turbo Prolog is a trademark of Borland International.

  The <Language> Machine Prototype is written in PDC Prolog 3.21
and uses the following tools from the PDC Prolog 3.20 Toolbox:

	tdoms.pro
	tpreds.pro

	ui\\filenam6.pro [same as filename.pro except calls dir/6]
	ui\\longmenu.pro
	ui\\menu.pro
	ui\\pulldown.pro
	ui\\status.pro

  Also, editing in The <Language> Machine Prototype is
accomplished by calling the standard PDC Prolog 3.21 system
predicate edit/20.

  PDC Prolog is a trademark of Prolog Development Center.


 How it all fits together

  The following diagram shows how PDC Prolog figured into the
development of The <Language> Machine Prototype.


           ͻ         ͻ     
      > Specify             Specify   <Ŀ
            & Revise            & Revise     
                        
                                               
                                     v          
                v              ͻ   
        ͻ          The        
         <description>s       <Language>     
               &                Machine      
           <question>s         Prototype     
        ͼ     ͼ   
                   ͻ             
                     PDC Prolog              
                      Compiler  <ͼ          
                   ͼ              
                                               
                          v                     
                    ͻ               
                >  TLM.EXE                 
                     ͼ               
                                                
                           v                     
                     ͻ               
                      <answer>s                
                     ͼ               
                                                
                           v                     
            Reject      Reject       
      ĺ Evaluate 
                      ͼ 
                             Accept
                            v 
                      ͻ
                       Publicize 
                      ͼ


  I hope the next diagram shows how The <Language> Machine will
figure into what you are doing.

                               
            ͻ       ͻ 
             Specify           Specify   
        >  & Revise          & Revise <Ŀ
                     
                                             
                 v                   v         
         ͻ    ͻ 
          <question>s      <description>s  
         ͼ    ͼ 
                    ͻ            
                 >  TLM.EXE  <ͼ         
                     ͼ             
                                              
                           v                   
                     ͻ             
                      <answer>s              
                     ͼ             
                                              
                           v                   
           Reject       Reject     
        ĺ Evaluate 
                      ͼ 
                             Accept
                            v
                       ͻ
                        Teach? 
                       ͼ

 Correspondence

Bill Hogan <logic4sure@yahoo.com>

  Copyright 1994-2005


