Line number info missing from #lang htdp

[mikesperber]

Consider this BSL program:

(: foo (Integer -> Integer))

(define (foo n)
  (+ n 1))

(: bar (Integer -> Integer))

(define (bar n)
   n)

(bar "bar")

Running it in the menu-based "Beginning student" language gives line number info for the signature violation. Not so #lang htdp/bsl.

The reason is this code in the menu-based languages:

htdp/htdp-lib/lang/htdp-langs.rkt

Line 907 in 7877cc2

(define (with-mark source-stx expr phase)

(I don't know how to do the same for #lang.)

[rfindler]

The code that you link to here is the code that fills in the imports to the menu-based teaching-languages use of errortrace. There is a similar piece of code in DrRacket's implementation of the "debugging" radio button and yet another one that kicks in when you use errortrace just via the racket command-line, e.g., racket -l errortrace -t myfilename.rkt. These are just how each particular way that the debugging instrumentation is instantiated. So I think we'll probably need a more holistic take on what isn't desirable here.

So, stepping back, there are three different ways to run this program that gives some amount of source-location reporting, so I'll list them out and you can tell me which one is important (or if I'm missing one) and what's wrong with it?

Mode 1: Running inside DrRacket, using "The Racket Language" option in the language dialog with the debugging enabled (ie the default settings), then I see:

Welcome to DrRacket, version 9.1.0.5-2026-02-07-0558a76e0a [cs].
Language: htdp/bsl, with debugging; memory limit: 256 MB.
"bar"
This program must be tested!
1 signature violation.

Signature violations:
        got "bar", signature in tmp1.rkt, line 8, column 8
> 

Mode 2: The Beginning Student language via the language dialog. In that case, I see this in the interactions window:

Welcome to DrRacket, version 9.1.0.5-2026-02-07-0558a76e0a [cs].
Language: Beginning Student; memory limit: 256 MB.
"bar"
> 

and this in the testing window

This program must be tested!
1 signature violation.

Signature violations:
        got "bar" in tmp1.rkt, line 11, column 0, signature in tmp1.rkt, line 6, column 8

Mode 3: At the command line, back in the #lang version of the file but with errortrace instrumentation turned on:

$  racket -l errortrace -t ~/tmp1.rkt
got "bar"
  errortrace...:
   /Users/robby/tmp1.rkt:13:0: (bar "bar")
   /Users/robby/git/plt/extra-pkgs/htdp/htdp-lib/lang/private/teach-module-begin.rkt:28:9: #%module-begin
  context...:
   /Users/robby/git/plt/racket/share/pkgs/deinprogramm-signature/deinprogramm/signature/signature.rkt:99:3
   /Users/robby/git/plt/racket/share/pkgs/deinprogramm-signature/deinprogramm/signature/signature-unit.rkt:104:3
   .../private/map.rkt:54:19: loop
   /Users/robby/git/plt/racket/share/pkgs/deinprogramm-signature/deinprogramm/signature/signature-unit.rkt:412:13
   body of "/Users/robby/tmp1.rkt"
☕ [robby@tainan] ~/git/exp/plt
$  

[rfindler]

After some discussion with Mike, the issue seems to be that the signature macros can get access to the errortrace annotation information in the menu-based teaching languages, but not in the #lang-based ones. I'm skeptical of following that same approach for the #lang-based teaching languages and suggested that maybe the signature-related macros could pick up some relevant source locations. Not sure if this is a good way forward or not yet, but that's the current state of the discussion.

[rfindler]

Here's some example code, illustrating the technique I have in mind. This idea could also be done with the #%app where the source location is grabbed in that macro but maybe this way is better, since I guess that few folks will actually use the function in a higher-order position, typically preferring to either call the function directly or write (lambda (x) (f x)) instead of just f.

#lang racket
(require (for-syntax syntax/parse)
         syntax/location)

(define (check-arg function-name arg srcloc)
  (unless (integer? arg)
    (eprintf "expected an integer, got ~e at ~a\n"
             arg
             (or (srcloc->string srcloc) "unknown srcloc"))))

(define-syntax (define/int stx)
  (syntax-parse stx
    [(_ (f:id x:id) e:expr)
     #'(begin
         (define (secret-f x srcloc) (check-arg 'f x srcloc) e)
         (define-syntax (f stx)
           (syntax-parse stx
             [x:id #`(λ (x) (secret-f x (quote-srcloc #,stx)))]
             [(_ arg)
              #`(secret-f arg (quote-srcloc #,stx))])))]))

(define/int (f x)
  x)

(f 1)
(f "one")
(define g f)
(g "two")

[mikesperber]

@rfindler and discussed using continuation-mark-set->context to obtain a stack trace, and from there to obtain the location of the signature violation. Unfortunately, that has no location information from the source, only this:

(|body of "/Users/sperber/Desktop/lineno.rkt"| . #false)

[rfindler]

In general, it will have some amount of information but often not much. Probably that code needs to be kept as a fallback somehow and we should add something to errortrace with an api similar to continuation-mark-set->context but that responds with errortrace's information (when it is present).

If you wanted examples where continuation-mark-set->context has more information then make the violation occur inside the body of a function. Here's some example code where you get something, maybe not something especially useful, but at least something.

#lang racket
(define (f x)
  (cond
    [(zero? x)
     (define stuff
       (continuation-mark-set->context
        (current-continuation-marks)))
     (printf "~s\n" (and (pair? stuff) (car stuff)))]
    [else (f (- x 1))]))

(f 10)

[rfindler]

I'm not yet confident of them, but they seem enough to be able to experiment with for the purposes here. Give these two pull requests a try, maybe? racket/errortrace#38 and racket/drracket#804