I think @laurent.orseau might be objecting to your:
(require (prefix-in + (only-in racket/base +)) ; ++ is now standard +
(prefix-in * (only-in racket/base *))) ; ** is now standard * :slightly_smiling_face:
‘Objecting’ might be a strong word, but that’s what i was referring to indeed
You also have filtered-in which would be the right tool if you imported more operators and used the same pattern
Wasn’t thinking along those lines - but I see your point. Using rename-in would signal the intent better.
Yeah, you wouldn’t need the comment
Are you putting that code somewhere stable? I’d hate to see it fall off the Slack history.
It’s on the mailing list, so it is in the mailing list archive.
oh, whew :)
How about gist (my preference), gitlab snippets, pasterack or pastebin?
the first two allow you to revise your code without sending a new email :wink:
Although quite frankly, a package would be nice :slightly_smiling_face:
It’s pretty nice to have this for structs—classes are too heavy in many cases.
[unrelated] [compiler] Is there a rule that says something like “If a function is called only once in some other function of the same module and is not exported, inline it, even if it’s huge”?
Or am I missing cases where this can still blow up memory usage?
There’s a rule like that for locally bound functions. At the module level, though, everything ends up being exported, in a sense, by module->namespace.
Well, you can use (#%declare #:empty-namespace) and avoid exporting macros, and then probably the compiler could be made to treat a definition as unexported, but I don’t think that happens right now.
> There’s a rule like that for locally bound functions. Good to know, and pretty cool!
> At the module level, though, everything ends up being exported, in a sense, by module->namespace. Ow, that’s too bad. So this encourages local single-usage functions rather than module-scope single-usage functions.
Thanks
Wouldn’t define-inline be enough in this situation?
Speaking of continuation marks (at least we were a couple days ago, maybe in #beginners) I don’t understand the comment here in errortrace-lib/errortrace-key.rkt: ;; Defining `errortrace-key' as a function is a performance hack:
;; the compiler can track function constants, and in particular the
;; fact that it's not an impersonated/chaperoned mark key, so that a
;; `with-continuation-mark' using this key can be dropped if the
;; body expression is simple.
(define-values (errortrace-key) (lambda () 'anything))
I’d rather avoid giving hints to the compiler if possible
I don’t understand why signalling the key is a constant function has anything to do with the body expression being “simple”. That seems apples and oranges?
Also I’m surprised that a with-continuation-mark could be “dropped”, ever, because of the key or value or body expression or whatever being “simple” enough.
I feel like I’m missing something really basic here.
Maybe down the line. This was just an experiment. More polishing is needed for a package.
The expression (with-continuation-mark E1 E2 E3) is equivalent to (begin E1 E2 E3) if E3 is simple in the sense that it never inspects continuation marks and you can’t somehow interrupt the thread and be sure that it is currently in E3. In that case, no mark for the key produced by E1 needs to be set on the current continuation — at least, as long as the key isn’t chaperoned, because setting a mark for a chaperoned key is potentially observable in itself.
It happens that lambda is something that the compiler reliably recognizes as “never produces a value can can be chaperoned via chaperone-continuation-mark-key”, but it’s also sufficiently generative to work as a key.
… or, at least, that’s the case for the BC compiler. I see that it’s a place for improvement in the CS compiler!
Ah — that makes sense. Thanks!
So in theory errortrace-lib is relying on this to be “generous” wrapping expressions in wcm.
In theory things like DrRacket and Racket Mode that use errortrace-lib — for better stacktraces, profiling, and/or test coverage — would be at least somewhat slower in CS.
In theory. Not that I’ve noticed that at a user level, so far.
Roughly, yes. Errortrace is still somewhat stingy, but it only tries so hard.
Thanks again for explaining. I was really just looking to learn. I didn’t mean to create a to-do item, even a someday/maybe one! :disappointed:
:slightly_smiling_face:
It turns out that CS does recognize an identifier bound to a procedure as something other than a chaperoned key (which is the relevant case for errortrace). It just doesn’t recognize an immediate lambda form that way.
@spdegabrielle For the list of “real world” applications?
Towards a Dynamic Multiscale Personalized Information Space: Beyond application and document centered views of information Amy R. Fox, Philip Guo, Clemens Nylandsted Klokmose, Peter Dalsgaard, Arvind Satyanarayan, Haijun Xia & James D. Hollan. (2020) In Conference Companion of the 4th International Conference on the Art, Science, and Engineering of Programming (’20), March 23–26, 2020, Porto, Portugal. Proceedings of the Convivial Computing Salon at PROGRAMMING 2020. ACM, New York, NY, USA, 8 pages. https://doi.org/10.1145/3397537.3397542\|https://doi.org/10.1145/3397537.3397542
Wow, stateless servlets are really interesting.
Yes! I found another paper(version?) that is dated to 2020 but I’d love to date the Sony deal.
That would be interesting.
It’s also a fascinating area of research so thanks for that too!
@mflatt is compile-context-preservation-enabled supposed to work in Racket CS in the same way as in Racket BC?
Consider:
#lang racket
(define (show e)
(pretty-print (continuation-mark-set->context
(exn-continuation-marks e))))
(with-handlers ([exn:fail? show])
(for ([x 1])
(/ 1 0)))
Racket BC could report the site of for-loop when compile-context-preservation-enabled is on.
On the other hand, Racket CS’s continuation-mark-set->context gives the same result regardless of the value of compile-context-preservation-enabled.
which doesn’t have the site of for-loop
FWIW http://racket-stories.com\|racket-stories.com works with no state (except the database). The source is on Github, if you are interested.
For CS, compile-context-preservation-enabled currently disables inlining only at the schemify layer. Probably it should also disable inlining at the Chez Scheme level. I don’t know if that’s what’s going on in this example, though.
Is there a list of futures-friendly operations? I’ve looked in the docs, but haven’t found one.
fl :)
There is no list, unfortunately. I think the practice has been to use the futures visualizer to find out which things are not futures-friendly. For CS, it’s somewhat easier to guess what is in the list, since a non-friendly operation is one that has to synchronize at the Racket thread level or inspect continuation marks (as opposed to one that happens not to be special cased in the JIT for BC).
On Hacker News today. https://mendhekar.medium.com/why-i-still-lisp-and-you-should-too-18a2ae36bd8
is racket 8.0 going to be released tomorrow o: ?