I think the other part is historical and an artifact of backwards compatibility.
FWIW, I think the srcloc struct should be transparent or perhaps even a prefab, which would negate the benefit below. Robby On Wed, Sep 14, 2011 at 1:31 PM, Danny Yoo <d...@cs.wpi.edu> wrote: > I wanted to double check my understanding on why source locations have > several representations in Racket. > > One of them is the srcloc structure: > http://docs.racket-lang.org/reference/exns.html#(def._((lib._racket/private/base..rkt)._srcloc)) > > But there's also the list and vector representations, all which are > handled by the syntax/srcloc library in > http://docs.racket-lang.org/syntax/Source_Locations.html#(def._((lib._syntax/srcloc..rkt)._source-location~3f)) > > When I first saw the multitude of representations, I was surprised and > confused: I expected there to be one canonical representation. > > > I made sense of this to myself with the following reasoning: it's > easier to serialize a vector or list than it is a struct. In many > cases, I want to embed source locations somewhere into the output of a > macro, and it's a lot easier to do something like this: > > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > #lang racket > (define-syntax (where stx) > (syntax-case stx () > [(_) > (with-syntax ([loc (vector (syntax-source stx) > (syntax-line stx) > (syntax-column stx) > (syntax-position stx) > (syntax-span stx))]) > #'loc)])) > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > > than it is to do the equivalent with a srcloc structure: > > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > #lang racket > (define-syntax (where-2 stx) > (syntax-case stx () > [(_) > (with-syntax ([sloc #`(srcloc '#,(syntax-source stx) > '#,(syntax-line stx) > '#,(syntax-column stx) > '#,(syntax-position stx) > '#,(syntax-span stx))]) > #'sloc)])) > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > > There's several more requirements that the struct approach needs, from > the use of the module and macro system to be able to bind "srcloc" > hygienically, to remembering to quote all the internal arguments. So > it seems the vector approach is more lightweight. > > > That doesn't quite explain to me why there are both list and vector > representations for srcloc, though... In any event, it's something > that's been bothering me, because it's not obvious why there are so > many representations. > _________________________________________________ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/users > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users