[plt-scheme] Source location infromation and tracebacks (was: match-lambda and source location)

On Sun, Jan 4, 2009 at 7:34 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> At Sun, 04 Jan 2009 19:16:20 +0100, Jakub Piotr Cłapa wrote:
>> On 1/3/09 8:11 PM, Matthew Flatt wrote:
>> > At Sat, 03 Jan 2009 00:54:53 +0100, Jakub Piotr Cłapa wrote:
>> >> match-lambda creates a lambda without overriding syntax information.
>> >> This greatly reduces the information content in stack traces.
>> >>
>> >> OTOH overriding the source information for the lambda keyword greatly
>> >> reduces the clarity of the macro code...
>> >
>> > I don't understand what you mean. Can you provide an example, describe
>> > how it behaves, and describe how it should behave instead?
>>
>> Ok. I think I misinterpreted the problem since I last stumbled upon it.
>> Here is the test case:
>>
>> (define test-1
>>    (match-lambda
>>      [(list a b) #t]))
>>
>> (define (test-2 l)
>>    (match l
>>      [(list a b) #t]))
>>
>> Notice the difference in tracebacks between (test-1 #t) and (test-2 #t).
>> This is as far as I (now) understand related to source location
>> information of the match form.
>
> Ah, I see what you mean...
>
>> The problem with readability of the macros was in my own code:
>>
>> (define-syntax (on-notif stx)
>>    (syntax-case stx ()
>>      [(on-notif (notif arg ...)
>>         expr expr+ ...)
>>       (with-syntax ([fun (datum->syntax #'here
>>                                         (syntax-e #'(lambda (arg ...)
>>                                                       expr expr+ ...))
>>                                         #'on-notif)])
>>         #'(begin
>>             #;(** 'notif (list fun (notif-observers notif)))
>>             (notif-add-observer! notif fun)))]))
>
> The `syntax/loc' form makes this more readable:
>
>      (with-syntax ([fun (syntax/loc #'on-notif
>                           #'(lambda (arg ...) expr expr+ ...))])
>        #'(begin
>            (notif-add-observer! notif fun)))
>
>
> As another example, the `match-lambda' form could be implemented as
>
>     (define-syntax (match-lambda stx)
>       (syntax-case stx ()
>         [(k . clauses) (quasisyntax/loc stx
>                           (lambda (exp)
>                             #,(syntax/loc stx (match exp . clauses))))]))
>
> This would cause the stack trace for `(test-1 #t)' to give more
> information: it would show the `match-lambda' as a representative of
> the implicit `match' form. While that would give more information, it
> would look strange, because evaluating a `match-lambda' form doesn't
> actually evaluate its body. In other words, the `match-lambda' form
> isn't really a good representative for the macro-introduced `match'.

So what should I (as the maintainer of `match') do here?  It seems
like it might be better for Jakub just to get the additional
information, even if it looks weird.

Another possibility would be to give the generated `match' expression
the source locations for the body of the `match-lambda' (here
`clauses').  It's currently not convenient to do that, but I could do
it, and it might make more sense.

Thanks,
-- 
sam th
samth at ccs.neu.edu