Another way to search individual guides is to search the markdown files on GitHub: https://github.com/livecode/livecode/tree/develop/docs/guides and https://github.com/livecode/livecode-ide/tree/develop/Documentation/guides. 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@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 > 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 > _______________________________________________ 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
