Scheme with C++

I’ve been looking around for a way to embed Scheme in C++ and so I’ve been doing some research. The following is what I’ve read from the docs and keep in mind I haven’t done much coding in them other than compiling some example programs.

First I looked at GNU Guile. I had high expectations, but the more I read about it the less interested I became. It’s just too bloated and too slow, not to mention that it has terrible support on Windows with the only option being Cygwin.

Next I looked at was Chibi Scheme which looked wonderful; small, simple, and portable. The only problem was that it was too lightweight and not fast enough. I’ll recommend using Chibi for lightweight scripting similar to Lua.

Moving on to compiled Schemes, I looked at Chicken, Gambit, and Bigloo. All three of these are interesting in that they compile to C code, which obviously implies easy interop with C/C++

Chicken, like Guile, was disappointing. It looked great for writing Scheme programs, but failed to deliver on embedding inside C, although it did have a nice FFI. I may be wrong on this, but I don’t believe Chicken has good support for Unicode, well at least not as good as the others. Also, it seemed to perform the worst on benchmarks of the 3 compiled Schemes.

Gambit on the other hand, looks great for embedding inside C++. In fact, it’s the only implementation that mentioned C++ in the documentation – the others were entirely C based. Windows is fully supported, although MSVC lacks some GCC optimizations and so MinGW seems to be the best choice. Unfortunately, it has two flaws: 1) it lacks native threads 2) the GC is stop-the-world. These are not huge problems as it supports green threads and the GC can be configured to block less, although these are not ideal solutions.

And finally, Bigloo which seems to solve Gambit’s problems: it uses incremental Boehm GC and it has support for native (POSIX) threads. Well, at least that’s how it appears – the docs are less clear than Gambit’s. Sadly, the FFI is much less nice than Gambit’s and Windows support isn’t stellar – it’s MinGW with some pthread emulation. Oh well, I’d rather play favorites with Linux.

Well, that’s it. I also looked at some other Lisps like Racket and CLisp which were too large, but otherwise good. 

In conclusion, Chibi for lightweight scripting, Gambit for the average embedding in C++, and Bigloo for when you need high performance real-time embedded Scheme. Oh, and Chicken otherwise, although honestly a full-blown Lisp makes it seem unnecessary.



Posted in Uncategorized | Tagged | 2 Comments

C++ Sucks

Disclaimer: This should be titled “Things about C++ that suck,” but “C++ sucks” is a much better search term.

1. Too many ways to write identical things.

This is a language smell. Ideally, there should be one way to write things, not multiple. For instance, there are at least 9 ways to create an alias to an unsigned long int:

typedef unsigned long int foo;
typedef unsigned long foo;
typedef long unsigned int foo;
unsigned long int typedef foo;
unsigned long typedef foo;
long unsigned int typedef foo;
using foo = unsigned long int;
using foo = unsigned long;
using foo = long unsigned int;

The fact that ‘typename’ and ‘class’ can be used in template declarations is rather silly, especially since ‘class’ is only enforced for template templates.

Having both ‘struct’ and ‘class’ is a waste of keywords. I prefer ‘struct’ as defaulting to public gets used much more often then defaulting to private.

Trigraphs are another issue. I can’t see any use for them anymore other than backwards compatibility.

2. Templates are an unholy mess.

Templates are great for their intended purpose: generic types. Attempting to do metaprogramming with them is torture.

The 3 most obvious things are ‘typename’, ‘template’, and ‘this’ used inside of templates. They’re not incredibly hard to use, rather they feel inconsistent with the rest of the language. Major compilers seem to do fine without them – perhaps I’m missing something but it really doesn’t seem necessarily to have them anymore.

Inconsistency is a real problem for templates. Specializations are a real issue here – some things you can, some things you can’t, and others you are severely restricted on. And why can’t parameters be evaluated in specializations?

Metafunctions and types aren’t very type safe. There’s no language feature for them, and so you’re left coming up with your own standards. Also, while tmp practically requires a recursive approach, doing so often causes compiler crashes as everything must be evaluated at compile time – even branches that cannot be reached.

3. The standard library is part of the language

What I mean by this is that many things cannot be done without using the standard library. Some language features even require it, the most notable being certain exceptions, ‘typeof’ and the new initializer lists.

The thing that really bothers me is that perhaps the most used container, std::vector, involves magic. The reason for this is that there’s no standard way to resize allocated memory. realloc() somewhat works, although it doesn’t work for non-pod data types. It blows my mind that the committee has been rejecting improvements to memory allocation for so many years. If 2 functions were added, realloc_nocopy and alloc_size, then I would be very very happy, as (somewhat) efficient memory allocation could finally be possible!

Well that’s all I’m going to write about. There are quite a few other sucky parts of C++, but those 3 are the ones that bother me the most.

Posted in Programming | Leave a comment

Template strings


This prints “foo and bar are foobar!” after formatting it with templates. I’m going to try and add some actual string functions so I can do cool stuff.

Very very messy/buggy code:

Posted in Uncategorized | Leave a comment


Quick overview on things I like and don’t like about C++11.

Things I’ve always wanted:

  • Lambdas
  • auto
  • Explicit overrides and final
  • Better enums
  • Better support for unions
  • Variadic templates
  • Custom literals
  • Static assertions
  • Things the std can do but the core language cannot. I thought C++11 would get rid of this silliness.
  • No static inheritance without using templates
  • No concepts. Concepts are cool.
  • No improvements to macros. The only necessary thing macros are  used for is #include – either improve them or get support for modules.
Everything else I like, I just didn’t know I wanted it until C++11 came out. I hope in a year or two compilers will be far enough that every new feature can be used – it sucks having so many new things without being able to use them all!
Posted in Programming | Leave a comment

Comment approval

Comments don’t seem to get shown unless I’ve approved them (just realized this) and so I’m going to outline a few things:

  •  I’m not going to approve anything with an email address in it. Spam bots will happily find and spam any email posted. I will gladly read these comments, but I will not approve them.
  • Short “Cool!” or “Not cool!” comments are nice and I appreciate them, but I’m not going to approve them simply because they add little to the post.
  • I may choose to not approve questions but later address them in future blog posts. This is because I don’t want to answer them in the comment section.
Posted in Uncategorized | Leave a comment

Metalanguage C

I have been thinking about a new language. A language simpler than C, yet more complex than C++. I want it to strongly support metaprogramming – something I’m surprised more languages haven’t tried. XL seems to be the most advanced, but I think it obscures things too far and isn’t really a specific language.

The basic ideas:

  1. You cannot create a program without defining what things are with metaprogramming.
  2. Meta and non-meta would have 2 different languages with some similarities.
  3. It should be possible to define types, functions, classes and unions in metaprogramming terms – for use in the non-meta code.
  4. It would be nice to be able to define exceptions and C++ style templates in metaprogramming terms.
  5. Using the metalanguage would be optional – everything needed for general-purpose code would be included in the standard library.
Now, creating a metalanguage is what I’m playing around with. I’m probably not going to get anywhere with it, unless of course I end up with something incredibly cool.
The rest of this post I’ll fill out some silly checklist for fun:
X means yes (can be created from the meta part)
M means yes for the meta part
? means maybe
You appear to be advocating a new:
[M] functional  [X] imperative  [X] object-oriented  [X] procedural [?] stack-based
[X] "multi-paradigm"  [?] lazy  [?] eager  [XM] statically-typed  [ ] dynamically-typed
[M] pure  [X] impure  [ ] non-hygienic  [ ] visual  [ ] beginner-friendly
[ ] non-programmer-friendly  [?] completely incomprehensible
programming language.  Your language will not work.  Here is why it will not work.

You appear to believe that:
[ ] Syntax is what makes programming difficult
[ ] Garbage collection is free                [ ] Computers have infinite memory
[ ] Nobody really needs:
    [ ] concurrency  [ ] a REPL  [X] debugger support  [X] IDE support  [ ] I/O
    [ ] to interact with code not written in your language
[ ] The entire world speaks 7-bit ASCII
[X] Scaling up to large software projects will be easy
[X] Convincing programmers to adopt a new language will be easy
[ ] Convincing programmers to adopt a language-specific IDE will be easy
[ ] Programmers love writing lots of boilerplate
[X] Specifying behaviors as "undefined" means that programmers won't rely on them
[X] "Spooky action at a distance" makes programming more fun

Unfortunately, your language (has/lacks):
[?] comprehensible syntax  [?] semicolons  [ ] significant whitespace  [ ] macros
[ ] implicit type conversion  [X] explicit casting  [ ] type inference
[X] goto  [?] exceptions  [X] closures  [?] tail recursion  [ ] coroutines
[ ] reflection  [X] subtyping  [X] multiple inheritance  [X] operator overloading
[?] algebraic datatypes  [?] recursive types  [X] polymorphic types
[?] covariant array typing  [?] monads  [?] dependent types
[?] infix operators  [ ] nested comments  [X] multi-line strings  [X] regexes
[X] call-by-value  [ ] call-by-name  [X] call-by-reference  [ ] call-cc

The following philosophical objections apply:
[?] Programmers should not need to understand category theory to write "Hello, World!"
[?] Programmers should not develop RSI from writing "Hello, World!"
[?] The most significant program written in your language is its own compiler
[ ] The most significant program written in your language isn't even its own compiler
[?] No language spec
[ ] "The implementation is the spec"
   [ ] The implementation is closed-source  [ ] covered by patents  [ ] not owned by you
[?] Your type system is unsound  [?] Your language cannot be unambiguously parsed
   [ ] a proof of same is attached
   [ ] invoking this proof crashes the compiler
[ ] The name of your language makes it impossible to find on Google
[ ] Interpreted languages will never be as fast as C
[ ] Compiled languages will never be "extensible"
[ ] Writing a compiler that understands English is AI-complete
[ ] Your language relies on an optimization which has never been shown possible
[ ] There are less than 100 programmers on Earth smart enough to use your language
[ ] ____________________________ takes exponential time
[?] ____________________________ is known to be undecidable

Your implementation has the following flaws:
[ ] CPUs do not work that way
[ ] RAM does not work that way
[ ] VMs do not work that way
[ ] Compilers do not work that way
[ ] Compilers cannot work that way
[ ] Shift-reduce conflicts in parsing seem to be resolved using rand()
[ ] You require the compiler to be present at runtime
[ ] You require the language runtime to be present at compile-time
[ ] Your compiler errors are completely inscrutable
[X] Dangerous behavior is only a warning
[ ] The compiler crashes if you look at it funny
[ ] The VM crashes if you look at it funny
[ ] You don't seem to understand basic optimization techniques
[ ] You don't seem to understand basic systems programming
[ ] You don't seem to understand pointers
[ ] You don't seem to understand functions

Additionally, your marketing has the following problems:
[ ] Unsupported claims of increased productivity
[ ] Unsupported claims of greater "ease of use"
[ ] Obviously rigged benchmarks
   [ ] Graphics, simulation, or crypto benchmarks where your code just calls
       handwritten assembly through your FFI
   [ ] String-processing benchmarks where you just call PCRE
   [ ] Matrix-math benchmarks where you just call BLAS
[ ] Noone really believes that your language is faster than:
    [ ] assembly  [ ] C  [ ] FORTRAN  [ ] Java  [ ] Ruby  [ ] Prolog
[ ] Rejection of orthodox programming-language theory without justification
[ ] Rejection of orthodox systems programming without justification
[ ] Rejection of orthodox algorithmic theory without justification
[ ] Rejection of basic computer science without justification

Taking the wider ecosystem into account, I would like to note that:
[ ] Your complex sample code would be one line in: _______________________
[X] We already have an unsafe imperative language
[ ] We already have a safe imperative OO language
[ ] We already have a safe statically-typed eager functional language
[ ] You have reinvented Lisp but worse
[ ] You have reinvented Javascript but worse
[ ] You have reinvented Java but worse
[?] You have reinvented C++ but worse
[ ] You have reinvented PHP but worse
[ ] You have reinvented PHP better, but that's still no justification
[ ] You have reinvented Brainfuck but non-ironically

In conclusion, this is what I think of you:
[?] You have some interesting ideas, but this won't fly.
[?] This is a bad language, and you should feel bad for inventing it.
[?] Programming in this language is an adequate punishment for inventing it.
Posted in Programming | Leave a comment


I’ve neglected writing about EoM for a while, and it’s really because progress on EoM has slowed. I’ve been trying to get back into it, but it’s hard for a few reasons:

  1. Large portions need to be refactored.
  2. I’m using 64-bit Linux now. It’s a pain setting up makefiles and rewriting parts to make it work. This ties in with 1.
  3. Working on PTL and Peped: two things which EoM is going to use.
  4. I’ve lost motivation. The interesting thing about this is that I still am highly interested in EoM, I just have so much else I need to do that it’s unsettling.
So here’s what I’m going to say:
Don’t put faith in EoM, but don’t lose it either.
I’m going to try and post more on this blog, I apologize for not writing much!
Posted in Uncategorized | 6 Comments