Writing Extensions

[Ali Lloyd]

Thanks Mark, those comments on the docs are really helpful! I've filed bugs
for the core language features, the fixed width font in the extension
builder, script object docs and misleading CamelCase naming.

On Thu, May 18, 2017 at 8:59 AM Mark Waddingham via use-livecode <
use-livecode at lists.runrev.com> wrote:

> On 2017-05-17 23:43, Mark Wieder via use-livecode wrote:
> > Yes. In fact it's the areas where they differ that make for a
> > difficult learning curve. There are features in LCB that I wish were
> > backported to LCS. I appreciate the team's reticence to make syntax
> > changes to the core xtalk language, but even as a long-time C
> > programmer,
> >
> > put tHexNumber converted from base 16 into tDecimalNumber
> >
> > seems so much more readable than
> >
> > put format("%02x", tHexNumber) into tDecimalNumber
>
> I wouldn't say we have a 'reticence' to make syntax changes but it
> requires
> a great deal more care than in LCB for several reasons:
>
>     - The current implementation of LCS has no notion of versioning for
> its
>       syntax or semantics - so every change to syntax / addition has to
> be done
>       in a way which will not break user scripts.
>
>     - All the syntax in the engine is done using hand-coded parsing - it
> is very
>       easy to introduce unintended ambiguities and syntactic forms which
> we did
>       not intend.
>
>     - It is quite labour intensive to add / change syntax which means
> experimenting
>       with it (which you need to do to get it 'just right') is hugely
> costly.
>
> In contrast, all of LCB's syntax (beyond the core control structures and
> definiton
> structures) is defined in LCB itself, and binds direct to handlers which
> implement
> that syntax (in contrast, in LCS, you have to write C++ code both to
> parse a piece
> of syntax, and to dispatch it to the implementation). For example, the
> syntax you
> mention above is defined like this:
>
> syntax BaseConvert is left binary operator with conversion precedence
>      <Operand: Expression> "converted" "from" "base" <Source: Expression>
> "to" "base" <Target: Expression>
> begin
>      MCMathEvalConvertBase(Operand, Source, Target, output)
> end syntax
>
> With 'MCMathEvalConvertBase' being a (foreign) handler implemented in
> C++ which performs
> the action of the syntax.
>
> The main limitation with LCB's syntax right now is that it has to be
> compiled into
> a parser spec ahead of time - i.e. at creation of the lc-compile tool -
> but even with
> that restriction, 'playing' with syntax is possible by just a tweak to a
> code file and a click of
> a button (albeit in a native code IDE), rather than spending many hours
> hand modifying
> some rather old (and in some places very complex) C++ code.
>
> Of course, one valid retort here would be - then why don't you just make
> it easier to
> do this by changing how the engine works in this regard? And the simple
> answer is that
> we are - in order to do that we need an architecture and method of doing
> so, and LCB is
> that architecture.
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>