horizon -> master

[jpolitz]

PR includes use context and small bugfixes.

[jpolitz]

So here's a fun problem @shriram @blerner that I just thought about. Right now it's tough to define essentials2021 in pyret-lang, because image isn't defined here. So essentials2021 is only defined in CPO. That means if you copy some code from the web and run it on pyret-lang, essentials2021 will fail.

We could:

• Define a parallel essentials2021 in pyret-lang omitting some stuff
• Define a parallel essentials2021 in pyret-lang stubbing out things that won't work without a DOM
• Give some special error message for essentials2021 that gives guidance on switching to something else

In any event, I don't think we'll wreck command-line only users at all, because nothing will change if they are only command-line users. And copying from command-line to CPO will work. The only direction that requires some new thought is copying from CPO to command-line, and what to do about innocuous programs that don't use image, but do use context essentials2021, which need some help.

[shriram]

Just curious: shouldn't what happens be exactly analogous to writing include image in CLI Pyret? From the POV of essentials2021 nothing should change: it should be the same code. Or is it that that is what happens, but the CLI will error, which is fine if you have just one command at a time (you can remove it and move on), but that error will cause the entire library to fail to load, and the user is left with no usable language at all?

[blerner]

Just curious: shouldn't what happens be exactly analogous to writing include image in CLI Pyret?

Yes

From the POV of essentials2021 nothing should change: it should be the same code.

Right

Or is it that that is what happens, but the CLI will error, which is fine if you have just one command at a time (you can remove it and move on),

I very strongly do not want "oopsies, throw out individual bad statements" as our semantics for Pyret -- that repeats one of the worst weirdnesses of JS programming (where an individual script can be silently ignored). I know that the chatitor interface on #anchor behaves like this, and it's the part of that approach that I like the least -- I don't want whole-file compilation to ever have this behavior.

but that error will cause the entire library to fail to load, and the user is left with no usable language at all?

Right. Hence the problem.

[blerner]

I'm somewhat inclined to not have essentials#### (or any context besides empty) be baked into the compiler. I'd almost rather have a layer of indirection, such that they redirect to <some host url>/essentials####, where the host url can be different for CPO and the CLI, so that we serve different contexts in...different compilation contexts ;-)

[jpolitz]

I'd almost rather have a layer of indirection, such that they redirect to /essentials####, where the host url can be different for CPO and the CLI

I'm reluctant to have the CLI require an internet connection for something so routine. And in any event, this still requires maintaining two versions of a thing with the same name, it's just a different mechanism for it, right?

I think essentials2020 may have to be part of the CLI standard library (note, that doesn't necessarily mean “in the compiler”, it just happens that these live in the same repo right now) in order to make legacy behavior be consistent and future-compatible, but essentials2020 doesn't have image, so that works.

After reading this thread, for stuff essentials2021 and beyond, I started thinking more about a custom error message, here's some discussion.

We need that error message to tell the user what to do! So we may need an offline essentials, or a core2021, or similar. I don't really like it that they are different, but I don't see how to get around it long-term unless we try to stub out everything. The browser is just going to have different stuff (and even if we say “but someday, offline will be feature-equivalent”, we won't make image work offline right away, so folks will confront this).

Maybe:

“essentials2021 is the name of a context used on code.pyret.org that isn't available offline due to relying on some browser features. You can change it to core2021 for a context that implements the features that are available offline. You can also use the compiler option --builtin-arr-dir to provide a directory containing a custom essentials2021.arr file of your choosing.”

---

After writing that, I dislike it, because the natural next questions are things like “what's the difference between essentials2021 and core2021?” or “so what would I put in a custom essentials2021.arr file?”. The answer to these questions is “do the thinking we punted on when we released this.”

So in that sense, I feel like the CLI should come with an essentials2021.arr that's stubbed out with dynamic errors for all the things that won't work offline. We already do this for reactors, and image ought to behave the same from a user's point of view, because to have it not do the same kind of thing requires us to explain with compiler author hat on the difference between requiring a module vs. stdlib vs. syntax, and that's wrong for Pyret.

→ cat react.arr
include global
include reactors
r = reactor:
  init: 5,
  on-tick: lam(x :: Number): x + 1 end
end
r.interact()
→ npx pyret react.arr
1/1 modules compiled (react.arr)    
Cleaning up and generating standalone...
The run ended in error:
No interaction set up for this context (please report a bug if you are using code.pyret.org and see this message)
Pyret stack:
  file:///Users/joe/src/pyret-lang-anchor/react.arr: line 7, column 0

[shriram]

Or is it that that is what happens, but the CLI will error, which is fine if you have just one command at a time (you can remove it and move on),

I very strongly do not want "oopsies, throw out individual bad statements" as our semantics for Pyret

That isn't what I was saying at all. What I meant is that if you are entering a command at a time, you as the user have the ability to decide what to do when one particular import breaks. But if you just have a bulk context, that's like a transaction, so a failure in one part means you have nothing. In short, I'm agreeing with you on the (un)desired semantics.

[shriram]

So in that sense, I feel like the CLI should come with an essentials2021.arr that's stubbed out with dynamic errors for all the things that won't work offline.

This sounds like the most reasonable thing. Then all code works the same except when it accesses a feature that really can't exist, and then it only errors at the point where it tries to use that feature.