Hope to discuss this old question a bit further: https://racket.slack.com/archives/C09L257PY/p1616624808201500 The original question is: > How to collect the results from “delimited continuation world” But more precisely, this question should be: > How to collect the results from non-deterministic computation which implemented by reset/shift? Indeed there are many ways to do. (e.g. mutation, generator, reset/shift with multiple-prompts, see previous threads in the #beginners channel)

Recently, I read the paper “Abstracting Control” by Olivier Danvy and Andrzej Filinski. They introduced a new method to collect results via CPS hierarchy, i.e. a family of reset/shift operators Something like: (define (fail) (shift1 c "no")) (define (flip) (shift1 c (begin (c #t) (c #f) (fail)))) (define (test-sat) (let ((b1 (flip)) (b2 (flip)) (b3 (flip))) (list b1 b2 b3))) ;; shift2 captures level-2 continuation (define (emit n) (shift2 c (cons n (c '())))) ;; collecting result by emit (reset2 (begin (reset1 (emit (test-sat))) '())) Does Racket support this kind of family of reset/shift operators? (i.e. reset1/shift1, reset2/shift2, … ) Thanks.

PS: In addition, it seems that the family of reset/shift operators is very similar to multiple prompts. But I don’t know the connection between them.

That paper mentions Sitaram and Felleisen 90 as being a similar approach, which can be implemented in Racket (they show an implementation in Scheme). In general there are connections between all of the different control operators, and there’s a lot of literature on this. You can probably encode the shift_n hierarchy in Racket’s control operators, but I don’t know that anyone’s done it.

Thanks. In the shift-reset scenario, can I think of this family of reset/shift operators is exactly multiple prompt? (i.e. reset-at and shift-at)?

No, they’re different, because they accumulate — reset2 interacts with shift1.

But not the other way around.

Whereas with tagged prompts (as in Racket) different tags do not interact

You mean that when the body of shift1 finished, it will return to reset2 if the reset2 is the nearest reset?

I believe that shift_k captures the continuation up to the nearest enclosing reset_n where n >= k (but I might have that backwards)

I my example, it seems no difference. I can rewrite the code above by reset-at and shift-at: (define p1 (make-continuation-prompt-tag 'reset-1)) (define p2 (make-continuation-prompt-tag 'reset-2)) (define (fail) (shift-at p1 c "no")) (define (flip) (shift-at p1 c (begin (c #t) (c #f) (fail)))) (define (test-sat) (let ((b1 (flip)) (b2 (flip)) (b3 (flip))) (list b1 b2 b3))) (define (emit n) (shift-at p2 c (cons n (c '())))) (reset-at p2 (begin (reset-at p1 (emit (test-sat))) '()))

Could you give me a example which can show their difference?

The difference between what? shift-at is not shift_n from that paper.

I mean an example program which replaces all the reset_n to reset-at n and shift_n to shift-at n , but give different behavior.

If you do (reset-at p1 (+ 1 (reset-at p2 (+ 1 (shift-at p1 k k)))) that captures the continuation (+ 1 []) in the shift-n semantics but (+ 2 []) in the shift-at semantics.

I understand what you mean. Very thank @samth !

I’m developing a library locally. Is there a command that combines raco pkg remove <my_package> and raco pkg install (in the working directory)?

raco pkg update <pkg-name> <src-path> if I’m not mistaken?

Maybe raco pkg update ?

https://docs.racket-lang.org/pkg/cmdline.html?q=raco%20pkg#%28part._raco-pkg-update%29

I tried that and got $ raco pkg update Updating current directory's package: todo-txt raco pkg update: cannot update linked packages; except with a replacement package source package name: todo-txt package source: /sd/racket/todo-txt

I want to reinstall the package to rebuild and reinstall the documentation.

If <my_package> is in the folder my_package,

raco pkg update my_package/

will override the currently installed my_package and use what you have in the folder.

But that’s not what you are asking for.

You want a command to begin from? I.e. create a new copy of the current package and then change that?

(Maybe I am misunderstanding)

I only want to reinstall the package.

Why am I doing this? (Maybe I’m doing something wrong in the first place.)

I’m writing Scribble documentation for the API of my package. When I run scribble in my working directory on the todo-txt.scrbl file, I get these warnings Warning: some cross references may be broken due to undefined tags: (dep ((lib "racket/private/reqprov.rkt") require)) (dep ((lib "racket/private/pre-base.rkt") require)) (dep ((lib "racket/base.rkt") require)) (dep ((lib "racket/private/base.rkt") require)) (dep ((lib "scheme/base.rkt") require)) and in the generated HTML file require (generated by defmodule) is underlined in red. After reading https://stackoverflow.com/questions/20685638/unresolved-links-in-scribble-lp-document my understanding/assumption is that the link will work if I install the documentation properly as part of my package.

You want to just run raco setup yourpkg

@raoul.schorer (Sorry, didn’t see your reply because I was only looking in the thread :smile:)

I get the same message as before $ raco pkg update todo-txt ../todo-txt/ raco pkg update: cannot update linked packages; except with a replacement package source package name: todo-txt package source: /home/schwa/sd/racket/todo-txt

You don’t have to do any packaging commands

I get $ raco setup todo-txt collection-path: collection not found collection: "todo-txt" in collection directories: /home/schwa/.local/share/racket/8.0/collects /home/schwa/sd/racket/current/collects/ ... [167 additional linked and package directories]

Oh right your collection doesn’t have the same name as your package

You can do raco setup file/todo….

Or there are options to raco setup for package names

The package should be file/todo-txt, but that gives me the same message.

Ok, let me check the raco setup --help output to see if I can find something seemingly helpful. :wink:

You need the -n flag

(I have a muilti-collection with file/todo-txt and file/todoreport, and the documentation is under file/todo-txt/scribblings/todo-txt.scrbl.)

raco pkg update -n <pkg-name> <src-path>

I usually use raco setup --only --pkgs <pkg-name>

and path needs to be absolute, I think :thinking_face:

@raoul.schorer -n is listed as -n, --no-zo : Do not create ".zo" files

Nope

You two are talking about different commands

Ah, I see

@samth

$ raco pkg update -n todo-txt ../todo-txt worked, as it seems. :+1:

You shouldn’t need any raco pkg commands just to build the docs

I tried -n file/todo-txt first, but that didn’t work.

@samth That’s what I thought, but I tried it as a workaround to fix the linking of require in defmodule. Before I was running scribble directly on the file.

Running scribble directly will have the problems you saw

But just running raco setup is all you need

@samth Another possibility might be to just continue and check the links later after reinstalling when I’m practically done.

@samth Ok, this worked at least without error message $ raco pkg install <- needed to do this first $ raco setup file/todo-txt <- just `todo.txt` didn't work

Now I’m trying to find the generated docs. … :wink:

raco docs file/todo-txt

@samth Wow, nice! It actually works. :smile:

(including the require link)

@wjb Seems to work, too. I like this even a bit more because it makes it explicit that the name is a package name.

Thanks again everyone for your help! :slightly_smiling_face:

From what I’ve seen so far, it seems to be quite common to repeat function signatures and contracts in defproc forms. Shouldn’t it be possible to somehow get this information from the modules I write documentation for? The current approach looks very “un-DRY”.

I see there’s https://docs.racket-lang.org/scribble/srcdoc.html (also described here: https://blog.racket-lang.org/2012/06/submodules.html#in-source-documentation ). Shouldn’t this be the recommended approach but if not, why not?

Alternatively, just run “raco setup”. If you package doesn’t have many dependencies, you don’t really need anything fancy

(and “Raco setup” checks things that the versions with arguments above cannot, like if you added a dependency that isn’t tracked)

There are occasions where the signatures/contracts listed in documentation are not the same as the actual contracts. This can be the case when the actual contract is really complicated, so it’s helpful to document an easier-to-read contract that is still “morally correct”.

However, I do agree that, in the cases that the documented contract is the same as the actual one, it should be easier to communicate that to Scribble.

In my experience, raco setup is slower, so I usually go with --only --pkgs until something goes wrong

If your package don’t have other dependencies then probably most of that extra time is checking to see if all of the dependencies are declared properly. It may also be updating the info cache.

(doesn’t)

Yeah, I’m sure all good things to check. But I’m impatient.

I would do better to run raco setup more frequently because I have forgotten to declare dependencies before pushing.

yeah, and when people do that in the main distribution package you break the snapshot builds. Which might be the only reason I mentioned that upthread :wink:

(probably guilty)

It is really easy to do.