> Q: If special syntax support for alists were added would a!k return a keyvalue pair (`assoc`) or just a value(`alref`)?
One option is to extend calling lists so that calling a list with a number would continue to do the same thing (return the item at that position), while calling a list with a non-number would treat the list as an association list and do a lookup on that key.
Then no special syntax is needed because the standard `alist!x` would work, as it expands into `(alist 'x)`.
Naturally, this means that you couldn't do a lookup in your alist with a number using the `!` syntax, but that might be OK for you if you aren't using numbers in keys in the alists that you want to use the `!` syntax with.
This option wouldn't return the alist value on an index access though, as it would continue to return the association pair.
Another option would be to create a new type (e.g. using `annotate`) and then have calling objects of that type do what you want (for example, in Anarki you could use `defcall`).
testible.clef means look up the value stored at what clef evaluates to in testible
testible!clef means look up the value stored at clef in testible
testable.0 means look up the value stored (at what 0 evaluates to) in testible
testible!0 means look up the value stored at 0 in testible
atist.0 means look up the value stored at what 0 evaluates to in atist
atist!0 means look up the value stored at 0 in atist
0 of course being an atom evaluates to 0
but what if you want it to evalute to something like the key stored at 0 . . .
. . . if quote means something like "don't evaluate" and unquote means something like "do evaluate" then one could reason that
atist,0 means look up the value stored at what 0 evaluates to (do evaluate it) in atist
! and . behave the same with alists and numbers while its inconvenient if you want to access the key it makes sense.
Is this reasonable?
Edit: this could work for alists and insertion-ordered tables since it's unobvious how testible!0 & testible.0 should behave, numbers can and should be able to be keys so one can imagine a situation where behavior would be like so:
"Immediate reaction: this is a bad idea. Commas mean something specific in Lisp. And having `0` mean different things in different contexts is a recipe for disaster.
"I prefer aw's proposal above. Support list indexing, support alist lookup, don't support alist lookup by integer keys. Not the end of the world, people can just use `alref` in that situation."
