ali.lloyd at livecode.com
Tue May 23 14:41:15 EDT 2017
Another way to search individual guides is to search the markdown files on
GitHub: https://github.com/livecode/livecode/tree/develop/docs/guides and
Again, not ideal. There's an outstanding enhancement request for full-text
search of all the guides: http://quality.livecode.com/show_bug.cgi?id=15957
I've just added http://quality.livecode.com/show_bug.cgi?id=19728 for quick
search of the currently viewed guide in the IDE.
On Tue, May 23, 2017 at 6:57 PM Mark Waddingham via use-livecode <
use-livecode at lists.runrev.com> wrote:
> 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
> of 'what should we remove or add compared to LCS'.
> LCB is a language in its own right - indeed, you can write entire
> in LCB (and run them using the 'lc-run' tool)... Our 'vulcanbot' (the
> which integrates our buildbot-based build system with github) is written
> 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
> 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
> languages (principally LCS, admittedly) but perhaps is not quite like
> 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
> 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 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:
More information about the Use-livecode