Suppose module A exports an uninterned symbol s (via a submodule, if that’s relevant). and modules B and C transitively require A from different paths, and module D requires B and C. Is it somehow possible (compilation issues, say) for B and C to see two different values of s and thus to cause problems in D?

I guess not, but I was thinking that something of this effect can be achieved with struct types (if the type is produced when calling a lambda). the symbol def in not in a lambda in my case, but maybe submodules can have strange effects?

(It’s likely a really stupid bug in my code though…)

I’m not sure, but have you seen this thread? https://lists.racket-lang.org/dev/archive/2012-July/009817.html

Interesting, thanks. There seem to have been some work on gensym since then. The docs also say that string->uninterned-symbol shouldn’t be called twice as the results won’t be eq?, but I’m only calling it once and nothing should ‘re-produce’ it—normally.

hmm… when I change the uninterned symbol to some normal symbol I get the same issue, so it seems the problem is elsewhere. Weird.

Yep, ok, bug on my side (not so stupid though :slightly_smiling_face: )

Actually, I haven’t solved my issue, and there may be something deeper. See #drracket

@mflatt the doc claims that:

(current-continuation-marks [prompt-tag]) is equivalent to:

(call-with-current-continuation (lambda (k) (continuation-marks k prompt-tag)) prompt-tag) Experimentally, that’s not true:

#lang racket (let () (println (length (continuation-mark-set->context (current-continuation-marks (default-continuation-prompt-tag))))) (println (length (continuation-mark-set->context (call-with-current-continuation (lambda (k) (continuation-marks k (default-continuation-prompt-tag))) (default-continuation-prompt-tag))))) (void)) prints

12 1 for me.

The implementation of ccm is:

(call/cc (lambda (k) (make-continuation-mark-set (prune-mark-chain-suffix who (strip-impersonator tag) tag (current-mark-chain)) (cons (continuation->trace k) (get-metacontinuation-traces (current-metacontinuation)))))) Is there a way to do the same using public API?

Arguably, the the documentation is correct on the grounds that continuation-mark-set->context doesn’t make any checkable guarantees. Context is currently defined as “approximate,” meaning whatever is convenient — and it’s potentially convenient to return a different result every time.

The fact that the convenient thing can pick up information about frames beyond the requested prompt could be considered a space leak. It’s not the sort of space leak that can easily change the space complexity of a program, I think, but it’s worth considering more.

I’m not sure what you mean about the public API. The currently convenient thing that happens with context corresponds to using unsafe-root-continuation-prompt-tag, which would be reachable only through ffi/unsafe/vm.

By public API, I meant a way to evaluate:

(make-continuation-mark-set (prune-mark-chain-suffix who (strip-impersonator tag) tag (current-mark-chain)) (cons (continuation->trace k) (get-metacontinuation-traces (current-metacontinuation))))) using stuff provided from #lang racket and libraries.

But yeah, I think I get the general point.

Thanks!

I think I saw a link here to a package or a language made for CSV data manipulation? It was a DSL if I recall correctly. I can’t seem to find it again. Does anyone know what I’m talking about?

not sure exactly what you are thinking of, but there are a few packages for CSV work; I particularly like data-frame

Thanks, didn’t know data-frame. Maybe I just looked at threading and kinda of thought of doing a DSL myself and now my memory is failing. In any case, data-frame looks good (so it was worth it to ask) and I also found https://github.com/n3mo/data-science\|data-science, which looks very interesting. Thanks, samth!

Did not know about either of these, both look very useful, thanks!

uninterned symbols are bad, is my hot take

That wasn’t the issue actually. So I’ll wait a little more before I can bash them :slightly_smiling_face:

someday, laurent, someday :p