Dead Conversational Language (DeadCL)

The foundation of DeadLetter is DeadCL or Conversational Language. It consists of four interoperating components, an Authoriser, (Author Key) Object interpretation, (library) Object information (Arrays) and a Key file (Conversation) together they make up a DeadLetter program.

To gain a basic understanding of CL, you'll need to familiarise yourself with it's basic process, of receiving, executing and outputting, object based information; before familiarising yourself with the syntax used.

CL - Inputs

All inputs are defined within Conversations. DeadLetter is only capable of receiving information in plain text files, without encoding or foreign syntax.

Input sources should employ Secure Sockets Layer although this is not a prerequisite.

All inputs must use the syntax *input,

Your input source must be accessible without, obstruction.

            

      
*input, 
	@INPUT-ADDRESS

CL - Output

Output address(es) should only ever be defined within your Author Key. This improves redundancy, simplifies sharing and administration.

Output should be defined using the syntax ?DRP -- [email protected]+Cnvrstn$

This instructs DeadLetter to use the address;

https://post.deadletter.io/Do-ID+CONVERSATION_URL

for it's output(s) providing a unique address for each Conversation automatically upon publication of each Conversation named within the Author Key.

            

      
?DRP -- [email protected]+Cnvrstn$

CL - 'Meanings' Based Syntax'

Perhaps the most useful benefit of MBS is how you're able to integrate the nature meaning of a word directly with deadCL. You can of-course add its meaning using a KC if you're worried about deadCL understanding the request.

In this example we've used the word 'WATCH' to detect a change of state in an object. This is called Meanings Based Syntax (MBS), within deadCL.


      
ACTION; 
	?WATCH, _ALL -- INPUT

CL - Connections

Connections, are object links, secondary object resources (SOR) used to assist in correct interpretation of an abstract object.

In this example, we've used a door (in the real world) one SOR is of the actual door the other is just a door.


      
door; 
	{a doorway}
	actual, @RESOURCE_deadID 
	sample, @RESOURCE_deadID

CL - Importance

How you structure your CL files is important. As CL runs the commands in the order you've written them.

For example first your Author Key will be checked, then remote libraries are loaded, followed by a single local library.