[CLJ-1706] top level conditional splicing ignores all but first element Created: 15/Apr/15 Updated: 24/Apr/15
|Affects Version/s:||Release 1.7|
|Fix Version/s:||Release 1.7|
I believe using a conditional splicing not inside a list should be a read-time exception like
|Comment by Alex Miller [ 15/Apr/15 2:05 PM ]|
pulling into 1.7 so we can discuss
|Comment by Alex Miller [ 24/Apr/15 11:18 AM ]|
Compiler.load() makes calls into LispReader.read() (static call). If the reader reads a top-level splicing conditional read form, that will read the entire form, then return the first spliced element. when LispReader.read() returns, the list carrying the other pending forms is lost.
I see two options:
1) Allow the compiler to call the LispReader with a mutable pendingForms list, basically maintaining that state across the static calls from outside the reader. makes the calling model more complicated and exposes the internal details of the pendingform stuff, but is probably the smaller change.
2) Enhance the LineNumberingPushbackReader in some way to remember the pending forms. This would probably allow us to remove the pending form stuff carried around throughout the LispReader and retain the existing (sensible) api. Much bigger change but probably better direction.
|Comment by Nicola Mometto [ 24/Apr/15 11:24 AM ]|
What about simply disallowing cond-splicing when top level?
|Comment by Alex Miller [ 24/Apr/15 11:42 AM ]|
We want to allow top-level cond-splicing.
|Comment by Nicola Mometto [ 24/Apr/15 11:52 AM ]|
Would automatically wrapping a top-level cond-splicing in a (do ..) form be out of the question?
I'm personally opposed to supporting this feature as it would change the contract of c.c/read, complicate the implementation of LineNumberingPushbackReader or LispReader and complicate significantly the implementaion of tools.reader's reader types, for no significant benefit.