Learning DeadCL DeadCL Tutorials DeadCL Syntax DeadCL MBS

Walk throughs

Author Keys Conversations Libraries Arrays

  Network Status Community Hub Contact Us



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 JSON or XML or plain text 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,


            

*input, PARCEL- A LR5p6

CL - Output

Output address(es) should only ever be defined within your Author Key, Library or Conversation.

Here we're informing DeadCL where & how post your Conversation output to;

API.PURPLE.COM/user

As JSON using Parcel Arnold with the payload {PARAMETERS}

If you're having trouble understanding how Parcel posting works best to learn more about Parcel posting or lookup the syntax.


           

POST; PARCEL- A PARAMETERS -- API.PURPLE.COM/user

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.



dld.keyset('AUTHOR-KEY-deadID') *Catch-all - libs *Catch-lib -L @COOKIE_ACTIONS