Opening Pollen source in DrRacket causes no-arg call to root #268

Closed
opened 2 years ago by otherjoel · 8 comments
otherjoel commented 2 years ago (Migrated from github.com)

Using Racket 8.4.0.8 on macOS/AArch64, in a folder with this pollen.rkt:

#lang racket/base

(provide (all-defined-out))

(define (root . elems)
  (println "BOO")
  `(root ,@elems))

—and another file test.html.pm:

#lang pollen

Hello!

Simply opening test.html.pm in DrRacket will cause the REPL to open and display the results of an apparent call to root with no arguments:

image

If the definition of root for the current project assumes that it is called with at least one element, then simply opening a Pollen source instantly gets you a REPL with an error and “Interactions disabled”. If you do actually “Run” the file, the REPL displays the expected result.

I could be wrong (I’m starting to revisit Pollen projects after a few months away) but I am pretty sure that this is new behavior. I don't recall ever having to build checks for “called with no elements” into any of my Pollen projects before.

Using Racket 8.4.0.8 on macOS/AArch64, in a folder with this `pollen.rkt`: ```racket #lang racket/base (provide (all-defined-out)) (define (root . elems) (println "BOO") `(root ,@elems)) ``` —and another file `test.html.pm`: ``` #lang pollen Hello! ``` Simply opening `test.html.pm` in DrRacket will cause the REPL to open and display the results of an apparent call to `root` with no arguments: <img width="545" alt="image" src="https://user-images.githubusercontent.com/1553115/162483512-49bec096-6a82-4ea8-be3f-46b866d058ad.png"> If the definition of `root` for the current project assumes that it is called with at least one element, then simply opening a Pollen source instantly gets you a REPL with an error and “Interactions disabled”. If you do actually “Run” the file, the REPL displays the expected result. I could be wrong (I’m starting to revisit Pollen projects after a few months away) but I am pretty sure that this is new behavior. I don't recall ever having to build checks for “called with no elements” into any of my Pollen projects before.
mbutterick commented 2 years ago (Migrated from github.com)

This sounds like a new (Dr)Racket bug related to the auto-running behavior. I’m on 8.3.0.7. The Pollen source does not auto-run when opened, and when I explicitly hit Run I get the right result:

Welcome to DrRacket, version 8.3.0.7 [cs].
Language: pollen [custom]; memory limit: 2000 MB.
"BOO"
'(root "Hello!")
This sounds like a new (Dr)Racket bug related to the auto-running behavior. I’m on 8.3.0.7. The Pollen source does not auto-run when opened, and when I explicitly hit Run I get the right result: ``` Welcome to DrRacket, version 8.3.0.7 [cs]. Language: pollen [custom]; memory limit: 2000 MB. "BOO" '(root "Hello!") ```
rfindler commented 2 years ago (Migrated from github.com)

When opening a file in DrRacket, DrRacket will runs a program that consists only of the #lang line (so in this case, the program that has only #lang pollen). Could that explain this behavior?

The reason DrRacket does that is to try to get a reasonable initial namespace for the interactions window. The hypothesis I had (apparently wrong!) is that an "empty" program wouldn't have any particular effects but would result in a reasonable set of bindings in a namespace. If there's some other heuristic I could employ to try to get a reasonable initial setup for that first interactions window, I'm game to try it.

When opening a file in DrRacket, DrRacket will runs a program that consists only of the \#lang line (so in this case, the program that has only `#lang pollen`). Could that explain this behavior? The reason DrRacket does that is to try to get a reasonable initial namespace for the interactions window. The hypothesis I had (apparently wrong!) is that an "empty" program wouldn't have any particular effects but would result in a reasonable set of bindings in a namespace. If there's some other heuristic I could employ to try to get a reasonable initial setup for that first interactions window, I'm game to try it.
otherjoel commented 2 years ago (Migrated from github.com)

That might even still work in this case, if it were possible to run the empty program in such a way as to ensure that an upward search from current-directory would never find a pollen.rkt module.

That might even still work in this case, _if_ it were possible to run the empty program in such a way as to ensure that an upward search from `current-directory` would never find a `pollen.rkt` module.
rfindler commented 2 years ago (Migrated from github.com)

Is that something that can be done from within pollen? I'm not sure that that would be generic enough to put into drracket (since it would then apply to all languages).

Is that something that can be done from within pollen? I'm not sure that that would be generic enough to put into drracket (since it would then apply to all languages).
mbutterick commented 2 years ago (Migrated from github.com)

The hypothesis I had (apparently wrong!) is that an "empty" program wouldn't have any particular effects

Pollen is a popular Racket package. Like other popular packages, it brings new users into Racket. If the Racket maintainers are going to ship compatibility-breaking changes (especially in a minor release) without testing against popular Racket packages, it is a strong negative signal to the users and maintainers of these packages.

Beyond the behavior observed here, it should be apparent why “run an empty source file on startup” is a bad idea:

  • an empty source file may raise an error because it’s syntactically invalid (e.g., web-server/insta)

  • an empty source file may still incur expensive startup costs (e.g., open a database connection, load disk cache)

  • an empty source file may have irreversible or one-shot side effects (e.g., run is logged to disk)

  • more broadly, the #lang line triggers execution of another source file, which can contain anything, so this new policy incurs the risk of unbounded side effects, including failure to terminate.

FWIW as a UI matter, this is not behavior anyone reasonably expects when opening any source file in any code editor.

Still, I am always willing to investigate bona fide bugs. If Pollen is violating documented Racket behavior, guidelines, norms, etc. — please post a link. The parts of Pollen that cooperate with DrRacket have not been changed in at least four years. That doesn’t mean they’re correct, but they are stable.

If DrRacket seeks certain information from a #lang, one might’ve supposed that the correct approach is for DrRacket to query the #lang using the affordance that exists for exactly that purpose: the get-info function (with a key like drracket:whatever-you-want).

> The hypothesis I had (apparently wrong!) is that an "empty" program wouldn't have any particular effects Pollen is a popular Racket package. Like other popular packages, it brings new users into Racket. If the Racket maintainers are going to ship compatibility-breaking changes (especially in a minor release) without testing against popular Racket packages, it is a strong negative signal to the users and maintainers of these packages. Beyond the behavior observed here, it should be apparent why “run an empty source file on startup” is a bad idea: * an empty source file may raise an error because it’s syntactically invalid (e.g., [`web-server/insta`](https://docs.racket-lang.org/web-server/run.html#%28mod-path._web-server%2Finsta%29)) * an empty source file may still incur expensive startup costs (e.g., open a database connection, load disk cache) * an empty source file may have irreversible or one-shot side effects (e.g., run is logged to disk) * more broadly, the `#lang` line triggers execution of another source file, which can contain anything, so this new policy incurs the risk of unbounded side effects, including failure to terminate. FWIW as a UI matter, this is not behavior anyone reasonably expects when opening any source file in any code editor. Still, I am always willing to investigate bona fide bugs. If Pollen is violating documented Racket behavior, guidelines, norms, etc. — please post a link. The parts of Pollen that cooperate with DrRacket have not been changed in at least four years. That doesn’t mean they’re correct, but they are stable. If DrRacket seeks certain information from a `#lang`, one might’ve supposed that the correct approach is for DrRacket to query the `#lang` using the affordance that exists for exactly that purpose: the [`get-info` function](https://docs.racket-lang.org/guide/language-get-info.html) (with a key like `drracket:whatever-you-want`).
rfindler commented 2 years ago (Migrated from github.com)

These are good points. Thank you.

These are good points. Thank you.
otherjoel commented 2 years ago (Migrated from github.com)

Thanks to both of you for looking at this. It is at least clear to me now that this is not a Pollen issue!

Thanks to both of you for looking at this. It is at least clear to me now that this is not a Pollen issue!
samth commented 2 years ago (Migrated from github.com)

That heuristic seems somewhat worrying in other cases as well. For example, writing this module with #lang s-exp "wrap.rkt" would mean opening it in DrRacket would run the whole program.

That heuristic seems somewhat worrying in other cases as well. For example, writing [this module](https://github.com/racket/racket/blob/master/pkgs/racket-benchmarks/tests/racket/benchmarks/common/collatz-q.rkt) with `#lang s-exp "wrap.rkt"` would mean opening it in DrRacket would run the whole program.
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: mbutterick/pollen#268
Loading…
There is no content yet.