I would expect the Expr type to be abstract, with different concrete
subtypes for each current value of head. Each value of head indicates a
specific structure in args, and this can just be reflected in the
definition of the subtypes. (Then you can dispatch on Expr type, use
"subtypes(Expr)" to see all possible kinds of Expr, etc.)
-- Leah
On Sat, Sep 13, 2014 at 10:47 AM, Jake Bolewski <jakebolew...@gmail.com>
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.
>>>
>>
> 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 <gcal...@iastate.edu>
>>> 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).
>>>>
>>>
>>>
