Hirrolot

15 ms·

121.
by Hirrolot 5y ago
I learnt it from "Type Theory and Formal Proof" when I wanted to understand type theory (I was in a community of functional programmers). BTW, nice book, I always recommend it to absolute beginners.
122.
by Hirrolot 5y ago
This was not sarcastic; I've explained in more detail in my blog post: https://hirrolot.github.io/posts/macros-on-steroids-or-how-c... . The linked code uses other macros too, that's right, since it's wri
123.
by Hirrolot 5y ago
Yeah, the macro-based lambda calculus is pretty slow, since it's essentially an interpreter upon interpreter upon interpreter! The first one is preprocessor, which executes Metalang99, which executes the final calculus.
124.
A λ-calculus interpreter written in C preprocessor macros(github.com)
85 points by Hirrolot 5y ago|9 comments
125.
What’s the Point of the C Preprocessor, Actually?(hirrolot.github.io)
3 points by Hirrolot 5y ago|0 comments
126.
by Hirrolot 5y ago
I don't think the suggested metaprograms in the blog post don't look like C, in opposite [1]. [1]: https://hirrolot.github.io/posts/extend-your-language-dont-a...
127.
by Hirrolot 5y ago
That's cool, looking forward to any feedback when you're done.
128.
by Hirrolot 5y ago
> Native macros were never supposed to be used that way. If anything goes wrong, you still have to deal with that, and no IDE will save you from having to invoke your compiler with “preprocess-only” flag to see what you’re dealing with.
129.
by Hirrolot 5y ago
If we are talking about such abstractions as Datatype99, this model is less convenient than native macros [1]. You have to write code in separate files, IDE support is lacking, sophisticating a build procedure, etc etc. [1]: https:/&#
130.
by Hirrolot 5y ago
> The c preprocessor replaces something by something else and the process is completely opaque. If you have multiple layers of macros, codes becomes impossible to follow, isolate and understand with a debugger or a profiler. It's no
131.
by Hirrolot 5y ago
I'd wager no, as long as you remain sane and do not pollute everything with fancy macro eDSLs. Specifically Datatype99 & Interface99 can be good for newcomers because they make code more concise, less intimidating and intricate.
132.
by Hirrolot 5y ago
If you're asking about debugging macros, I've put a huge effort to this [1]. There are several macros that help you test, debug, and report errors at compile-time. For example, you can make calls to ML99_abort and see the expansio
133.
by Hirrolot 5y ago
There are several reasons why not to resort to third-party code generators [1]. This includes the burden of maintenance (think about the build process) and seamless integration of native macros with other code. Do you have some code to show
134.
by Hirrolot 5y ago
Zig is an interesting alternative to C. libcello has quite different philosophy than Metalang99 and the accompanying libraries like Datatype99. The thing is that the former comes with its own runtime environment, but the latter ones even do
135.
by Hirrolot 5y ago
C++ can, fair. Still there is a huge amount of developers sticking to plain C, even if they can use C++ (FFmpeg, VLC, Linux, etc.), why do they do that? I think an answer to this question would be pretty much the answer for the initial ques
136.
by Hirrolot 5y ago
See this comments branch: https://news.ycombinator.com/item?id=27921095 .
137.
by Hirrolot 5y ago
I'm currently using Datatype99 & Interface99 at work. What can I say? Everything goes well, nothing critical has appeared soon, my coworkers are able to understand the code. Regarding macro-based eDSLs, I would not resort to them f
138.
by Hirrolot 5y ago
Only if you can switch to something like Zig, Rust, etc. But a tremendous amount of code bases are already written in plain C. Using preprocessor metaprogramming allows you to invoke macros right in the same files in which you write ordinar
139.
by Hirrolot 5y ago
> IMO people should prefer boost::preprocessor for purposes like this (even in pure C), since it is battle-tested and more polished than "little" metaprogramming libraries will likely ever be. In fact, I used to program in boos
140.
Metalang99: Full-blown preprocessor metaprogramming for pure C(github.com)
2 points by Hirrolot 6y ago|0 comments
141.
by Hirrolot 6y ago
Yesterday I announced datatype99 [1], today I announce Metalang99 -- a framework upon which datatype99 is built (initially published under a different name, though I changed it to more neutral). [1]: https://news.ycombinator.com&
142.
Metalang99: A functional language for C99 preprocessor metaprogramming(github.com)
2 points by Hirrolot 6y ago|1 comments
143.
by Hirrolot 6y ago
The reason why I created this project is that I miss sum types in C all the time, literally everywhere I need a custom error type or just any other alternative data representation. And I do think the implementation of datatype99 is straight
144.
by Hirrolot 6y ago
We can generate a type ID by defining an extern variable of a sum type inside the `datatype` macro. Its address then will be a type ID (though I am not sure that such two variables will always have different addresses, I need to check the s
145.
by Hirrolot 6y ago
Yeah, actually the most missing thing in C is sum types, as for me. Poica was rather an experiment; datatype99 is rather a practical library. I'm planning to use it on my work.
146.
by Hirrolot 6y ago
datatype99 generates a switch expression under the hood, and modern compilers check this switch expression for exhaustiveness.
147.
by Hirrolot 6y ago
Something similar, yes. Behind the scenes, datatype99 deduces a type of a matched expression using the typedefs generated earlier.
148.
by Hirrolot 6y ago
Yes, just write otherwise { ... } to handle a default case.
149.
by Hirrolot 6y ago
Hmm, I don't use Zig so can't say much about it.
150.
by Hirrolot 6y ago
Well, mostly I use idioms from the Cloak Wiki ( https://github.com/pfultz2/Cloak/wiki/C-Preprocessor-tricks,... ). It takes some time to realise them :)

More ›