Writing Extensions

[Mark Waddingham]

On 2017-05-17 21:27, Mark Wieder via use-livecode wrote:
> Well, I'd love to have more parity between LCS and LCB as far as
> keywords and syntax, but I guess that's outside the scope of the
> documentation per se. But finding that constants like comma and quote
> aren't defined in LCB was a shock. Indeed, even defining a constant
> doesn't seem possible. Or at least it's not documented. Searching for
> "constant" gives nothing, even though "PiConstant" is in the
> dictionary.

You can define constants using:

    constant X is Y

Currently Y has to be a literal - not an expression (just like LCS).

> 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.

> The pointer type isn't documented.

Well it is listed in the language reference ;)

> Why is the "point" operator documented as "PointMake"? Is this just to
> differentiate between the "point" creator keyword and the "point"
> object keyword?

Each piece of syntax in LCB has a unique name (it is a definition, like
a handler or a variable) - those title-case names you see are the names
of the syntax definitions.

The point operator is a constructor for the (Canvas.)Point type.

> Some major strengths of LCS are missing in LCB, or at least don't
> appear to be in the documentation. Chunks, for instance. It's possible
> to get character chunks (and the [first|last] modifier in the offset
> functions are *very* nice), but there's no conception of words. This
> results in some ugly, convoluted, and error-prone coding to deal with
> things that are not only easy in LCS, but IMNSHO one of the things
> that makes LiveCode such a productive environment. I'm hoping this is
> just a documentation failure and not a missing feature.

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.

> The StringToJString and StringFromJString examples handler use the
> "foreign handler" construct, but "foreign" isn't in the dictionary.
> Nor is the "binds to" syntax. Nor the JObject or JString objects. Nor
> the "unsafe" keyword.

The dictionary doesn't currently contain anything which is 'part of the
core language syntax' - more details about that can be found in the
Guides section of the dictionary - there are a few guides related to LCB
at the bottom.

So, as Ali said, we have a fair bit of work to do on the documentation, 
but
then that's also true of the language itself.

LCB is definitely a work-in-progress but one which is actually quite
usable now for a wide variety of things... Once you've got your head 
around
how to use it!

Warmest Regards,

Mark

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps