@sorawee Hey! Thanks for reviewing. I don’t know how to use ~bind, care to explain further?

(define-syntax (mycond stx)
  (syntax-parse stx
    [(mycond (~optional (~and (~bind [fallthrough
                                      #'[else
                                         (error 'failure
                                                "no clause matched")]])
                              #:error-on-fallthrough))
             clause ...)
     #'(cond clause ... (~? fallthrough))]))

Like this, I think

For the purposes of the syntax-parse example though, maybe it should be something simpler, that doesn’t require ~bind or ~?.

I see. That’s a good point.

@sorawee Oh, I see, thanks! I agree with @alexknauth, that would be cool to find a simpler example.

The first thing that comes to mind is a struct-like macro with a #:transparent flag that determines whether the “inspector” argument is #f or (current-inspector), but that might also be more complicated than neccessary.

Yep, I was thinking about something with structs too, because that’s one of the “standalone keywords” in the wild that are widely used

But as all other examples were about this mycond thing, I tried to stay consistent

The “More Keyword Arguments” section of the syntax-parse examples uses the struct options as examples: https://docs.racket-lang.org/syntax/More_Keyword_Arguments.html?q=Optional%20Keyword

However, it uses it to explain ellipsis-head patterns, which is also more complicated than necessary when there’s only one flag.

But maybe a simplified version of that struct example with only one flag would make sense in the first “Optional Keyword Arguments” section.

Wow, yes, my solution was already buried in that big example, and I definitely couldn’t see it when I skimmed over the doc.

I guess it’s a good reason for making a simpler example

> There are two main problems with the pattern above: > • There’s no way to tell whether a zero-argument keyword like #:mutable was seen. > • Some options, like #:mutable, should appear at most once. > > The first problem can be remedied using ~and patterns to bind a pattern variable to the keyword itself, as in this sub-pattern: > (~seq (~and #:mutable mutable-kw))

It happens a lot when Iearn new tricks in Racket: I read the doc, I don’t understand a thing, I try stuff by myself, I check on stackoverflow, I ask here, then days later, when I finally get it, I read the doc again, and now it makes sense.

The problem is the doc example in “Other Keyword Arguments” tried to address both of those two bullet points at once, and the solution to the first ended up washed out by the solution to the second.

yep

I’d add that none of the examples in that page shows up the template part

which means as a reader you don’t know how to use what you just matched

By reading those example, as a beginner, I still don’t get why (~and) was used and what it did (create an attribute bound to the keyword)

while the example I suggest shows precisely that, and nothing else

(except from the ~@ usage which I find clumsy)

Sorry for a dumb question, but why is, for example, define-syntaxes a part of Racket core form? Ideally I think that after fully expand Racket code, I would have code in phase 0, and all define-syntaxes could be safely removed.

@sorawee I think it’s because fully expanded modules can still export syntax definitions for other modules to import

There may be other reasons too

It’s possible that they will be used by some other module for example, the expansion time of another module could depend on those transformers and even the runtime of another module could depend on them if the module is require for-template

if a module would only by instantiated at 0, then those define-syntaxes won’t be used but the module itself cannot determine that

@sorawee what @notjack says is right — if you are turning something into a single executable and you’ll never require the module, then define-syntax could be removed

I see. Thanks!