@notjack Yes, Racket could exit before the thread finishes

is there a way to define something once and have it be available in both the for-syntax and the top-level without copying and pasting? (begin-for-syntax (define my-fn my-fn)) is the dumb first thought that comes to mind, and obviously that doesn’t work. (If it did, I would be surprised.) (edit: where my-fn is already defined, of course)

@fluffywaffles You can define the thing in a module, then require the module both for runtime and for-syntax.

For instance using module in the same file: #lang racket (module m racket/base (provide f) (define (f) (println "f") 42)) (require (for-syntax 'm) 'm)

Or you could define f in a module that is another file like f.rkt, and (require "f.rkt" (for-syntax "f.rkt")). Same difference.

gotcha, thanks @greg

@fluffywaffles You’re welcome. The TL;DR is define things once in a module. Then, how/when they’re available is a function of how you require their module.

@mflatt How often do we update the versions of various native packages?

As listed here: https://github.com/racket/racket/tree/master/racket/src/native-libs

I ask because I would like to know if I can rely on Racket coming with libpng16. (Except on Linux obviously.)

Rarely, and on no particular schedule

That makes sense. Do we have any announcement when we do?

I mean, I would be happy to have racket install libpng16 when its needed. But I’m worried about that conflicting with the one Racket comes with.

I guess, since its not going to update in the middle of a Racket version, I can just make a libpng16 package, and have an exception to not install libpng16 for versions that already have it installed.

We provide libpng16 right now on Windows and Mac OS, right?

That is correct.

And on linux it needs to be installed (which it is on basically every distro….)

I’ve having trouble with the str syntax class (or, at least I think I am…?): I have a custom syntax class that uses str in its pattern, but when I give it a str in the correct location it fails to match, even though the output of (string? (syntax-e stx)) is #t.

I made a gist of the issue in an effort to make up a minimal reproduction: https://gist.github.com/fluffywaffles/e616df5399d5e7140b76229af94b30d0

Any help would be much appreciated! I have absolutely no idea why this is happening.

@fluffywaffles It looks like the q class matches a string, but the last subform provided to select is a list containing a string.

Right; I explain that I still think the error is unexpected… Can you explain why it does what it does?

In the gist, rather, I explain in a comment (on the gist, not in the code)

I think you’ll get the behavior you expect if you add the #:commit option to the q syntax class.

Unfortunately, I have to run—maybe someone else can explain in more detail (or I can once I get back).

that works — thanks @lexi.lambda

I don’t know why, but it works

I have another minute or two… basically, without #:commit, syntax-parse can backtrack back into a syntax class even if the syntax class originally succeeded if a later parse fails.

So your q pattern successfully matches "hello" against the first pattern, then continues matching the top-level pattern, and that fails. So it backtracks into q and tries to match "hello" against the second pattern, which always fails.

And specifically, it fails by throwing an exception, not by using ~fail or something like that, so that failure is unrecoverable, and parsing halts.

oh, interesting — so if the first syntax class pattern matches, but then after moving on, the next form in the overall syntax object doesn’t match, it’ll go back to the most recently tested syntax class and try other patterns?

Why is that?

You probably want to use ~fail instead of (~do (raise-syntax-error ...)). Of course, in this case, you probably don’t want the second case at all, and instead might just want to add #:description "question" to q and just let syntax-parse generate its own error message.

But yes, generally, syntax-parse tries everything. It backtracks to try every possible solution unless you explicitly add cuts/commits.

It’s possible to construct a situation in which that backtracking behavior is desirable, but it often isn’t, so #:commit is a useful option for a lot of syntax classes.

Unfortunately, I don’t have time to construct such an example, though.

No, you’ve been plenty helpful even without! Thanks @lexi.lambda

@fluffywaffles The “try everything” approach is also paired with a notion of “progress” - syntax-parse orders possible parses based on how early they fail. When parsing fails, this lets syntax-parse choose the parse that failed the latest and uses that parse for an error message, since that’s likely what you want. The “Introduction” section of the syntax parse docs describes this and other aspects of syntax-parse in a friendly manner, I recommend reading it: http://docs.racket-lang.org/syntax/stxparse-intro.html?q=syntax%20parse