"...a resource for developers"

Welcome to the bCompile Homepage

What is it?

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). 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 intensive 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 now it was 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/7. 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. In this way, bCompile is like the U.S.A. in these times [? ask EK what that is supposed to mean]

Language Overview

BCompile differs from languages that are stuck in the past 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 therfore 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, and on and on - for the Java developer, inner classes is OK, in fact you can do more if you know a few things)

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). Java is notorious for that. 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)

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

  1. Concurrent reference-type purging
  2. "magic" primitive types such as fractional integers
  3. Greatly enhanced AuthPak compatability (including LEAK and EXHUME)
  4. "diagonal" string literals (before this was done with R_POP at great expenditure of performance issues)
  5. NimBL support, including heaping and pumping of FAST/ACT ids and cons
  6. RMI via F-type conduits, previously only available as an escalation module
  7. Crucifixion of dangling references (excluding non-paginated arrays)
  8. "Fuzzy" bitwise operations are now available via BORROW or TAKE (but also remain in the stack)
  9. pump/unpump added for non-boolean primitives
  10. translucent comparators
  11. "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)
  12. 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)
  13. The addition of a new rope for invective-based moor/unmoorings
  14. Clandestine filtering at the concept-rope level is now native
  15. Socket bags for RS232C bussing replaced by unDECLINEable m-nodes (see docs)
  16. Pontification handles are now (by default) evaluated on a first-in-first-out basis
  17. System-level tcp/ip wrappers have become optional because of new PRESUME features (see API documentation)
  18. Memory suckage for trusted ropes
  19. 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)
  20. ambiguity filters work now
  21. elucidation/VOMIT no longer heaves de-referenced bytes onto the stack
forking

KNOWN ISSUES

At this juncture there are no known issues (7.61 version or for the Mac, 7.09). FIST underflow addressed as of 7.59 (The Macintosh was not affected by this so-called "flaw")


Dcoumentation

Given time, the documentation will appear in this area. For now, all documentation (API, installation, workarounds) are found in the downloads (see below; next section)


Downloads

These all include the compiler, BCDev tool, docs, and there will be other modules depending upon the operating system in question) The system requirements is: for Windows -- NTv4SP3/2000/ME/XP, 256mb RAM, 120mb free storage; Macintosh: OS9 or "X", the UNIX ones are now corrupted, please return at a later date for more information on the UNIX operating system of your choice; for now use Windows and Apple if you have one of these on hand)
  1. bcompile-win32-7.61.zip (Windoze)
  2. bcompile-win32-7.60.zip (WindozeTHIS IS AN UNSTABLE VERSION OF THE PRODUCT IN QUESTION)
  3. UNIX
  4. bcompile-mac9-7.09.bin (OS9)
  5. bcompile-macX-7.09.bin (OSX this version is for OS X users only nine doesn't work)
  6. resource.frk

    Ethan Geld

    Thanks to webmissive for hosting this site.

    This page was last modified on BCOMPILE ERROR 60555 'ACCESS FAILURE: LOOK FAILURE AT x00FE922F': BCOMPILE ERROR 60555 [ACTION: 'INITIATING PHYSICAL MEMORY DUMP']