Surely not in any lasting sense? With a.b syntax overloading we could actually make the transition pretty smooth.
> On Sep 13, 2014, at 4:47 PM, Tony Fong <[email protected]> wrote: > > That'd be bad news for Lint... > >> On Saturday, September 13, 2014 3:22:04 PM UTC+7, Stefan Karpinski wrote: >> We've actually discussed changing our expression representation to use types >> instead of the more lisp-like symbols for distinguishing expression types. >> That would allow dispatch on expression types and be more compact. It would, >> however, break almost all macros that do any kind of expression inspection. >> >>> On Sat, Sep 13, 2014 at 2:48 AM, Gray Calhoun <[email protected]> wrote: >>>> On Wednesday, September 10, 2014 11:50:44 AM UTC-5, Steven G. Johnson >>>> wrote: >>>>> On Wednesday, September 10, 2014 12:20:59 PM UTC-4, Gray Calhoun wrote: >>>>> Are there better ways to do this in general? >>>> >>>> For this kind of expression-matching code, you may find the Match.jl >>>> package handy (https://github.com/kmsquire/Match.jl), to get ML- or >>>> Scala-like symbolic pattern-matching. >>> >>> >>> Thanks, that's pretty cool. For simple cases like I'm using, do you know if >>> there are advantages (or disadvantages) to using Match.jl, or should I just >>> view it as a nicer syntax? (Obviously, when things get more complicated >>> Match.jl looks very appealing). >>
