[jackhill/mal.git] / chuck / notes.md

# Step 1

- What if I don't have an OOP language?
- types.qx could be more promently mentioned...
- A table with all types and suggested object names would be hugely
  useful
- Same for a list of all errors and their messages
- Mention return types and argument types consistently
- More on int/float and their grammar (int is mentioned implicitly in
  the ASCII art, nothing on signs or bases or their lack of)
- Note that a string must be parsed for the `print_readably` thing to
  work and mention how one could do that (like, by using a `read` or
  `eval`-like thing or alternatively, chopping off the surrounding
  quotes and doing the inverse transformation of the printing)
- How is an atom printed?

# Step 2

- What if my language doesn't support lambdas, let alone passing
  around named functions? Ideally write something about
  implementing/using functors/delegates or replacing that namespace
  with a big switch as with VHDL.  Another problem is that if you
  choose a different solution in step 4, step 2 could end up no longer
  functional...
- What kind of error (read: what message?) is raised when no value can
  be looked up for the symbol?  Is it arbitrary?  Do I need to extend
  my error handling to allow for format strings?
- It would be worth a mention that you should extend the printer to
  handle "native" functions (or in oldtimey terms, subrs)

# Step 3

- You should modify both eval_ast *and* EVAL
- Suggest the trick with destructuring the AST into `a0`, `a1`,
  etc. variables for easier access.  Perhaps this can be used to clear
  up the general language used with AST manipulation (like, first
  parameter and second list element)?
- What does def! return?  Emacs Lisp for instance returns the symbol
  whereas the tests suggest the value should be returned instead...
Commit	Line	Data
b12906e3 VS	1	# Step 1
	2
	3	- What if I don't have an OOP language?
	4	- types.qx could be more promently mentioned...
	5	- A table with all types and suggested object names would be hugely
	6	useful
	7	- Same for a list of all errors and their messages
	8	- Mention return types and argument types consistently
	9	- More on int/float and their grammar (int is mentioned implicitly in
	10	the ASCII art, nothing on signs or bases or their lack of)
	11	- Note that a string must be parsed for the `print_readably` thing to
	12	work and mention how one could do that (like, by using a `read` or
	13	`eval`-like thing or alternatively, chopping off the surrounding
	14	quotes and doing the inverse transformation of the printing)
	15	- How is an atom printed?
80a2a738 VS	16
	17	# Step 2
	18
	19	- What if my language doesn't support lambdas, let alone passing
	20	around named functions? Ideally write something about
	21	implementing/using functors/delegates or replacing that namespace
	22	with a big switch as with VHDL. Another problem is that if you
	23	choose a different solution in step 4, step 2 could end up no longer
	24	functional...
	25	- What kind of error (read: what message?) is raised when no value can
	26	be looked up for the symbol? Is it arbitrary? Do I need to extend
	27	my error handling to allow for format strings?
	28	- It would be worth a mention that you should extend the printer to
	29	handle "native" functions (or in oldtimey terms, subrs)
0c8b871a VS	30
	31	# Step 3
	32
	33	- You should modify both eval_ast and EVAL
	34	- Suggest the trick with destructuring the AST into `a0`, `a1`,
	35	etc. variables for easier access. Perhaps this can be used to clear
	36	up the general language used with AST manipulation (like, first
	37	parameter and second list element)?
	38	- What does def! return? Emacs Lisp for instance returns the symbol
	39	whereas the tests suggest the value should be returned instead...