| Cool! Something I wish project docs would always include is …why… and what. Why does fe exist? Why did the orignal author spend a span of 6mo on it? What can it do and what can't it do? Don't make people read between the lines. It can be just to learn and have fun! But please don't make me read between the lines. The overview is interesting: * Supports numbers, symbols, strings, pairs, lambdas, macros * Lexically scoped variables, closures * Small memory usage within a fixed-sized memory region — no mallocs * Simple mark and sweep garbage collector * Easy to use C API * Portable ANSI C — works on 32 and 64bit * Concise — less than 800 sloc Since I work in embedded Linux systems I always like looking at small languages, using Lua at the moment. So it struck my interest, oooh this is interesting. The single fixed allocation is interesting, and odd. It then has gc...so why On the not just use malloc the manage the pool? I wonder if the performance is that much better? But beyond print there's no IO library, so I guess it's a "toy" language, maybe somewhere to learn a lisp flavor? |
Reply to one of the GitHub issues discusses it some[1].
>> What was the motivation to create fe if you already made aria?
> The same motivations I had writing aria: for the fun of programming it; trying to make something terse but still practical. Every line of code has a weight to it with consideration that would be unreasonable outside this kind of project: a project that exists just to exist. Each time you write something it becomes — or at least should become — more clear and more concise than the previous time, and if you repeat this, the original version is by comparison an over-engineered bloated mess. fe is a sequel to aria, and as such ended up smaller, simpler and faster
[1]: https://github.com/rxi/fe/issues/3