-> and ->> have unexpected behavior when combined with unusual macros

Description

My intuitive understanding of the classic threading macros is that the meaning of forms like (-> a b c) can be understood syntactically independent of the meaning of the symbols involved or the fact that the two threading macros are defined recursively. However the recursive definition breaks that expectation. After

c is now in control if it is a macro, and is now seeing the argument (-> a b) rather than (b a) as would be the case if we had written (c (b a)) originally.

Admittedly I do not know of a realistic example where this is an important distinction (I noticed this when playing with a rather perverse use of ->> with macros from korma), but at the very least it means that the behavior of the threading macros isn't quite as easy to accurately explain as I thought it was.

Environment

None

Attachments

2

Activity

Show:

Tim McCormack [personal] January 10, 2013 at 12:47 AM

This patch also prevents an infinite loop in the macroexpander when fed the following expression:

Edit: Far simpler example.

gfredericks December 27, 2012 at 2:16 AM

New patch in response to stuarthalloway feedback.

Stuart Halloway December 22, 2012 at 3:48 PM

Would be nice if tests also demonstrated that metadata is preserved correctly.

gfredericks December 7, 2012 at 3:19 PM

I just realized that my patch also implements CLJ-1086.

Completed

Details

Assignee

Reporter

Approval

Ok

Patch

Code and Test

Priority

Affects versions

Fix versions

Created December 7, 2012 at 2:28 AM
Updated August 15, 2013 at 12:13 AM
Resolved August 15, 2013 at 12:13 AM