something like (contract-out (f (-> (lambda (g) (procedure-arity-includes g .....)) any/c))) ? (contracts are just code :))

Does anyone know if there is a ~datum like syntax class that can be used with define-conventions?

wow, this program used to type check. It doesn’t anymore, ~yay~! #lang typed/racket (: f (-> Integer Integer)) (define (f x [y 0]) (+ x y))

@ben Sadly that only seems to change the highlighted color. Also no rainbows. :disappointed:

@ben that doesn’t seem like it was an intended change

it type checks in my 6.12 repl

the change happened over the weekend

I think https://github.com/racket/typed-racket/commit/4b1a1bfa9d59aa2ae469e1217dd16aea9c2f5aa6

should that typecheck? I really can’t tell

I’m happy getting an error, because it told me I had an “arity error” in my type

@ben yeah, I’m sure that’s because of the kw argument change

@ben help me through this — why should that function not type check?

is it not a function that, if given an integer, produces an integer?

that’s true

I’m pretty sure it should check at that type

I’m going to try and double check it wasn’t the other commit that happened this weekend affecting functions…

what should happen if it’s called with two integers?

at that type that cannot happen

so, an application where 2 arguments are supplied should either be statically rejected by the type checker or not allowed by a contract

it seems like if that program is rejected then (ann 1 Integer) should also be rejected, which clearly doesn’t make sense

???

it seems odd to me that sometimes a subtype annotation is okay but sometimes it isn’t

what do you mean

what subtype annotation is not okay

Ben’s program

I am agreeing with you

I don’t understand what we are agreeing on

xD

that the program Ben posted should typecheck

okay… I guess the “if/then” is what confused me, but nevermind

@ben @samth it looks like the regression was from https://github.com/racket/typed-racket/commit/4b1a1bfa9d59aa2ae469e1217dd16aea9c2f5aa6 (and not the other function-related commits from this weekend)

I expected that to typecheck, too. If you make y a keyword argument, then it does typecheck, so the part that has gone wrong is related to by-position optional arguments.

@mflatt Is there any API accessible to macro authors that allows either (a) forcing recursive expansion in a context where #:out-of-context-as-variable? is #f or (b) determining whether or not a particular binding is in context in the current expansion context?

Put another way: is there any way I can recursively expand a piece of syntax and reject syntax that includes out of context variable references?

@lexi.lambda I can’t recall one, so I expect that there isn’t (since you didn’t find it)

Would adding a keyword argument to local-expand for that behavior be reasonable, or is there a better way to do it?

An extra argument sounds ok to me. Note that the expander’s exported API can’t have keywords, though; a keyword variant would have to be implemented at the racket/base level.

@mflatt I’m not sure I totally understand how to arrange for that to work out for the bootstrapping process. I tried doing the naïve thing of adding positional arguments to local-expand and its variants, then adding a new module racket/private/kw-syntax-local, but bootstrapping the expander failed with the following error: Traversed 278 modules Got 267 relevant linklets Need 211 of those linklets Code is 3024648 bytes as source Unfortunately, some linklets depend on pre-defined host instances that are not part of the runtime system: - /Users/alexis/gits/racket/racket/racket/collects/racket/private/kw-syntax-local.rkt at 0 needs #%core: syntax-local-expand-expression local-transformer-expand/capture-lifts local-transformer-expand local-expand/capture-lifts local-expand needed by side-effect

I’m not sure how to interpret this error. Does it mean there’s something wrong with the expander code, or with kw-syntax-local.rkt? It seems like it would be normal that kw-syntax-local.rkt needs #%core, but I don’t know what “needed by side-effect” means.

It looks like the flattener can’t infer that the new module is free of side effects. I don’t have a guess at why, but I you could send me “kw-syntax-local.rkt” and maybe I’ll see the problem.

The module is pretty small: (module kw-syntax-local "pre-base.rkt" (require (prefix-in k: "pre-base.rkt")) (provide local-expand local-expand/capture-lifts local-transformer-expand local-transformer-expand/capture-lifts syntax-local-expand-expression) (define (local-expand s context stop-ids [intdefs '()] #:allow-out-of-context? [allow-out-of-context? #t]) (k:local-expand s context stop-ids intdefs allow-out-of-context?)) (define (local-expand/capture-lifts s context stop-ids [intdefs '()] [lift-key (gensym 'lift)] #:allow-out-of-context? [allow-out-of-context? #t]) (k:local-expand/capture-lifts s context stop-ids intdefs lift-key allow-out-of-context?)) (define (local-transformer-expand s context stop-ids [intdefs '()] #:allow-out-of-context? [allow-out-of-context? #t]) (k:local-transformer-expand s context stop-ids intdefs allow-out-of-context?)) (define (local-transformer-expand/capture-lifts s context stop-ids [intdefs '()] [lift-key (gensym 'lift)] #:allow-out-of-context? [allow-out-of-context? #t]) (k:local-transformer-expand/capture-lifts s context stop-ids intdefs lift-key allow-out-of-context?)) (define (syntax-local-expand-expression s [opaque-only? #f] #:allow-out-of-context? [allow-out-of-context? #t]) (k:syntax-local-expand-expression s opaque-only? allow-out-of-context?)))

Ok – the expansion involves make-optional-keyword-procedure, and a later pass of the flattener can figure out that calling make-optional-keyword-procedure has no side effect, but the check for a reference to expander functions happens before that (and didn’t seem easy to reorder, for reasons that I forget). So, adding keywords for functions below the expander level can work this way, but not functions from the expander layer. The right workaround isn’t immediately obvious.

Sorry, I only just saw this—that makes some sense to me. I think that’s okay, since this thing I wanted to add was mostly just to be able to do “the right thing”, but what I have right now seems to work fine.

It does seem like it would be useful in general to be able to export functions with keywords from the expander layer, though.

@lexi.lambda I think the solution is probably to improve the flattener so “kw-syntax-local.rkt” is ok. But not this week.

Understandable. I should probably be focusing on other things, anyway. :)