Get started with App.net.

  Sign up now  
jspahrsummers
    If I want to annotate Documentalist’s AST (http://git.io/pCmxuQ) with custom data, is an extra type parameter over each definition really the most efficient way to get there?
    There are 12 new posts
    jspahrsummers
      [Post deleted]
      jspahrsummers
        I’m using a Map outside of the type right now, but that seems less than ideal. For example, if I want to recursively `show` the AST, it doesn’t look like there’s an easy way to apply the annotations.
        jspahrsummers
          Likewise, I’d really like to able to create instances of Functor, Foldable, Traversable, etc. for the Declaration type, which seems to necessitate another type parameter. Threading that through may be a huge pain in the ass, though.
          tacticalgrace
            @jspahrsummers There is no one answer to this question. It depends how you use the attributes. Eg, what is their lifetime? Short? Then, a separate Map may be a good idea. Similar to the lifetime of the AST? Probably best to make them fields in AST nodes.
            tacticalgrace
              @jspahrsummers A lesson from GHC is that putting attributes into identifiers and parameterising ASTs over the type of binders (identifiers) gets you very far and scales well.
              tacticalgrace
                @jspahrsummers I'm not sure why you are worried about adding type parameters. That usually only affects type signatures and is not an invasive change.
                tacticalgrace
                  @jspahrsummers Another option is to define a “pre” type, which has recursive occurrences replaced by a type parameter and to tie that with varying knots. We use that in Accelerate: http://bit.ly/13YWbek (PreAcc is the open AST type.)
                  jspahrsummers
                    @tacticalgrace I wanted to avoid type parameters on _everything_ in a Declaration, but I don’t know why I thought that might be needed in the first place. Besides that, it seemed like a little bit of a hack.
                    jspahrsummers
                      @tacticalgrace I like what @maxpow4h proposed here — it makes a lot of sense to me: https://github.com/jspahrsummers/documentalist/commit/1cbf310039400405f3826ec527bb005c731a0615#L2R35 I don’t fully understand the PreAcc stuff. Where’s that type defined?
                      co_dan
                        @jspahrsummers you can try parametrizating your type over an arbitrary functor in the recursive subterm. So `Class Identifier SuperTypes [Declaration] ` becomes `Class Identifier SuperTypes (f Declaration)`
                        jspahrsummers
                          @co_dan What’s the advantage of that?
                          co_dan
                            @jspahrsummers you can replace it with arbitrary Functor that would contain your attributes. It's very similar to what @tacticalgrace has proposed actually
                            jspahrsummers
                              @tacticalgrace @maxpow4h Hmm, interesting. Make sense, though I like the separation of nodes/leaves in the other version. What are the advantages of a recursive functor?
                              tacticalgrace
                                @jspahrsummers The separation of nodes/leaves is an orthogonal aspect. The advantage of the functorial notation is that you can extend the data type with both attributes and new AST nodes. Very flexible. + @maxpow4h
                                maxpow4h
                                  @tacticalgrace I tried this instead: https://github.com/jspahrsummers/documentalist/pull/24/files Yeah I see its not as flexible. But it is simple :) + @jspahrsummers
                                  tacticalgrace
                                    @maxpow4h Sure. I was just outlining possible approaches. + @jspahrsummers
                                    co_dan
                                      @jspahrsummers @tacticalgrace @maxpow4h I don't understand the solution you used. You are still adding a type variable, right?
                                      jspahrsummers
                                        @co_dan @maxpow4h Yeah, I just liked the split of nodes and leaves, though @tacticalgrace has correctly pointed out that aspect is orthogonal to the issue of adding a type variable/using a recursive functor.