4 ms·

Just as a fun fact, in Common Lisp, any function you write and any data structure you define can be executed trivially at compile time.

traes 6y ago
That's... most lisps, isn't it?
tetris11 6y ago
Forgive my denseness, but I can see why it would make sense for a defconst or even a defvar to be evaluated at compile time, but why a function?
- klysm 6y ago
  suppose you have a bunch of logic in a particular domain that’s noisy to write and read because of a lot of boiler plate. The ability to execute arbitrary code at compile time enables you to easily create pretty much arbitrary abstractions/DSLs to make this more readable and writable. This certainly comes at a cost though, and if you abuse it too much it becomes very hard to reason about programs.
- Doxin 6y ago
  So I'm not a lisp programmer, but the concept of compile-time function evaluation is pretty programming language agnostic, so allow me to give some examples of what you can use it for in D: In D it's generally used for compile-time code generation. The regex module in the stdlib for example can compile regexes to bytecode along with the rest of your program, obviating the need for having a regex cache or for compiling regexes on the fly. Of course it can also be used for... less useful stuff. I still think everyone should at some point try writing a compile-time brainfuck compiler in D[0]. A couple dozen lines of fairly simple code and suddenly you can use brainfuck as a DSL in your D program. You get a compiler backend with optimization for free. As another example of a useful application might be reading and parsing a config file. That way you can quite easily configure a complex "custom" compilation without resorting to complex makefiles and whatnot. Which leads me into another neat one: compile-time parser generation. Pegged.d can generate and compile a lexer/parser for any PEG grammar you like. Again it gets compiled at compile time and linked into your program seamlessly. Which is incredibly convenient for e.g. parsing config files and whatnot at compile time. You might even get all fancy and parse a graphql schema or SOAP wsdl file or what have you and automatically generate an API interface at compile time. The advantage here being that e.g. calling an API function that doesn't exist or with the wrong argument types leads to a compile-time error instead of a run-time error! So in general compile time function evaluation is really useful for moving work from run-time to compile-time. The above examples are mostly code generation -- which I imagine is less of a thing in lisp due to macros -- but it can be used for any computation that can be done at compile time. It's basically constant folding[1] on steroids. I could go on giving examples since compile time function evaluation is so wildly widely applicable, the sky is the limit really. [0] it really is surprisingly easy given the mixin function D provides. Just translate the brainfuck code to D code and mixin() it to get it all compiled in to the final program. [1] https://en.wikipedia.org/wiki/Constant_folding https://en.wikipedia.org/wiki/Constant_folding

traes 6y ago

That's... most lisps, isn't it?

tetris11 6y ago

Forgive my denseness, but I can see why it would make sense for a defconst or even a defvar to be evaluated at compile time, but why a function?

klysm 6y ago
suppose you have a bunch of logic in a particular domain that’s noisy to write and read because of a lot of boiler plate. The ability to execute arbitrary code at compile time enables you to easily create pretty much arbitrary abstractions/DSLs to make this more readable and writable. This certainly comes at a cost though, and if you abuse it too much it becomes very hard to reason about programs.
Doxin 6y ago
So I'm not a lisp programmer, but the concept of compile-time function evaluation is pretty programming language agnostic, so allow me to give some examples of what you can use it for in D: In D it's generally used for compile-time code generation. The regex module in the stdlib for example can compile regexes to bytecode along with the rest of your program, obviating the need for having a regex cache or for compiling regexes on the fly. Of course it can also be used for... less useful stuff. I still think everyone should at some point try writing a compile-time brainfuck compiler in D[0]. A couple dozen lines of fairly simple code and suddenly you can use brainfuck as a DSL in your D program. You get a compiler backend with optimization for free. As another example of a useful application might be reading and parsing a config file. That way you can quite easily configure a complex "custom" compilation without resorting to complex makefiles and whatnot. Which leads me into another neat one: compile-time parser generation. Pegged.d can generate and compile a lexer/parser for any PEG grammar you like. Again it gets compiled at compile time and linked into your program seamlessly. Which is incredibly convenient for e.g. parsing config files and whatnot at compile time. You might even get all fancy and parse a graphql schema or SOAP wsdl file or what have you and automatically generate an API interface at compile time. The advantage here being that e.g. calling an API function that doesn't exist or with the wrong argument types leads to a compile-time error instead of a run-time error! So in general compile time function evaluation is really useful for moving work from run-time to compile-time. The above examples are mostly code generation -- which I imagine is less of a thing in lisp due to macros -- but it can be used for any computation that can be done at compile time. It's basically constant folding[1] on steroids. I could go on giving examples since compile time function evaluation is so wildly widely applicable, the sky is the limit really. [0] it really is surprisingly easy given the mixin function D provides. Just translate the brainfuck code to D code and mixin() it to get it all compiled in to the final program. [1] https://en.wikipedia.org/wiki/Constant_folding https://en.wikipedia.org/wiki/Constant_folding