>
> 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.
>>
>
Hmm, interesting. I guess the Expr type would then be Expr{:head} with
getindex / setindex overloaded to manipulate the arguments? This would be
a nice change as for many nodes you would not have to allocate an args
array which could be a performance win (i guess the serialized ast's would
be more compact as well). Can't comment on whether it would be enough of a
win to justify such a massively breaking change.
> 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).
>>>
>>
>>
