Writing Extensions

[Mark Wieder]

On 05/18/2017 12:45 AM, Mark Waddingham via use-livecode wrote:

> You can define constants using:
>
>    constant X is Y
>
> Currently Y has to be a literal - not an expression (just like LCS).

Didn't find it in the dictionary, but I do see that now in the language 
reference. How would one define a quote constant?
constant quote is "\q"  ?

The language guide explicitly states "Note: Constants are not currently 
implemented, although the syntax is recognised." What am I supposed to 
make of that?

>> Is it even possible to set the various delimiters? The documentation
>> only talks about retrieving them. The description talks about the
>> calling (script) handler's <type>Delimiter property... is this an
>> actual property of the object or is just a shorthand way of talking
>> about "the <type>Delimiter"?
>
> No - the context local properties are a LiveCode Script feature, they
> don't exist in LCB.
>
> The 'the <type>Delimiter' syntax gives you access to the values of those
> properties in the most recent LCS stack frame allowing LCB to do similar
> things as the engine can in its commands and functions.

That's unfortunate. In LCS I often change the itemdelimiter in order to 
parse complex strings. The lack of the ability to manipulate things at 
this level is a serious detriment to text parsing, which is one of the 
main strengths of LCS.

>
>> The pointer type isn't documented.
>
> Well it is listed in the language reference ;)

Ah. So the dictionary isn't a good place to look for things. I'll spend 
some time working my way through the language reference instead.


> LCB's syntax is quite minimal at the moment, it isn't meant to be a
> replacement for LCS (as mentioned before) - it is intended as a language
> which makes explicit the implicit patterns and abstractions which exist
> (albeit hand-coded in most cases) in the engine, so that they can be used
> to build the abstractions which we use everyday in LCS - and extend them
> in a natural way.
>
> For example, line and item chunks are actually an incarnation of what
> you might call a 'delimited chunk' - they have identical semantics, apart
> from where the delimiter to use is fetched from (the *delimiter property
> in local context).
>
> Similarly, word and token are 'tokenized chunks' - they action could be
> described by a regular expression.

See above (itemdelimiter).

-- 
  Mark Wieder
  ahsoftware at gmail.com