cx

cx is a modernized version of C. cx adds no overhead to C, but adds modern conveniences cx is built on LLVM and will run on any platform supported by LLVM

Simple:

• ultra minimalist (based upon C and GO)
• fast as C
• simple grammar

Relationship to C:

• cx is almost reverse compatible with C
• C programs can be easily ported to cx
• cx effortlessly imports C depedencies

Advanced Features

Modern conveniences:

• struct reflection
• map[int]int dictionary type
• string type
• memory safe slice, array type
• channels for concurrency (based upon golang channels)

Stricter Specification than C:

• fixed width types int32,int64, float32, float64 defined in standard
• cx defines serialization of structs to byte array
• no implicit type conversions
• official coding style for language

Reflection:

• Struct Reflection. Ability to get member variables for cx structs at runtime
• Function Reflection. Ability to get name and type signature of exported module functions at runtime.

Extensible Syntax

• cx programs can extend the grammar of the language
• programs can define domain specific languages in cx

Compilation:

• cx can be run both as a scripting language and compiled
• cx modules can be recompiled and reloaded at runtime

Cx Compilation

Caching Compiler:

• cx is a caching compiler.
• cx compilation is designed to be massively parrallel
• cx only re modules if a file in the module has changed
• cx caches the AST of parsed modules
• cx will only recompile a module if

cx flow control

for statement:

• There is only for. There is no while, until, not for.
• parens are optional.
• Semicolons are only needed for seperating statements
• := infers type

Note: replace ":= range" with "in"

//while loop
for i < 5 {
i++
}

//for loop
for i:=0; i<5; i++ {
}

//range keyword, for key,value
for index,value := range KeyValueExample {
}

//optional: range keyword?
for num := range(0, 10) {
//do something
}

---

if statement:

• parens are optional
• last statement in list is return value for if

if x == false {
//do something
}

if x:= y+z; x==5 {
//returns true
}

--- advanced, optional ---

"get list of X that match Y"

select x := range List; x.Id == 5 {
}
//can this be for statement?
//is there better way of doing selector?

List Selectors/Pattern Matching

list := select(x:= range List, x.Id =5)
//returns list, iterator/list, condition
list := for x:= range List; x.Id= 5
//use "in" for iterator instead of ":= range"?
list := select x := range List {
}
python:
a = [1,2,3,4,5]
b = [x for x in a if x > 3]
token: b = filter(lambda x: x > 3, a)

Sorting for structs

list := sort x := range; x.Index list := sort x,y in ``
cx program structure
====================
Cx does not have a "link" phase in compilation. Cx uses a platform indepedent structure for loading depedencies. A cx program consists of a series of modules. -- module type reflection --
Each module has a reflection function that defines the types exported by the module.

[type name], [type signature], [field names], [function pointer] ("test_struct", "{int,int}", "x,y", 0x...) ("test_struct2", "{int,test_struct2}", "x,t1", 0x...)

Type signatures of types exported by the module may only contain
- atomic types
- previously defined struct types
- pointers to struct types
-- module type dependencies --
A cx module contains a list of types and signatures for types required to define types in the current module. Each type must be defined down to the atomic type.
- atomic types
- previously defined struct types
- pointers to struct types

[module], [type name], [type signature], [field names] ("module", "struct_name", "{int,int,int}", "x,y,z")

-- module function reflection -- Each module has a reflection function that returns the functions exported by the module. The function returns a list of

[function name], [type signature], [field names], [function pointer] ("test_function", "{int,int},{int}", "x,y,z", 0x...)

-- module function depedencies --
Each module has a table of external functions used by the module.
Note
=====
Difference between - assert - assert invariant
- error - error
When are asserts/invariants different from errors?
- preconditions
- post-conditions
"specifications" - post conditions/preconditions
testing impossible without a "specification?"
---
Precondition
- predicate that holds before function is run
Post-condition
- predicate that holds after funtion if precondition is met
Pre: member(x,l) List remove(x : Elem ,l: List) {
if (x == head(l))
return tail(l);
else
return cons(head(l),remove(x,tail(l)));
}
Post: !member(x,l)
• Most useful if they are executable
– Written in the programming language itself
– A special case of asserts
Positive Assertions
Negative Assertions
---
For static analysis:
- mutation testing?
- fuzzing
---
" Codenomicon[6] (2001) and Mu Dynamics (2005) evolved fuzzing concepts to a fully stateful mutation testing platform,"
---
http://en.wikipedia.org/wiki/Notation3
@PREFIX dc: <http://purl.org/dc/elements/1.1/>.
<http://en.wikipedia.org/wiki/Tony_Benn>
dc:title "Tony Benn";
dc:publisher "Wikipedia"