You can ‘shadow’ a built-in procedure by requiring a module that exports the same name. Ex: Module my-plus.rkt: #lang racket (provide +) (define (+ . vs) (apply * vs)) ; hahaha, that'll teach 'em! Main: #lang racket (require "my-plus.rkt") (+ 3 4) ; 12 (Untested, typed on phone)

I think wlbberman do want to ‘extend’ the function of a procedure (for example, logging some info when it’s called) instead of shadowing.

I’m also interested in the answer :grin:

You can do that with shadowing, but it will work only for the modules that import the new function, not modules that are already defined. Otherwise I think the only alternative is to modify the original code directly.

maybe a wrapper can help?, keep the original functionality and use rename-out to replace the binding. (define (plus-wrapper x y) (display "you are calling +") (+ x y)) (provide (rename-out [plus-wrapper +]))

That’s precisely shadowing :slightly_smiling_face:

yes

Has anyone tried couchdb 3 in racket? I’m having trouble with authorization.

It’s ok, just sorted it out.

@wanpeebaw You are telling him something that the linked answer already explains — punctuated by :rolling-on-the-floor-laughing:?

Thanks for the advice. I don’t need it for predefined system functions. I’m cool with just getting the functionality for functions I defined. A friend also sent me this https://lists.racket-lang.org/users/archive/2006-May/013016.html

I’m not interested in shadowing per say. I’m interested in defining my own procedure type that can provide the functionality. i.e.

(mydefine (foo a b c) < body here >) (foo 1 2 3) ;; Works as if foo was created via a standard define (procedure-body foo) ;; -> < body of foo >

That’s easy. Use define-syntax-rule to make a my-define that not only defines the function as usual but also adds the key and procedure code into a hash table (make-hasheq). Tell me if you’re stuck.

@greg: Racket Mode feature request: a command that pretty-prints the region and then re-inserts it and re-tabifies it

@samth What if you put point at the start of an sexpr and do C-M-q ?

that’s just indenting

Do you mean eval the region, and insert the pretty-printed result?

(If not, maybe a little example would help me understand.)

Imagine you have some piece of code which was printed out with “write” and you pasted it into your source file. Then you have to go insert a bunch of newlines, and then indent properly. I’d like to automate that.

So (dumb example) the region is (say) something like (define (f x) (if 11341234 2342477777777777777777777777777777777777777777752435 (if #f 1 (quote asdfadsf)))) and you’d like it to become (define (f x) (if 11341234 2342477777777777777777777777777777777777777777752435 (if #f 1 'asdfadsf))) ?

The Slack thread presentation is not the best for this, but yes

That’s literally what pretty-format would produce.

Yeah it’s better if you click the Threads thingie in the top-left.

I’m just asking because pretty-xxx don’t really follow Racket coding guidelines, exactly, about newlines. It’s very line width based.

Right, it wouldn’t be perfect, but it would help a lot in this situation

But if that’s adequate, that’s a pretty easy thing to implement.

OK, got it.

By the way, to do code generation, Racket has this thing called “macros” you might want to take a look at?

lol

:smile:

this is more “some error message spit out some big s-exp”

Yes, that was the solution I posted in the other thread. I’d prefer to not save the additional properties in a global but instead as a part of the datatype which also acts as a procedure if possible.

However, I’m more than willing to go the global hash table route.

Is there any existing effort to add support for version pinning to raco pkg?

You wouldn’t need to use any globally accessible data for this. First off, things defined in a module body are not globals. You can export them or not from the module. Second, you could also use structs that implement prop:procedure and keep the s-exp in the struct itself.

Meaning for packages in general, since https://docs.racket-lang.org/pkg/FAQ.html#%28part._.How_can_.I_specify_which_version_of_a_package_.I_depend_on_if_its_interface_has_changed_and_.I_need_an_old_version_%29 implies that doesn’t happen right now.

prop:procedure is exactly what I was looking for. Thanks!

@samth This is a quick prototype. It only works on one s-expr at a time, which you need to mark as a region. It has minimal error-checking. (defun samth/pretty-format (beg end) (interactive "r") (unless (region-active-p) (user-error "mark a region first")) (let ((orig (buffer-substring-no-properties beg end))) (delete-region beg end) (call-process "racket" nil (current-buffer) t "--eval" (format "%S" `(pretty-write (read (open-input-string ,orig))))) (goto-char beg) (prog-indent-sexp)))

awesome! that’s already helpful

as in, I just used it

@deactivateduser60718 there’s been lots of discussion of that sort of thing (@lexi.lambda probably can point to the mailing list archives). the big challenge, which is (IMO) why it doesn’t exist now, is that http://pkgs.racket-lang.org\|pkgs.racket-lang.org (and catalogs in general) don’t store the package contents. That means that the big goal of version pinning, that you can re-run your code somewhere else and get the same packages, doesn’t work. Instead, if you want that level of reproducibility, you have to archive the whole catalog, which is what raco pkg catalog-archive does.

The other reason is that the pkg system doesn’t have any “old version” information, and if you started pinning things, then you could quite easily need much more complicated choices about which packages to install. That would be a lot of additional complexity in the package system, and thus hasn’t been added in view of the first issue.

I think you could put the pieces of raco pkg (and raco link, the underlying system) together to produce a package system much more like npm or cargo, and that would be a worthwhile thing to try, but it would be a pretty big step from the current system.

A final reason for the current setup is that the previous approach for packages in Racket (called PLaneT) built versions and version specs in much more deeply, into the source code even, and that (I think) had some serious drawbacks. You can see the design of raco pkg in some ways as learning from the problems with that system.

while I have you here, numbers with exponents don’t get the literal color in racket-mode

Super informative, thank you :+1:

Two other things to say there: 1. I don’t mean to discourage you from wanting this; I’d like to have that kind of package system too. But probably someone needs to build it, and Matthew and Jay (who built the current one) aren’t likely to. 2. Other people have proposed doing things here (such as @notjack) but nothing has ever gotten of the ground.

Is there a summary somewhere of the problems with versions as they existed in PLaneT?

The biggest problems were 1. you ended up with a bunch of versions of the same library in your program, 2. upgrading was changing the program, 3. (the biggest one, IMO) different versions of the library would define incompatible structs (because structs from two different modules are distinct) and then you’d get errors when one flowed into the other.

@samth @deactivateduser60718 IMO, the fact that the package catalog doesn’t store package contents is mostly unrelated from being able to depend on a particular version of a package; it would be perfectly possible to continue to use a git repository as a package source yet to support package versioning.

Any complaints about such a system would still apply to the current system, so I think it’s pretty orthogonal.

@lexi.lambda Agreed.

One problem with pretty-write is that it doesn’t preserve (quote ...). It will be turned into ' instead.