The Free Proprietary Software Community serves software developers and engineers, described in https://github.com/CCT-token/free-proprietary-software-community. The Compiler Compiler System will be used to bootstrap FPSC ideas and essentially will be a sub-community within the FPSC. The CCS is an example of how sub-communities can be formed and how their products can be distributed through tokens or fiat currency. All related CCS products will be connected with the CCT Token. Any other sub-communities created, either a sub-community that works with IoT solutions or AI solutions etc., can create their own token. Every software created within the FPSC, is considered Free Proprietary Software, which will enable developers to share code for research and development for free but once they start selling for profit, the developer will be paid with community tokens or pay with fiat money. This setup creates a software developer community where developers will be incentivized by sharing their code through tokens (or fiat). The next sections describe how FPSC can grow at a large scale by using the Compiler Compiler System.
a compiler creating compilers.
The CCS is a tool, enabling programs to compile any source code.
The CCS has a specific Source Grammar Definition Language (SGDL), which is
used as an input to generate a target parser with additional code,
compiled and linked into an executable program.
After the Compiler Compiler System runs, it creates a program
that is ready to compile source code and also it is
ready to generate Compiler Compiler System (CCS) Syntax-Controlled Binary, as well as it is
ready to decompile the binary to its original definition.
The Compiler Compiler System's important feature of generating
CCS Syntax-Controlled Binary and then decompling that binary to its
original form will prove to provide solutions to many technological
slowdowns: Compilation, Interoperability, Obfuscation, Security,
Content Management, Scaleability, Standardization.
These areas, as well as their solutions, will be discussed below.
The Compiler Compiler System is a tool.
Being a tool, it is about bettering the lives for software developers.
The diagram shows the present invention, The Compiler Compiler System, and its phases for building itself.
The Compiler Compiler executable program, 205, takes Compiler Compiler Source Grammar Definition Language 201, which defines itself (regarded as meta grammar). Phase 2.1a, takes 201 and generates 202, the Compiler Compiler System Syntax-Controlled Runtime. The Compiler Compiler executable program, 205, has an option to de-compile the meta grammar source text from the Compiler Compiler Runtime, shown as Phase 2.1b. This newly de-compiled meta grammar as a text, is identical to the meta grammar from
201 except for some differences related to supported indentation rules.
The Compiler Compiler executable program for the given meta grammar performs Phase 2.2a, generating the Compiler Compiler Syntax-Controlled Binary, 203, for the corresponding Compiler Compiler Syntax-Controlled Runtime. Phase 2.2a is implemented as a formal procedure that converts CCS Syntax-Controlled Runtime into CCS Syntax-Controlled Binary. The Compiler Compiler executable program
has an option to de-compile the meta grammar, generated from the CCS Syntax-Controlled Binary, into a text file (not shown) containing the meta grammar executing phase, Phase 2.2c. This newly de-compiled meta grammar, as a text, is identical to meta grammar from 201 except for some differences related to supported indentation rules.
Having the Compiler Compiler Syntax-Controlled Binary executing phase 2.2b, the Compiler Compiler executable program has an option to re-create a Compiler Compiler Syntax-Controlled Runtime that is identical to the original Compiler Compiler Runtime from 202. The Compiler Compiler executable program performs Phase 2.3, creating Compiler Compiler generated code, 204 corresponding to the meta grammar from 201.
The C++ CCS Syntax-Controlled Runtime API is defined in these files:
include/SyntaxControlledRuntime.h and src/SyntaxControlledRuntime.cc
The C++ CCS Syntax-Controlled Binary API is defined in these files:
include/SyntaxControlledBinary.h and src/SyntaxControlledBinary.cc
C++ CCS and C CCS both have two implementations of the Parsing Model: Syntax-Controlled Runtime and Binary.
The Syntax-Controlled Runtime is used by parser performing parsing operations using the corresponding API.
If the parser is successful at analyzing the source program, the Syntax-Controlled Runtime can be (formally)
converted to Syntax-Controlled Binary. Any additional semantics processing can be done on Syntax-Controlled Binary
using the corresponding API. Having a target language description on SGDL, the corresponding parser and additional
code are generated, when the executable program for the target compiler is built, that compiler program is capable
of compiling programs on the specified language into Syntax-Controlled Runtime with a subsequent transformation into
Syntax-Controlled Binary; also that compiler can de-compile the provided Syntax-Controlled Binary file into the original
source code in accordance with the target language grammar. Ones again, all described operations are completely automated.
(Back to top)
Meta Grammar
Source Grammar Definition Language (SGDL)
Compiler Compiler System Syntax-Controlled Runtime API
Compiler Compiler System Syntax-Controlled Binary API
Compiler Compiler System Syntax-Controlled Runtime
Compiler Compiler System Syntax-Controlled Binary
Compiler Compiler Executable Program
When C++ compiler compiler executable program 205 takes the following meta grammar source file:
(meta
(grammar ::=
0 =" METAACTBEG();"=
'(' grammarNameDef
{ rule }
')'
0 =" METAACTEND();"=
)
(grammarNameDef ::= identifier
)
(rule ::= '(' nterm '::=' right ')'
)
(nterm ::= identifier
)
(right ::= { element }
)
(element ::= identAlt | alternative | identMiss | iteration | action
)
(action ::= integerToken '=' { stringToken } '='
)
(actions ::= '=' { action } '='
)
(identAlt ::= ntermtermact { Altpart }
)
(Altpart ::= '|' ntermtermact
)
(ntermtermact ::= ntermterm [ actions ]
)
(ntermterm ::= nterm | termToken
)
(alternative ::= '(' identAlt ')'
)
(identMiss ::= '[' identAlt ']'
)
(iteration ::= '{' iterItemact iterItems '}'
)
(iterItems ::= { altIterItem }
)
(altIterItem ::= '|' iterItemact
)
(iterItemact ::= iterItem [ actions ]
)
(iterItem ::= nterm | maybeNterm
)
(maybeNterm ::= '<' nterm '>'
)
)
As a result of phase 2.3 the following C++ source files are generated:
- metaGenerator.h
- metaKeyWordDefinition.h
- metaParser.h
- metaGenerator.cc
- metaKeyWordDefinition.cc
- metaParser.cc
- metaMakeGenerators.cc
Note, that the 'meta' prefix in file names corresponds to the grammar name
- the first section identifier in SGDL.
Note also that
0 =" METAACTBEG();"=
0 =" METAACTEND();"=
are used as a special macro substitution actions defined in form of integer
number followed by sequence of string literals enclosed in '=' and '='.
(Back to top)
The Compiler Compiler Source Grammar Definition Language elements such as '(' and ')'
are grammar terminals defined as a string literal with enclosed single quotes.
The Compiler Compiler Source Grammar Definition Language consists of a grammar "name"
section followed by a sequence of rules where the first rule is also a grammar axiom.
As used herein, the grammar name section consists of a single identifier that defines a name of grammar.
The Compiler Compiler Source Grammar Definition Language element:
{ rule }
is a BNF extension called iteration, meaning that enclosed by { and }
non-terminal may occur zero or any other number of times.
Note, that, e.g., rule
(iterationExample ::= { element } )
is equivalent to rules
(iterationExample ::= element iterationExample )
(iterationExample ::= )
The Compiler Compiler Source Grammar Definition Language element:
(rule ::= '(' nterm '::=' right ')'
)
defines rule as a terminal '('
followed by non-terminal nterm, followed by terminal '::=',
followed by non-terminal right, followed by terminal ')'.
The Compiler Compiler Source Grammar Definition Language element:
(nterm ::= identifier
)
defines non-terminal nterm as identifier.
The Compiler Compiler Source Grammar Definition Language element:
(right ::= { element }
)
defines non-terminal right as an iteration of element non-terminals.
The Compiler Compiler Source Grammar Definition Language element:
(element ::= identAlt | alternative | identMiss | iteration | action
)
defines non-terminal element as an alternative of non-terminals on the right side of
rule definition separated by '|'. The alternative is BNF extension similar to
iteration extension; it is used in cases when non-terminal on the left side of
rule definition can be one of non-terminals from the right side.
Note, that, e.g., rule
(alternativeExample ::= A | B | C | Z )
is equivalent to rules
(alternativeExample ::= A )
(alternativeExample ::= B )
(alternativeExample ::= C )
(alternativeExample ::= Z )
The Compiler Compiler Source Grammar Definition Language element:
(action ::= integerToken '=' { stringToken } '='
)
defines non-terminal action as an integerToken followed by terminal '=',
followed by iteration of stringToken followed by terminal '='. Here integerToken
and stringToken are another Compiler Compiler Source Grammar Definition Language
reserved key words similar to identifier. integerToken defines token that holds
integer value. stringToken defines token that holds string literal value as an
arbitrary sequence of any characters enclosed with double quotes, i.e., ".
The Compiler Compiler Source Grammar Definition Language element:
(actions ::= '=' { action } '='
)
defines non-terminal actions as a iteration of action enclosed with '='.
The Compiler Compiler Source Grammar Definition Language element:
(identAlt ::= ntermtermact { Altpart }
)
defines non-terminal identAlt as a ntermtermact followed by iteration of Altpart non-terminals.
The Compiler Compiler Source Grammar Definition Language element:
(Altpart ::= '|' ntermtermact
)
defines non-terminal Altpart as a terminal '|' followed by non-terminal ntermtermact.
The Compiler Compiler Source Grammar Definition Language element:
(ntermtermact ::= ntermterm [ actions ]
)
defines non-terminal ntermtermact as a non-terminal ntermterm followed by [ actions ] meaning that
non-terminal actions may be omitted. Non-terminal enclosed with [ and ] is another compiler compiler
source grammar definition language BNF extension representing elements that can be omitted.
Note, that, e.g., rule
(ommitedElementExample ::= A [ W ])
is equivalent to rules:
(ommitedElementExample ::= A Welement )
(Welement::= W )
(Welement::= )
The Compiler Compiler Source Grammar Definition Language element:
(ntermterm ::= nterm | termToken
)
defines non-terminal ntermterm as an alternative of nterm of termToken. nterm is defined above.
termToken is another compiler compiler source grammar definition language reserved key word that defines
terminal token specification as a string literal enclosed with single quotes.
The Compiler Compiler Source Grammar Definition Language element:
(alternative ::= '(' identAlt ')'
)
defines non-terminal alternative as an identAlt enclosed with terminals '(' and ')'.
The Compiler Compiler Source Grammar Definition Language element:
(identMiss ::= '[' identAlt ']'
)
defines non-terminal identMiss as an identAlt enclosed with terminals '[' and ']'.
The Compiler Compiler Source Grammar Definition Language element:
(iteration ::= '{' iterItemact iterItems '}'
)
defines non-terminal iteration as an iterItemact followed by non-terminal iterItems enclosed with
terminals '{' and '}'.
The Compiler Compiler Source Grammar Definition Language element:
(iterItems ::= { altIterItem }
)
defines non-terminal iterItems as an iteration of altIterItem non-terminals.
The Compiler Compiler Source Grammar Definition Language element:
(altIterItem ::= '|' iterItemact
)
defines non-terminal altIterItem as terminal '|' followed by non-terminal iterItemact.
The Compiler Compiler Source Grammar Definition Language element:
(iterItemact ::= iterItem [ actions ]
)
defines non-terminal iterItemact as non-terminal iterItem followed by [ actions ].
The Compiler Compiler Source Grammar Definition Language element:
(iterItem ::= nterm | maybeNterm
)
defines non-terminal iterItem as an alternative of non-terminals nterm and maybeNterm.
The Compiler Compiler Source Grammar Definition Language element:
(maybeNterm ::= '<' nterm '>'
)
defines non-terminal maybeNterm as non-terminal nterm enclosed between terminals '<' and '>'.
The compiler compiler source grammar definition language iteration is actually defined as
a sequence of terminals or nonterminals may be followed by actions, and also non-terminals
may be enclosed between terminals '<' and '>' meaning that such non-terminal is allowed to
be in iteration only zero or one time.
Note, that, e.g., the rule
(anotherIterationExampe :: = { A | B | | } )
is equivalent to the rules
(anotherIterationExampe :: = elem anotherIterationExampe )
(anotherIterationExampe :: = )
(elem ::= A | B | X | Z )
Instructions included in .zip file.
FPSC bootstrapping entails the idea of expanding the community in various ways. One direction is based on Compiler Compiler Technology. The tasks to be completed in that area are depicted in the form of tiers: tier I., tier II., and tier III CCS software products (described in the white paper). Another direction encompasses Ethereum capabilities to build smart contracts with dedicated coins. For CCT related development, there is a plan to create a CCT Ethereum token to be used within FPSC to sell/buy built software products paying with the Ethereum CCT Token and with other Ethereum tokens introduced within FPSC. There are two important factors that bring together the FPSC: Free Proprietary Software License (FPSL) and the incentives that FPSC members issue to each other for licensing their software products using various Ethereum tokens. It is important to distinguish that FPSC is not a community comprised of only software products derived from CCS products.
CCS repository acts as NOSQL database management system. One component of CCS repository, a CCS meta repository, acts as a registry for any language that has CCS SGDL specification. Another component of CCS repository, a CCS binary repository, acts as a storage where any CCS binary for any registered CCS SGDL specification can be maintained: saved, updated, deleted, retrieved.
CCS repository can be implemented as a service on a cloud or physical instance on a given host. Also, many instances of CCS binary repositories can be maintained under the control of the CCS meta repository.
CCS is capable to provide scalability and interoperability solutions based on the CCS repository and the CCS light router that supports only one message type, obtained from the CCS binary for the given SGDL specification and CCS repository ID.
A well known industry solution for distributed applications and integrating them is based on a message bus. The traditional idea of integrating two applications with different end point types is the ability of having a router that supports both endpoint types and provides end point transformations from one point to the other. This approach in general, makes the router heavy with multiple endpoints and applications. In case of the CCS, CCS Binary is a final representation of data processing chain and in this case, the CCS light router can be implemented with a single endpoint type, which is a CCS Binary endpoint.
In the diagram above, Device 1 talks to the application by means of the endpoint, e1, and Device 2 talks to the application by means of the endpoint, e2. Device 1 endpoint e1, is understood by the application’s endpoint e1. The maintenance burden at the application level to support multiple versions of the introduced endpoints is a heavy task in terms of time and cost. For large applications, this scenario creates a well known issue called fragmentation. The idea of CSS Light Router combined with CCS Repository is capable to provide a better solution for integration. The solution is presented in the figure below.
In the proposed diagram, Device 1 and Device 2 are connected with an external world by means of CCS Binary1 (B1) and CCS Binary2 (B2). Traditionally, any endpoint defines a collection of messages. It is not a problem to create, for any given collection of messages, a corresponding CCS SGDL specification that would be an equivalent representation of that collection of messages. The Light Router accepts only one type of endpoint, processing CCS Binary, interacting either with Application or CCS repository directly. In the diagram above, Light Router talks to the Application and that Application submits the results to the CCS Repository. Keep in mind, the proposed solution allows application development based on CCS Binary API only. This way, dependencies with Device 1 and Device 2, with custom manufacturers of software, is eliminated.
Technology is growing vastly with promising advancements however we see through AI, IoT, and various other technologies, we face bottlenecks and setbacks that help us further move forward into a completely scalable, interoperable technological society.
Let's take AI specifically as an example; "Experts estimate that AI market will increase from the $200 billion it is valued today to $3.1 trillion by 2025, but serious roadblocks remain." Today, AI functionality is expensive, time-consuming, and hard to use and is among one of many technologies with similar experiences.
In the following section, we will underly how Compiler Compiler Technology will eradicate these problems completely, solving problems with standardizaton and interoperability, creating a completely scalable technological world in all areas. Solutions to these problems enable the creation of trillions of $US in value but also help us further the advancements of mankind.
Major overall solution for AI: Solving interoperability issue.
The growth and popularity of AI rapidly expanded and has become a significant topic in technology. Despite the growth, AI still exists in a form of some exclusive products promoted to the market by large corporations. During the last two decades, a lot of different standards have emerged in AI marketplace, which furthers us from being an interoperable technological world. We believe that providing solutions for the existing AI standards, e.g., Ontology, based on CCT would be able to change the AI landscape solving interoperability issues.
For the last decade, IoT has become possible for many reasons, one is the tremendous growth of hardware capabilities. Another one is wireless network capabilities. Another is 5G capabilities including new options to run TV services. As a result, at least a hundred IoT platforms have been created in the last decade. As a result, at the consumer level we have an issue of lack of interoperability between those platforms and corresponding products. CCT is capable to deliver solutions for standardization, content management/digitization, scalability, security based on obfuscation and interoperability making it possible to integrate existing IoT platforms.
Content management is a process that takes information in any format and provides an environment for manipulating that data by means of programming. The idea of digitization of any business related information is vital because it is a source for better performance.
The Compiler Compiler System can be used for binary file processing. In this case, a corresponding binary file format has to be designed in the form of Compiler Compiler Source Grammar Definition Language specification. After that, a custom convertor from binary file format into Compiler Compiler Runtime format is implemented. Having a Compiler Compiler Runtime built for a binary file with a given format allows all other Compiler Compiler phases to work automatically without any extra code development.
Traditional text files and/or text specifications on some custom languages including any form of XML, interchange formats, other markup languages, etc. can be transformed by designing the corresponding SGDL specifications, building corresponding front ends and converting those text representations into CCS binary. Keep in mind that CCS Runtime and Binary APIs (completely automatically generated from SGDL) provide a foundation for content management solutions.
---- add text here
Major overall solution for Blockchain platforms: Solving scalability issue.
The key components of blockchain platforms are:
• A distributed ledger to keep track of all transactions.
• Proof of Work (PoW) feature implemented as a security solution against malicious intruders and making a blockchain platform not just distributed but decentralized too. Other ideas including Proof of Stake are in discussion in the blockchain community.
• Smart Contracts. Eg., Ethereum has a smart contract language, Solidity.
• Replication of the ledger across all blockchain network nodes.
• Peer to peer network messaging.
Peer to peer network messaging and ledger replication creates a condition where scalability is not an option.
Compiler Compiler Technology is capable to provide blockchain scalability solutions the following way:
• Introduce a peer to peer messaging layer in a form of SGDL specification.
• Implement ledger based on CCS Repository.
• Instead of PoW, provide blockchain security solutions through obfuscation.
• Combine security solutions based on obfuscation with ledger represented in CCS Repository that is the replicated in all nodes. It is possible to implement other strategies for ledger replication but the main point is to avoid ledger replication in each node, since it is redundant and a blocking factor for scalability.
• Since CCS Repository is scalable and security solutions based on obfuscation can eliminate the necessity of having PoW, the proposed blockchain technology based on CCS is equivalent to the existing blockchain technology.
• Regarding smart contract languages including Solidity, it is possible to implement Solidity compiler and other smart contract language compilers from the CCS, because keep in mind the CCS builds the front-end to any language completely automatically. This way, interoperability solutions between different blockchain networks will be granted from day one. The most complicated area which is less researched is building security solutions, replacing PoW based on obfuscation. This part requires research and development but when it is finalized, scalability issues would not be an issue at all.
Industry created a universal approach for interoperability between different applications by having an interchange format approach. Any interchange format can be defined in the form of CCS SGDL specification with subsequent automatic compilation of that CCS SGDL specification into related interchange format front-end, syntax-controlled binary, and syntax-controlled runtime APIs. Note, that , syntax-controlled binary API can be implemented for any programming language and any software platform including Unix/Linux, Microsoft .NET, Java, GO, etc...
CCS is capable to provide interoperability solutions based on the CCS repository and CCS light router that supports only one message type by having a CCS binary for a given SGDL specification and CCS repository ID. In the Light Router section above, solutions for interoperability were discussed based on CCS Light Router and CCS Repository in more detail.
The Compiler Compiler System provides a solution for automating the creation of standard specification transformations in software products. This approach reduces the expenses for implementing standard specifications in hardware/software products. The C++ Compiler Compiler System generates C++ code for front-end, parser, syntax-controlled runtime API and syntax-controlled binary API. The front-end is an executable program that provides compilation from source into syntax-controlled binary. During this process, parser builds syntax-controlled runtime that is formally converted into syntax-controlled binary. Also, backward operations from syntax-controlled runtime and syntax-controlled binary into the source program are provided. The business logic operations can be defined by means of syntax- controlled binary API. This way for any given standard there is an option to use CCS syntax- controlled binary API instead of creating custom implementations of custom APIs by different software/hardware providers.
“Scalability is the capability of a system, network, or process to handle a growing amount of work, or its potential to be enlarged to accommodate that growth". The most well known scalability solution is the internet itself. Modern cloud solutions with decentralized architecture provide another approach for scalability.
CCS is capable to provide scalability solutions based on CCS repository and CCS Light router that supports only one message type by having a CCS binary for a given SGDL specification and CCS repository ID.
It is known that grammar recognition tasks are NP-complete. In simple words, NP-complete means that the task would run almost forever. Having CCS syntax-controlled binary, the task of the grammar recognition is NP-complete. Having CCS syntax-controlled runtime, obfuscated one way or another, with subsequent formal conversion into CCS syntax-controlled binary would make grammar recognition tasks even harder. Implementing obfuscation/de-obfuscation algorithms for CCS syntax-controlled runtime and binary is an advanced, patent protected way of transmitting data with built-in security features and content management. Keep in mind that the patent describes any binary file transformation into CCS syntax-controlled runtime including video/audio streams. Having all forms of data transformed into CCS syntax-controlled runtime with a well defined logical syntax structure generic obfuscation/de-obfuscation algorithms can be implemented to provide security solutions.
A use case is described in the white paper.