@greg Excellent, thanks for the pointers!

So the solution is to create a submodule and export (define rkt-define @racket[define]) , that makes sense.

And then, in your document: @(begin-for-syntax (define rkt:define (make-element-id-transformer (lambda (stx) rkt-define)))) will make the substitution happen automatically.

@soegaard2 I don’t see what you mean. Currently I’m using: @(module def-racket racket/base (require scribble/manual (for-label racket/base)) (define rkt-define @racket[define]) (define rkt-lambda @racket[lambda]) (provide (all-defined-out))) @(require 'def-racket) .... Like @\|rkt-define\| from @racketmodname[racket/base]... which does the trick

If you use the element-id-transformer, then @racket[rkt:define] will render to the value of @racket[define]. The substitution also happens with racketblock, racketcode etc.

Oh good, thanks. I won’t need that though, but that’s useful to know

but I have my numbers available as a list (sorry, have just found there is also a #beginners channel)

@notjack write an issue for Rhombus?

@laurent.orseau working on a prototype first, I think I need an example to illustrate it well

Can’t wait to see the result :slightly_smiling_face:

When embedding CS, can I rely on ptrs to Racket functions (retrieved using racket_dynamic_require) to remain static between GCs? The docs mention that Racket values should not be retained between calls to racket_*, but I think this wouldn’t necessarily be true for code. When I use racket_dynamic_require to require a top-level function from a module, do I get back a function pointer or some kind of intermediate value which might get moved?

To give a concrete example of what I’m doing: https://gist.github.com/Bogdanp/49aac3f4cc4b727323b58c60e105a601\|this seems to work just fine, but I’m wondering if it’ll come back to bite me.

The intent here being to avoid performing a namespace lookup and the associated allocations inside a tight loop.

basic idea pushed here https://github.com/jackfirth/decorator/commit/7f654b9f27dc12d6b74d1ad6e369ad39fb10d698

Answering my own question: the app crashed after a while due to a bad memory access so the answer is probably “no”. Is there a better way to refer to functions from a module from C?

As you say, functions generally will not stay in place. You can use lock-object or Slock_object from the Chez Scheme layer to keep it in place.

Thanks! I’ll try using Slock_object.

Nice. The decorators are mostly tags for now, right? How do you intend them to be used for transforming code?

No worries, everyone’s friendly in the Racket community. The language is great, the people are great.

Basically, it depends on what kind of thing you’re decorating. Definitions will support one kind of transformation, structs a different kind, submodules another kind, etc. User macros (like rebellion’s type definition macros in rebellion/type, for example) can implement support for their own kinds of transformations by expanding to #%decoratable-form.

Just pushed an implementation of definition decorators https://github.com/jackfirth/decorator/blob/master/main.rkt

Example usage: ;; This is a (non-syntax) definition decorator. Definition decorators are macros that receive the list ;; of identifiers to define, and the body expression that produces their values. They expand to a ;; replacement body expression. This definition decorator prints the defined values when the ;; definition is evaluated. (define-simple-macro (@print (id ...) expression) #:with (result ...) (generate-temporaries #'(id ...)) (let-values ([(result ...) expression]) (printf "~a = ~a\n" 'id result) ... (values result ...))) (decorating-block ;; Prints a = 1 (decorate @print) (define a 1) ;; Prints b = 2 (decorate @print) (define b 2) ;; Prints c = 3 (decorate @print) (define c 3) ;; Prints: ;; d = 4 ;; e = 5 ;; f = 6 (decorate @print) (define-values (d e f) (values 4 5 6)))

I see, thanks. That’s a pretty good start!

Could you do something that runs ffi-callback on the Racket side and save that pointer on the C-side?

In the following code, how do I make sure the error location is call site of foo (or better the s-exp (error ...)) instead of ../../../../../usr/share/racket-7.9.0.9/pkgs/drracket/drracket/private/stack-checkpoint.rkt:115:30: stop? #lang racket (require syntax/parse/define) (define-syntax-parser foo [(foo body ...) #'(let () body ...)]) (foo (error "stop")) I tried various combinations of #:contex and syntax/loc without success

Are you using errortrace?

I was not :face_palm:

Thanks! :slightly_smiling_face:

Well, I think it should work without errortrace enabled

probably related to https://github.com/racket/racket/issues/3325

That would be good indeed but there’s a tradeoff between debugging and speed which I’m ready to accept.

I meant, it probably works with errortrace disabled if you use Racket BC

The fact that it doesn’t work for you is due to Racket CS bug

I was looking for an idiom make stuff like (cond [test-expr #f] ...) more palatable, and I like (cond [test-expr => not] ...) , but I wonder if there are others?

(and (not test-expr) (cond ...)) maybe?

@ben.knoble Perhaps and-let* from srfi 2 ? https://docs.racket-lang.org/srfi/srfi-std/srfi-2.html

I haven’t seen it used much. The cond solution seems more popular. Alternatively, use match: (match test-expr [#f <handle-false>] [x <handle-non-false>])

I like the match solution.

The guarded-block macro I made a while ago would work for that

Is stat-template short for “static template” ?

What’s a good way to communicate between racket programs and DrRacket plug-ins (“tools”)? (ping @leif and @florence, in case you have ideas)

I’m asking on behalf of the Forge devs. at Brown https://pkgs.racket-lang.org/package/forge

I think via syntax properties is the pretty standard way, but I guess it depends a little on what kind of tool you’re writing

ah! well that’s much better than a logger

If you want to communicate information about expressions, use syntax properties. If you want to communicate information about identifiers, store the information in the identifier itself using define-syntax and a struct that implements either prop:procedure or prop:rename-transformer, depending on whether non-tool users of the identifier need to use syntax-local-value on it. In that case, tools can get the stashed information instead of the original binding using syntax-local-value/immediate .

Try to avoid global mutable identifier hash tables if you can, but don’t stress too badly if there’s no other way to annotate identifiers you don’t control.

I have learned that macros don’t behave the same in the REPL as they do in a file.

Is that part of, “the top level is hopeless”, or is a separate thing?

Yup that’s the top level being hopeless