Implement all of the tools required for, and then itself, a macro which converts a stream of infix functions and other expressions into the relevant sexprs. This would primarily be useful for implementing other parsers and their behavior.
Needs to support operator precedence. This will require some sort of multi-method interface to access probably.
Cool Features
Support literate programming interfaces through type checking and specificity, bonus points if the types can be encoded into the multimethods themselves. Consider the classic programming mistake: x = 5 or 8, classically this would resolve into (or (= x 5) (truth 8)) (depending on how the system organizes the truthiness of integers, e.g. whether or implicitly converts them with truth, because of abstract tags for example, whether the macro adds truth (as is the case here), or some other code path). It would be cool if this macro would prefer (or (= x 5) (= x 8)) through some sort of operator precedence system (e.g. where explicit truth conversion is ordered below repetition of the previous condition for "similar" types).
Implement all of the tools required for, and then itself, a macro which converts a stream of infix functions and other expressions into the relevant sexprs. This would primarily be useful for implementing other parsers and their behavior.
Core Features
Basically:
(2 + 3) * 4 + func (8)
into:(+ (* (+ 2 3) 4) (func 8))
Needs to support operator precedence. This will require some sort of multi-method interface to access probably.
Cool Features
Support literate programming interfaces through type checking and specificity, bonus points if the types can be encoded into the multimethods themselves. Consider the classic programming mistake:
x = 5 or 8
, classically this would resolve into(or (= x 5) (truth 8))
(depending on how the system organizes the truthiness of integers, e.g. whetheror
implicitly converts them withtruth
, because of abstract tags for example, whether the macro addstruth
(as is the case here), or some other code path). It would be cool if this macro would prefer(or (= x 5) (= x 8))
through some sort of operator precedence system (e.g. where explicit truth conversion is ordered below repetition of the previous condition for "similar" types).