No please don't mind me. I was just over-excited after pushing out a bunch of commits.
On Sunday, September 14, 2014 3:28:25 AM UTC+7, Stefan Karpinski wrote: > > 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] <javascript:>> > 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). >>> >> >>
