@mflatt @ryan So, I think I figured out why a recent commit killed nanopass.

Older versions of syntax/loc seemed to (sometimes) work when the source location given wasn’t a syntax object directly.

(But rather a list or somethhing that syntax-case/parse can match on.)

No there seems to be a check for syntax/loc that errors when its not given a syntax? object.

@leif you probably meant to mention @ryanc in your message above

@leif Indeed, that is something that changed. But IIRC if it didn’t error before, it was because it was throwing away the loc argument entirely, because the template was just a single pattern variable. For example: (syntax/loc loc-expr x) where x is a pattern variable or (quasisyntax/loc loc-expr #,expr).

@leif that’s the same reason trivial wasn’t building yesterday — bad argument to syntax/loc. I’m happy with this error because it found a bug in my code

mentioning @leafac as his css-expr also fails on new syntax/loc behaviour

Ya. @ryanc, given the amount of packages this broke, it should at least be announced.

Also, it would be good to explicitly document that the srcloc argument for syntax/loc must be a syntax? and thus not every value syntax-parse can match on is valid there.

@leif the docs for syntax/loc already say that. The announcement sounds like it might be a good idea, though.

@githree Thanks for the mention.

@ryanc, Interesting, my build says:

“Like syntax, except that the immediate resulting syntax object takes its source-location information from the result of stx-expr (which must produce a syntax object), unless the template is just a pattern variable, or both the source and position of stx-expr are #f.”

Which is now broken. And so it ‘might’ make sense to change that and add a history note.

(Which I’d be happy to do for the record.)

@ryanc breaking a bunch of packages sounds bad

Does anybody know if there’s a way to force racket to simulate places using threads, even if places are available?

@samth I agree. Although it is at least only a handful (somewhere between 5 and 10).

@mflatt Do you know what’s going on here? https://github.com/racket/racket/issues/2019

@ryanc It also looks like the reason your push killed rosette was because Rosette already used ?? as an identifier.

(Thanks to @ben for finding that.)

(here it is https://github.com/racket/racket/issues/2031)

To be fair, if that were the only reason: My impression is that provide-ing a new definition is one of the few ways it’s acceptable to break backward-compatibility? The idea being, well users could defend themselves by using only-in with require. I’m not arguing that’s the right norm (idk) but I think that’s the de facto norm, until/unless someone wants to advocate otherwise?

I’m not sure there’s an ideal choice. - Using only-in everywhere might be tedious. - Providing whole-new-module-just-for-one-function might be icky.

@ryanc https://github.com/racket/racket/pull/2032

Does anyone here know where the scripts to create the nightly snapshots live?

as far as I can tell, it’s mostly just a standard “exporting a new identifier from #lang racket/base that other people already used” issue

Hello everybody! I’m pondering whether I should make a small package in which I provide my web helpers (creating html content and instantiating a racket web-server to serve them) or just use something already existing. Is there any racket “web framework”? I saw frog and plt-web, but they generate static content. My helpers mostly consists of basic elements (links, dates, images…) and a way to create new ones with a define-renderer macro. Then I have a define-response macro that handles serving a specific page. I want to make the inner workings of racket’s web-server disappear. Are there already packages doing that, or should I create some? (if so, I’ll need your help to come up with a catchy name)

as I understand it:

• things imported by #lang can be shadowed by require imports and by definitions
• things imported by require can be shadowed by definitions

so does exporting from #lang racket vs a require form mean anything special here?

@jerome.martin.dev I think a newer, nicer, more consistent layer on top of web-server would be appreciated.

The problem is that people often do (require racket/base) (often for-syntax or for-label, but that still suffers from the same potential pitfalls).

If it was only used as #lang racket/base, you’d be right in that it probably wouldn’t be a problem. But it isn’t only used that way.

Yup. Especially when making the sort of, front end, so to speak, for DSLs.

Cool, I’ll extract what I came up with from working on my websites, and put it on github, so that you can give me some feedback :slightly_smiling_face:

@jerome.martin.dev I like racket web stuff a lot so looking forward to it

Wait is ?? part of racket/base now?

Yes, on HEAD (but not in any releases yet). IIUC, syntax is now essentially template from syntax/parse/experimental/template, but I’m not completely sure if all the features from template were ported to syntax.

I thought they were. Although you know them better than me.

Okay I’m less confused now I think

I’m assuming template recognizes ?? as a bound literal instead of a datum, is that right?

Yes, that’s right.

@jerome.martin.dev even if there would be packages like this already I still think it would be a good idea to publish yours. Seeing how others deal with similar problems is an eye opening experience that creates synergistic effect that can ultimately lead to great results (ever-greater packages)

@leafac @githree I have pushed a fix to nanopass.

So it should now (hopefully) work on head.

thanks @leif!

I think the most annoying bit is that you can’t just say (except-in racket/base ??), because then it won’t build on 6.12 because ?? isn’t provided.

Like, it would be nice if there was an except-in/maybe-doesnt-exist form. Or something like it.

dear past Ben I think you should see this: https://github.com/racket/racket/issues/2031

There’s some code in @alama’s book that would be nice to have as a package too

@stchang @alexknauth @ben I think I might be throwing in the towel (for now) on using prefab structures

time to convert a lot of uses of racket/match to uses of syntax/parse…

@lexi.lambda I’m also curious about how that journey worked out

s

essentially, I want to be able to embed expanded types back into syntax objects, and I can do that with prefab structures, but that wraps them in syntax objects anyway, so there’s not really any advantage to doing so

trying to go half way is more trouble than it’s worth

I guess it’d be possible to use syntax-wrapped prefab structures, but I’m not sure there’s much of a point to doing so

(versus just using the usual lists and symbols)

Is there a way to force an expression to evaluate at compile time without defining a macro?

@plotnus you could use begin-for-syntax I think, but it depends what you want to do

I’ve thought that prefab structures were the better idea ever since hearing about it.

And since then I’ve made an alternate version of Turnstile that allows prefab structs as types…

What’s the problem with prefab? Possible marshaling/unmarshalling cost? Not having syntax-parse’s error messages? Interaction between modules?

Macros expanding to syntax that contains types?

I just saw this btw

@alexknauth the last one is the main problem. you can devise a way to turn the prefab structures back into syntax, but I find that somewhat unsatisfying. do you disagree?

So I haven’t tried out the gist yet

Expanding to dummy syntax with the type in a property isn’t an option?

(define-syntax stop/error
  (λ (stx)
    (raise-syntax-error #f “bad” stx)))

... (local-expand ... (list #’stop/error)) ...

... (syntax-property #’(stop/error) ‘is-type ...prefab-struct...) ...

?

@alexknauth I think that’s feasible, but I think it’s a confusing interface for users.

What do you mean? The interface for users wouldn’t be this, it would be an Int or -> macro that expands into (syntax-property #'(stop/error) 'is-type ...), and something like an expand-type function that does the (local-expand ... (list #'stop/error)) and gets out the syntax property.

But importantly, that expand-type function wouldn’t have to traverse the same syntax twice, because of the stop/error identifier in the stop-list.

And if users really need it, you would provide a type->syntax function that’s just (syntax-property #'(stop/error) 'is-type ty)

expand-type : Syntax -> Type
type->syntax : Type -> Syntax

@notjack thank you, I’ll give it a try. what I’m doing is setting an integer through a bitwise-ior of several bits. & want that computed at compile time so the binary would just have the results of evaluation.

@alexknauth Perhaps you’re right. That would be a less destructive change than ripping out half my code and replacing it. Maybe I’ll give that a shot to start.

(I was originally considering something like that, but after thinking about it again, I realized I had rejected it for a reason that is no longer relevant. So I should give it another try.)

Okay.

One module can require another at compile time with for-syntax, so you can define a regular variable containing the result of the thing you want to compute and use that variable in compile-time macros of another module