BCompile

BCompile is a programming language with its roots in Eclaire, initially developed in Zurich as an alternative CMR/C shell-scripting language that would provide for proleptic instigation of batch files for individuals who utilized CMR/C operating system in sub-standard ways (for example, batching).

History

While the Eclaire project in its original form (proleptic instigation) was subsequently abandoned after the emergence of the BERT-5 utilities, work on the project was dropped and then resumed at the University of Copenhagen at a later date. The new mission of Eclaire, in 1988, was to develop the first full-fledged programming language capable of "server-client synchronosis". Simply put, server-client synchronosis would provide for individuals to invoke the execution of the same executable running on his or her choice of the server (this would be, for example, at the time an ARPANET node, which would become the Internet) or client (usually a UNIX host or the arrival of telnet client).

With the arrival of the World Wide Web, the new mission of Eclaire (by now called SKiP, which for all intents and purposes was Eclaire with array clefting, having been "rechristened" by Bob Harrison at Ohio State University, where Eclaire/SKiP had ended up at) had been greatly enhanced by the WWW. At length, the decision was made to call it SKiP. Harrison and John Hayes of OSU, with funding from the U.S. 'Dept of Agriculture and their colleagues, continued development of SKiP as a compiled programming language capable of server-client synchronosis.

By 1994, legal forces forced SKiP (and its demented stepchild SKiP-FL, the scripting language, mostly for the client end, which is all now bCompile) to abandon its name, which became bCompile as of the close of business, August the 23rd, 1996. SKiP was relinquished, but the project was far from being done, as future events would prove to be true. Along with the name change came a new reason for the language to exist. This would take the form, now well-known, of the of the WWW (and the Internet as a whole), which was gaining awareness by 1996/1997. The importance of client-server, etc., was growing exponentially with every breath. (A footnote to history is that Eclaire in its original form evolved into the TRunK8 suite of tools.)

Enter Ed Keller, who brought bCompile, under his guidance, to where it is today. In addition to bCompile's server-client synchronosis (the first to become certified as a fully pROg-dOg-compliant component), this "robust" and "scalable" language also lists many other features on its impressive resume, including array clefting, concurrent start-put functionality, elucidation/VOMIT, ids and cons (explained below), base allocation in unseen threads, synthesis, RECTIFY as a "completely" new idea, remembrance for inner nodes, expanded forking, etc.

While its history has been long, bCompile in its current form has only been available in recent times, making it one of the newest platforms around to develop on.

Language Overview

BCompile differs from most languages in that it makes no distinction between commands, statements, expressions, operators, qualifiers, modifiers, variables, or constants; all of these are simply thought of by bCompile as "ideas" (usually referred to by developers simply as an "id", as noted above). Similarly, the situation bares some likeness to larger constructs. That is, where other languages have the notion of subroutines, procedures, classes, methods, objects, subroutines, interfaces, etc., bCompile makes no distinction between them. As far as bCompile is concerned, each of the above is just a collection of "ideas" and is therefore thought of by the inner workings of the language as "concepts" (usually referred to by developers simply as an "con", as noted above).

Hence bCompile developers think in terms of ids and cons, as noted previously. (Not to worry, cons can be nested, making what others would call a class, function.)

Furthermore, the notion of the syntax error has no place in the repertoire of bCompile. That is, bCompile lacks a notion of an "evil" line of code. Whereas other languages essentially think that some lines of code is "good" (the ones with no syntax errors) and the rest are "evil" (syntax error), bCompile does not think in the outmoded mode of good-vs-evil, which was one of the first things hammered through by Ed Keller upon his 1998 arrival at the SKiP project (now bCompile, and he is still there).

Instead of good-vs-evil, bCompile takes the approach of trying to understand the line of code, which are delimited by carriage-return-line-feed as is usual on many, many systems out there. The first part is not normal though; it gets complicated, but basically the compiler first harnesses a statement rope, then an expression rope, then an operator rope, and so on until it gets to the bottom. Once it goes through the ropes down to modifier, it grabs a scalar introspector for the unknown ids in the line and first thinks of it as a variable and then as a constant, which if not found either becomes null, zero, negative zero, or false for booleans. (It thinks of cons before ids).

So what you have is lines "formerly known as good" that the compiler knows what to do with and "evil" ones, which they are systematically ignored completely by the compiler and at runtime. Those lines is just completely ignored. (This will cause you some problems, and if so, use RECTIFY, as described further on down in this document)

Recent Enhancements

BCompile Series 7 introduces several new features and constructs hitherto ignored worldwide:

* Concurrent reference-type purging
* "magic" primitive types such as fractional integers
* Greatly enhanced AuthPak compatibility (including LEAK and EXHUME)
* "diagonal" string literals (before this was done with R_POP at great expenditure of performance issues)
* NimBL support, including heaping and pumping of FAST/ACT ids and cons
* RMI via F-type conduits, previously only available as an escalation module
* Crucifixion of dangling references (excluding non-paginated arrays)
* "Fuzzy" bitwise operations are now available via BORROW or TAKE (but also remain in the stack)
* pump/unpump added for non-boolean primitives
* translucent comparators
* "quantum" operations now allowed during SACRIFICE file I/O (removes the intermediate step of parsing stack-wise SUGGEST hooks as if they was byte arrays)
* Negatively charged buffers are now inherited instead of "bought" from the processor, greatly improving stall-debilitate negotiations and exterminating the need for opinion-based boolean constructs, which was problematic to put it mildly)
* The addition of a new rope for invective-based moor/unmoorings
* Clandestine filtering at the concept-rope level is now native
* Socket bags for RS-232C bussing replaced by unDECLINEable m-nodes (see docs)
* Pontification handles are now (by default) evaluated on a first-in-first-out basis
* System-level tcp/ip wrappers have become optional because of new PRESUME features (see API documentation)
* Memory suckage for trusted ropes
* STREAMable reference types may now be attached as passengers to 32-bit concept ropes (FASTEN operations from this day forth are stripped during r-preproc or, for unanimous hooks, ignored at compile-time)
* elucidation/VOMIT no longer heaves de-referenced bytes onto the stack

Known Issues

At this juncture there is one known issues (7.61 version or for the Mac, 7.09). FIST underflow reportedly addressed as of 7.59. (The Macintosh was not affected by this so-called "flaw"). The issue is ambiguity filters is busted for x86 platforms. They say they are working on it. This is hardly used by the programming community but it is mentioned here nonetheless because it is an issue and it is known to people who tried to use it and nuked their stack. It is a minor flaw and should be treated as such by the ones who use blobjects. (It only affects blobjects.)

Further reading
http://macslash.org/comments.pl?sid2876&op&threshold0&commentsort0&modethread&cid3358

Main Menu

See Also

Main Menu