Writing Extensions

[Mark Waddingham]

On 2017-05-23 17:53, Mark Wieder via use-livecode wrote:
> I'm not doing this because it's fun. I'm stuck with parsing xml data,
> and it's much uglier trying to treat it as a text stream, especially
> with a subset of the xtalk chunking functions, than by using the
> revXML functions in LCS.

Yes - so LCB could do with a module which wraps libxml...

> It might be useful to have a list of what xtalk features are available
> in LCB, and possibly even more useful to have a list of the features
> that *aren't* available in LCB. For instance, the lack of a switch
> statement is both surprising and disappointing. What decisions were
> made as to what language features to support / remove?

That is the wrong way to look at things I think - it was never a 
question
of 'what should we remove or add compared to LCS'.

LCB is a language in its own right - indeed, you can write entire 
applications
in LCB (and run them using the 'lc-run' tool)... Our 'vulcanbot' (the 
system
which integrates our buildbot-based build system with github) is written 
entirely
in LCB for example.

The design of LCB has been influenced by a number of design principals 
(in no
particular order, nor exhaustive):

   a) it should have fully customizable syntax (at least 'statically' -
      i.e. at the point the compiler is built)

   b) the syntax should be familiar to LCS

   c) operations should be strict (throw an error for indexing out of
      array bounds, for example, rather than throw an error)

   d) strong dynamic typing, with the aim that if fully typed, then an
      LCB module should be completely statically checkable

   e) enable interoperation with other languages to be defined *safely*

   f) allow modularity without co-operation

   g) it should run on a VM which could be shared with LCS

   h) it should have a type-system which could subsume LCS's type-system

   i) be a natural extension language for LCS (i.e. replace C++ as the
      main implementation language for LCS features)

   j) favour abstract patterns, rather than concrete features (as one
      can implement many concrete features from one abstract pattern)

   k) it should be possible to compile a full typed LCB program to 
'native'
      code (for some definition of native) with performance commensurate
      to that you would get if you wrote in said 'native' tongue

LCB is as much about trying to find the line between what we consider a
very high level language (LCS) and what we consider to be a low level
language (such as C) - blending the two together. It is influenced by 
many
languages (principally LCS, admittedly) but perhaps is not quite like 
any
specific one.

At the end of the day I could go on at length here (what do you know,
language design and implementation is probably my biggest computing
interest ;) ); however, I'll leave it as an 'interesting exercise for 
the
reader' to consider what becomes possible if we can (at the very least)
achieve to the full extent possible principals (a), (g), (h) and (k)...

Warmest Regards,

Mark.

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