Difference between revisions of "LSL Protocol/ListMessage"

From Second Life Wiki
Jump to navigation Jump to search
(suggest a way of encoding lists, non-lists, non-results, verb-not-found, and partially evaluated Polish expressions)
 
m (clarify - type out many more of the missing words)
Line 11: Line 11:
We then work with results of any non-list type, also results of list type, also parameter lists that include lists as entries, also the results of verbs that return no results, also the result that is failing to make sense of an unintelligible unknown verb.
We then work with results of any non-list type, also results of list type, also parameter lists that include lists as entries, also the results of verbs that return no results, also the result that is failing to make sense of an unintelligible unknown verb.


I guess we want [[llMessageLinked]] to pass such things to [[link_message]], so that we can divide the work of interpretation across indefinitely many scripts.
I guess we want [[llMessageLinked]] to pass such interpreter things to [[link_message]], so that we can divide the work of interpretation across indefinitely many scripts.


I guess we want to invent some way of escaping such things: (a) some perfectly reversible way to encode such things as a list we can pass around a script, and (b) some perfectly reversible way of encoding a list as a string.
I guess we want to invent some way of escaping interpreter things, in three parts:
 
i) some way of losslessly encoding any string as a string without troublesome punctuation that makes the one string look like more strings, and
 
ii) some way of losslessly encoding any list as a string, and
 
iii) some way of losslessly encoding interpreter things as a list.
 
Answers for that dream include:
 
i) A scheme for losslessly encoding any string as a string that begins with "\"" and contains no troublesome punctuation may be "\"" + [[llEscapeURL]](string) + "\"".
 
ii) A scheme for losslessly encoding any list as a string may be to encode its strings and then [[llDumpList2String]] with a ", " separator.
 
iii) A scheme for losslessly encoding interpreter things (without source comments) as a list may be:


<pre>
<pre>
Line 21: Line 35:


[ 0... ] = float or integer result
[ 0... ] = float or integer result
[ "\"...\"" ] = key or string result, may be empty = encoded simply as "\"" + ([[lEscapeURL]](string) + "\""
[ "\"...\"" ] = key or string result, may be empty
[ "<...>" ] = rot or vector
[ "<...>" ] = rot or vector



Revision as of 21:59, 10 October 2007

Back to Protocol page

List Message Protocol

(Proposed) (Draft, not implemented) (Open for comments)

When we solve problems like interpreting an LSL expression a la Chatbot, ...

We then work with results of any non-list type, also results of list type, also parameter lists that include lists as entries, also the results of verbs that return no results, also the result that is failing to make sense of an unintelligible unknown verb.

I guess we want llMessageLinked to pass such interpreter things to link_message, so that we can divide the work of interpretation across indefinitely many scripts.

I guess we want to invent some way of escaping interpreter things, in three parts:

i) some way of losslessly encoding any string as a string without troublesome punctuation that makes the one string look like more strings, and

ii) some way of losslessly encoding any list as a string, and

iii) some way of losslessly encoding interpreter things as a list.

Answers for that dream include:

i) A scheme for losslessly encoding any string as a string that begins with "\"" and contains no troublesome punctuation may be "\"" + llEscapeURL(string) + "\"".

ii) A scheme for losslessly encoding any list as a string may be to encode its strings and then llDumpList2String with a ", " separator.

iii) A scheme for losslessly encoding interpreter things (without source comments) as a list may be:

[] = unknown verb

[ "<>" ] = the result of a verb that returns no result

[ 0... ] = float or integer result
[ "\"...\"" ] = key or string result, may be empty
[ "<...>" ] = rot or vector

[ "[", ..., "]" ] = list, may be empty

[ "(", ..., ")" ] = partially evaluated Polish expression = list of verb with zero or more args, may be nested in the sense of args may be lists