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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
