Vacietis

Heck, I'm not convinced that this is a better idea than Common Lisp readtable[1], and I think Racket's #lang is more ergonomic than the CL readtable. 1: Which is powerful enough to implement a C compiler in: https://github.com/vsedach/Vacietis

Project name: Vacietis URL: https://github.com/vsedach/Vacietis Programming language used for the compiler: Common Lisp Compiles to: Common Lisp

> Why is this a worst case for Haskell? You generally don't want a garbage collector in the core request-dispatch loop, and Haskell's lazy evaluation makes it really easy to accidentally write code that can't be compiled to efficient output. It's not impossible to write a high-performance HTTP server in Haskell[0], but the skill requirement is much higher than in C++, Rust, or Go[1]. > is the average LISP developer anymore likely to make a non industrial > code base than a Rust developer? Yes. Not because of the developer, but because of how extremely flexible and dynamic the Lisp-family languages are. The power and joy of Lisp is in how it's almost a meta-language, so every project can become its own EDSL. The most famous (infamous?) example of this is Vacietis[2], which is a Common Lisp library that allows C code to be imported di

How about C? https://news.ycombinator.com/item?id=25531871 https://github.com/vsedach/Vacietis ================ Vacietis is a C compiler for Common Lisp systems. Vacietis works by loading C code into a Common Lisp runtime as though it were Lisp code, where it can then be compiled or evaled. The loaded C code has the same function calling convention as regular CL code and uses the same numerical representations. C memory is backed by regular Common Lisp arrays. Vacietis comes with a libc implemented in portable Common Lisp.

The Common Lisp specification has the entire reader algorithm laid out[1]. It fits on a single page, and it's really easy to understand. Note, however, that there is heavy lifting done by the default read-table (the CL reader is table-based and is dynamically modifiable[2]), so you will only be able to read tokens if you implement what is on that page. However, the most common characters are nearly trivial to implement: #\( #\" #\' as well as the most common dispatch characters for #\# 1: http://www.lispworks.com/documentation/HyperSpec/Body/02_b.h... 2: Someone modified the lisp reader to be able to read in valid C89 code, and implemented a backend to compile that to common-lisp: https://github.com/vsedach/Vacietis

Here's a real-word C compiler where the sizeof() everything is 1; https://github.com/vsedach/Vacietis For another example, the LLVM webassembly backend doesn't put the call stack in the same address space as the heap at all.

> You cannot parse it properly without symbol table. No context free parser handles C properly, let alone C++. It gets progressively and exponentially worse from here. C is actually pretty easy if you ignore all of the bad advice to use parser generators. I looked into the various YACC grammars for C I could find on the Internet, and all of them either had bugs or were incomplete. TCC[1] has a simple recursive-descent parser. With a recursive descent parser you also have the option of implementing the C pre-processor in the same step. Turns out I was able to implement a single-pass C parser and pre-processor as a bunch of Common Lisp read macros[2]. I have not looked into it, but the approach for C++ looks like it would be very different because template instantiation needs its own step. [1] https://bellard.org/tcc/ [2] https://github.com

> One of the few valid use cases of "goto" today. Manually rewriting recursive algorithms is one of the least valid use case of GOTO. You need GOTO for low-level concurrency, IO multiplexing, and transpiling: https://github.com/vsedach/Eager-Future2/blob/master/future.... https://github.com/vsedach/Vacietis/blob/master/compiler/imp...

They are not that hairy. I did a recursive-descent one as a Common Lisp reader macro in less than 1k loc: https://github.com/vsedach/Vacietis/blob/master/compiler/rea... C is ok in that you can handle everything (including typedefs) in a single pass with only one character lookahead. This includes the preprocessor. Common Lisp has concatenated streams (http://www.lispworks.com/documentation/HyperSpec/Body/t_conc...) which made handling the preprocessor really easy, but tcc (https://bellard.org/tcc/) and I think pcc also do the preprocessing as part of the parser.

The Vacietis (https://github.com/vsedach/Vacietis/) reader can be easily adapted to do that. You can see examples in the unit tests: https://github.com/vsedach/Vacietis/blob/master/test/reader-... As-is, C block constructs get mapped directly to Common Lisp special forms like tagbody and prog because those implement a superset of C control flow semantics. Pick different names in vacietis.c and you have an AST.

Read macros are great because you can use them to turn the Common Lisp parser into a parser for any language you want (no restrictions on the grammar), so you essentially get compilers for free. I wrote a one-pass C preprocessor and parser in just under a thousand lines of code: https://github.com/vsedach/Vacietis/blob/master/compiler/rea...

Flex does not work fine, that's why you need the lexer hack: https://en.wikipedia.org/wiki/The_lexer_hack Non-working (no lexer hack) Flex and Bison specification for C99: https://gist.github.com/codebrainz/2933703 653 lines Hand-written recursive-descent C parser and pre-processor (something not handled by Lex/Yacc) that produces executable Common Lisp code: https://github.com/vsedach/Vacietis/blob/master/compiler/rea... 935 lines

This is an instance of a C to Lisp compiler that translates to s-expressions https://github.com/vsedach/Vacietis

Here's C in Common Lisp: https://github.com/vsedach/Vacietis#readme