Compiler

LLVM langauge experiment,

A subset of C/C++,+more, resyntaxed like Rust. Implemented in C++.

'$ make' to compile & run inbuilt test

'$ ./hack -r example.rs' to compile & run example program.

see 'example.rs' example source;

Dont have a name yet hence 'hack'..

Currently supports:-

• most C operators, functions, structs,if-else,
• 'everything is an expression' syntax
• rust-like 'enum/Match' - tagged-unions & pattern-matching
• C for loops + break../else{..} expressions
• RAII (destructors)
• function overloading+UFCS
• limited operator overloading (no conversions yet)
• Forward+Reverse Type Inference within functions,
• forward between functions -by adhoc template sugar
• stack-based closures
• templated functions & structs
• new/delete ,and a ordered or named struct field initializer
• limited C++-style internal vtables & single inheritance
• emits LLVM sourcecode, compiled by clang, links with C/C++ ecosystem.

WIP

• rust-like iterator protocol
• details of C++ RAII
  • RValue-refs work in simple cases,more tests needed
  • ctor/dtors compose now, but TODO Foo():Bar()..{} syntax
• Parsing rust Trait/Impl
  • not planning on getting a full implementation done soon,
  • I prefer UFCS/overloading
  • but relatively easy to get it parsed
  • might inspire getting a larger subset of Rust handled..
  • details - 'Self' type - in progress..
• rust-style enum/match-
  • currently does a..b a..<b, a|b|c, (a,b,c), if guards, @,nesting;
    • no slice patterns yet
  • have tried to add scalas idea of being able to reference vars in patterns (by unary @)
  • works with ptrs, matching C++ refs appears bugged
  • just added padding of variants,like rust.
• HKT (template-template parameters)
  • .. not extensively tested
• Missing operators
• (todo ++/--;and currently &p[i] instead of ptr arithmetic)
• deref for smartpointers!
• [] for collections

example source.. https://github.com/dobkeratops/compiler/blob/master/example.rs

Long Term Goals / project pillars, Prioritized :-

• 1 a systems language, 'for games'. no GC,zero overhead principle.
• 2 significant C/C++ subset resyntaxed, intended for nondestructive transpiling both ways
• 3 open-world polymorphism (starting with UFCS)
• 4 Add features inspired by Rust, keep syntax close
• 5 dedicated features for parallelism, shader+GPGPU programming ?
• 6 Aim to actually compile a subset of Rust,
  • unless proves impossible to reconcile with goals 1,2,3
• 7 a subset should make a passable embedded dynamic language
  • think of 1 language to handle the C++-&-embedded-Lua usecase. recover @ptr..
  • but dont' compromise goals 1-6 over this.

Short Term Priorities

• solidify current features set (bugs, fix any oversights, cleanup)
• complete feature set required for compiling own transpiled own source
  • undecided-wait for a C++ -> Rust transpiler to appear and adapt it? or start one..
    • dont want to bite off more than I can chew
    • Sugar Cpp is a similar project that could use transpiling from C++.
• solidify Rust enum/match - rusts 'coolest' feature&most complimentary to C++.
  • extend eg anon enums? overload '.discriminant()'?
• intrinsic macros.. dump!() assert!() .. practicalities (dont need full macro system) etc
• a simplified module system
• low priority: gradually expand C++ and Rust features set covered (trait objects, rust macros)
  • .. but get bits done when focussed on an area of overlap
  • maybe aim to get all of Rust parsed, at least eg impl, lifetimes, even if not compiling
  • Rusts Macro System would fit perfectly but is low priority
• Keep track of 'jonathan blows JAI' language and
  • maybe copy features,
  • the syntax is different but in time we could switch

Rationale

Basically trying to combine everything I like from C++ & Rust, dropping what I dont like, plus what i've always missed.

This could all be done as a fork of a C++ compiler, or as a fork of Rust. however maintaining a fork againt commnity momentum (and trying to make such changes with either complex sourcebase) would be hard.

.. Anything here could be considered 'feature requests' for C++ or Rust.

I beleive C++ can be 'fixed' and improved without straying so far,without sacrificing existing knowledge & code. A C++ compiler could be 'reskinned' to fix syntactic problems?

Rust has many inspiring features but is a departure from C++ lacking features like function overloading that prevents representing existing C++ code; But its close enough to beleive it would only take very small changes to satisfy me.

Also I value performance+productivity over compile-time safety. You need to write tests for other reasons, so IMO productivity for tests will still yield stability... there is still so much you still can't express in a typesystem or verify at compile time.

I beleive C++'s main 'curse' is the way "headers & classes interact", and the asymetry between functions and methods has always been frustrating.(I have worked mostly on platforms where vtables were unacceptable). The standard libraries are messy but easily replaced. UFCS would be a big step forward.

Other C++ flaws are acceptable due to its evolutionary path and need to represent low level code

Rust on the other hand is a little too restrictive; in particular I want to be able to think primarily in Functions & Structs - not classes,traits, or hierachical modules. Rust Traits are good but I'd prefer them optional & duck-typed. Rusts philosophy edges toward verbosity,'costs must be explicit' -IMO costs should be deterministic sure, but typing more for slow code doesn't make it faster- it wastes time on setup,tools,tests.. What is important is expressivity, ability to write optimal code more elegantly. Rust has to over-estimate safety to be sure. Some performant patterns are still safe, without being compile-time provable. empirical tests are usually good enough.

So somewhere between the two is my perfect language.

This is probably all way beyond a 1man project but I'll see how far I can get. Perhaps I can just experiment and converge on whatever mainstream option is closest.

If another language has every feature I want in one place... great, I'll ditch this.

project structure & info..

• 'main.cpp' contains the driver,'parser.cpp' builds the AST,

• 'node.h'=abstract AST node; implementations - eg'exprfndef.cpp' &'exprstructdef.cpp' 'exprOp.cpp (operator);

• 'semantics.cpp' & '::resolve()' methods do inference/overload resolving..

• 'codegen.cpp' encapsulates the output, called from node '::compile()' methods

• this is a hacky text output at the minute but does the job,

• maybe replaced with mutliple back ends... LLVM, C++ transpile..

• sorry for the range of coding styles here:

• I'm intending to transpile to self-host,

• so have been reluctant to dive into full "modern C++"

• still might want to eliminate dependance on C++ stdlib with simplified Vec<T>

Open questions...

• inbuilt slice/vector types like .jai?

  • reasoning behind that makes sense
  • but we have templates already
  • might just give syntax sugar for declaring them
    • [] [..] [N] == __slice<T> __vector<T> __array<T,N>
    • [K=>V] == __dictionary<K,V>
    • .. then we can switch to inbuilt later..
    • still might just want to recover old Rust syntax ~[T], ~T, ~str [T*N] .. it was nice!

• default value passing behaviour especially * vs &, C++ vs rust..

  • C++ - value, copy by default, but autoborrow for '& ptrs' (aka references)
  • Rust - move by default, must write 'borrow' explicitely.

• whats' more useful, whats' more consistent?

  • Move is cheap, borrow is cheap, but which is more common..
    • find oneself writing & a lot in rust.
  • Can types from both slot in one system, eg flag rust stuff as 'Move', c++ stuff as Copy

• this language wants immutable default, like rust.

• immutable-borrow is just like a value, so reverting to C++ like behaviour modified for immutable borrow could be nice.

• its nice that Rust makes copy explicit (.clone()), as its' expensive

  • do we want to use C++ copy-constructors, or go that route..

• perhaps we should just have immutable-borrow as the default/nothing extra typed

  • and write explicit move or copy operators/functions
  • and have to write something explicit for a mutable pointer.
    • agree with google-style guide's preference to make output params obvious at callsite
    • rust also requires you to write &mut

• So is simply C++ like behaviour, tweaked for immutable default enough

• can we still shoe-horn compiling Rust source into this

  • Auto-coerce *ptr to &ptr, and & makes a * like in C++.
  • does that break any C++ code?

• What are the deatils of jonathan blows ^ptr. how does that sit.

  • would most likely want to converge on that language..

• Could we just generalize how the * & operators act on types and use some syntax on their declaration to set that up

  • so C++ transpiled and rust originated types get the right behaviour

Rust Compatability ???

• everything I want would be possible as a superset of Rust.
• It would be nice to build this up into 'a superset of a subset of Rust'
  • try to overlap with Rust community, Rust tools.
• but (i)I'm unlikely to be able to sort out every detail single handedly
• but(ii)its' not essential for the 'Project Pillars'.
• would anyone out there want to collaborate on building this up into a full rust implementation?
• full rust macros would be a nice addition that don't complicate the internals
• its' still possible future Rust versions might include these features..

Goals In detail:- (a huge TODO list..)

• Resyntax a significant subset of C++, in the spirit of SPECS;
• should be possible to non-destructively translate a subset back & forth.
  • to eliminate the risk of transitition
  • allow use with,& in, established C++ librari