Consider the following module (MWE of an issue that has bitten me a couple of times): #lang racket (bad-form #:do 'a #:do 'b) DrRacket (and racket I assume) report the following syntax error: application: duplicate keyword in application in: #:do However, notice that bad-form is itself an unbound identifier. So it could be that adding the correct require would solve the error because bad-form actually allows multiple occurrences of #:do.

Wouldn’t it make sense to report the error about the unbound id before reporting a possible wrong ‘application’?

I know why operationally it’s like that, but you are also right that it’s not ideal

The reason is that before bad-form errors as an unbound-id, it needs to insert the implicit #%top first, and that step is after inserting the implicit #%app.

See https://docs.racket-lang.org/reference/syntax-model.html#%28part._expand-steps%29

Thanks. But #%top isn’t responsible for the reported error I assume?

IIRC, no

Also there’s this note: Changed in version 6.3 of package base: Changed the introduction of #%top in a top-level context to unbound identifiers only.

Shouldn’t #%app be responsible for checking whether the id is bound before inferring anything about the form of the call?

@laurent.orseau: here’s the relevant code: https://github.com/racket/racket/blob/master/racket/src/expander/expand/main.rkt#L212

Thanks. Can’t make sense of it yet though :slightly_smiling_face:

@laurent.orseau #%app could do other things with unbound identifiers

I suppose so, but my question is why does it check things like duplicate keyword application when the id is unbound?

Or rather, I think that’s not ideal, and can probably be fixed. But if it takes too much energy or computation time, it may not be worth it

%app could have an error message that mentioned “maybe it’s because foo is unbound”

Yes, that would certainly help.

I think that would just be a change in the definition of #%app in racket/private/kw.rkt

This file doesn’t seem to know anything about unbound identifiers though

You would have to check with identifier-binding

I see, thanks