# Mal/Make-a-Lisp FAQ
+<a name="why_mal"></a>
+
### Why did you create mal/make-a-lisp?
### OR Why the name "mal"?
### OR Why?
implementation is now just a small part of the whole).
+<a name="code_split"></a>
+
### Why is some code split into steps and some code not?
The split between code that goes in steps and code that goes into other files
than the Lisp part, but that is due to the nature of the target
language not because of Lisp functionality per se).
+
+<a name="steps"></a>
+
### Why are the mal/make-a-lisp steps structured the way they are?
### OR Why is X functionality in step Y instead of step Z?
deferrable until later. But I am always open to suggestions.
+<a name="add_implementation"></a>
+
### Will you add my new implementation?
Absolutely! I want mal to have a idiomatic implementation in every
marked as optional and not needed for self-hosting.
* Your implementation should follow the existing mal steps and
- structure: Lisp-centric code in the step files, other code in
- reader, printer, env, and core files. I encourage you to create
- implementations that take mal in new directions for your own
- learning and experimentation, but for it to be included in the main
- repository I ask that it follows the steps and structure.
+ structure: Lisp-centric code (eval, eval_ast, quasiquote,
+ macroexpand) in the step files, other code in reader, printer, env,
+ and core files. See [code layout rationale](#code_split) above.
+ I encourage you to create implementations that take mal in new
+ directions for your own learning and experimentation, but for it to
+ be included in the main repository I ask that it follows the steps
+ and structure.
* Your implementation should stick as much as possible to the accepted
idioms and conventions in that language. Try to create an