Do we actually need the mzscheme dependency? Any reason we couldn't switch to a full racket base?
---
Interesting. I'll have to play around with that. And study it a bit more to figure out how it works. If I understand your description correctly, the reason you're using lists is so that 'nil is interpreted as no value, while '(nil) is interpreted as intentionally passing the value 'nil? How does the function know the difference?
---
Interesting opinion. Unless I misunderstood you, I would have felt the opposite way. Normally, I would expect the purpose of the data interaction layer to be separating the implementation details from the code, so that if changes need to be made to what backend storage system you can just trade it out.
Maybe that is what you mean though, and that's supposed to be a distinction between the "driver" and an additional abstraction layer. Though your comment about ORMs including sugar confuses that a bit. I don't really want sugar per se, just abstraction away from how I'm actually storing the data, within reason anyway.
"Do we actually need the mzscheme dependency? Any reason we couldn't switch to a full racket base?"
There's always a reason, but these days Anarki has broke all my code enough times that that shouldn't be a concern. :)
I think this would be a positive change.
---
"...the reason you're using lists is so that 'nil is interpreted as no value, while '(nil) is interpreted as intentionally passing the value 'nil? How does the function know the difference?"
Arc doesn't support nil as an element of a table. Setting a table entry to nil removes it. Therefore '$kw-apply will only see non-nil values anyway.
As pg says: "In situations where the values you're storing might be nil, you just enclose all the values in lists." http://arclanguage.org/item?id=493
When I was using Arc heavily, I defined a utility (sobj ...) that was just like (obj ...) but it wrapped everything in a singleton list. That may have been the only extra utility I needed.
I could write (each (k (v)) tab ...) in place of (each (k v) tab ...). I could write tab!key.0 in place of tab!key. I could write (iflet (v) tab!key ...) in place of (iflet v tab!key ...).
It was surprisingly unintrusive, even pleasant.
---
"Normally, I would expect the purpose of the data interaction layer to be separating the implementation details from the code, so that if changes need to be made to what backend storage system you can just trade it out."
I like the sound of that, but I think it's always a bit leaky, unless the result is a full database design that lets people happily forget there's another database underneath.
