I wonder whether it would really have much of a performance advantage. Usually
expressions are nested, and so an Expr{:headA} contains among its args an
Expr{:headB}. But you don't know until runtime what type it is, so runtime
lookup would have to be faster than
isa(arg, Expr) && (arg::Expr).head == :headB ...`
I don't actually know, but I would be a bit surprised if it would help that
much.
Before someone thinks about tackling this, it would make sense to mock it up;
make a MyExpr{:headsym}, nest a bunch of them based on real expressions, and
then see if you get any real benefit from having the head as a type parameter.
The other negative is it would add to compilation time---currently one version
of a function handles all expressions, but with this change you'd have to
compile a version for each parametric expression type. That means yet slower
startup of any packages that do expression-parsing, and startup speed is
already a pretty big problem.
--Tim
On Saturday, September 13, 2014 01:17:00 PM Kevin Squire wrote:
> While this would greatly affect Match.jl, it would be a very welcome change!
>
> Cheers,
> Kevin
>
> On Saturday, September 13, 2014, Leah Hanson <[email protected]> wrote:
> > 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 <[email protected]
> >
> > <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 <[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).
