symbols to export for essentials2023 context
Opened this issue · 21 comments
- num-sqrt and sqrt
- num-expt and expt
- num-sqr and sqr
- num-abs and abs
- flip-vertical and reflect-x
- flip-horizontal and reflect-y
- scale and dilate
- put-image and translate
- num-cos and cos
- num-sin and sin
- num-tan and tan
- num-random and random
Hmm, I really don't like the namespace inconsistency of removing the num- prefix, for things that go in the bog-standard-default namespace. That seems like a big regression to me, in terms of rationalizing the default imported names. I'd prefer if we had a bootstrap-essentials2023 context for things like this, plus the drop-down context chooser that we talked about elsewhere. @jpolitz or @shriram , what're your thoughts here?
to be clear - nobody is suggesting removing the old aliases.
I'm also happy to have a Bootstrap-specific context, but this opens up the "discover curated contexts UI" question
Right: adding new aliases while not removing old ones, and ad-hoc names without namespace-prefixes, just makes the global namespace issue worse.
Having short names for bootstrap is a worthwhile goal. Polluting the global namespace is an anti-goal...
@blerner OK, so you're ok with a curated dropdown of contexts in the "Choose Context" menu? Note that this is starting to replicate DrRacket's "Add teachpack" UI...
I'm more ok with that, yes. I'm also mulling the idea of allowing supplying the context as a URL parameter, so that teachers can create a short-URL that drops students right into the correct context.
Seems like I no longer need to weigh in? (-:
I'm fine with adding the listed names to the next essentials (and potentially to image) alongside the existing names.
I also really like the idea of the dropdown/URL infrastructure for contexts.
But the names suggested here (as motivated by Bootstrap) are a reasonable proxy for “stuff first-time programmers could probably use”. Putting it in essentials-202X only breaks e.g. tutorials that tell someone to type into an empty buffer.
There is one other interface suggestion worth making here. @schanzer points out that one reason to want them in essentials is that teachers will go to code.pyret.org and click the "Start Coding" button. Other tools, when you click the corresponding button, have a modal that shows up the first time for “what kind of project are you starting”. That could be the right place to make that selection.
I would love a "what kind of project are you starting?" UI. That puts this all front-and-center.
how about num-expt and expt?
is there a place for negate (which we use in early math)?
@retabak good call on num-expt. added
negate does not already exist in Pyret. This issue is about providing alternative symbols for ones that already exist
@schanzer are pi/e part of this? Can easily add to starter2024. Didn't see them in the top list, didn't know if that was the canonical list.
@jpolitz yep! the corresponding issue in pyret-lang can probably be closed once you add these
@jpolitz just added the basic trig functions to the list. Hopefully these are easy to add.
@schanzer a request that may seem a little silly but would help me a lot – could you write a short check/examples block that uses all the identifiers you want included on trivial inputs? That will be the spec for what ought to work. Something like:
sqrt = ...
expt = ...
check:
sqrt(1) is 1
expt(2, 3) is 8
...
end
and so on. This would help me rule out typos and also be a useful agreement on what this is accomplishing. Share link to CPO or just paste it here.
I was surprised to find that random already exists without the num- prefix!
@jpolitz not sure if this is related to the constants context, but it would be pretty great to have these symbols available by default as well
(Think I have this, just confirming) should PI and E be in this file, too? That is, I'm going to include this as part of the spec, too:
import constants as C
E = C.E
shadow PI = C.PI
check:
...
cos(PI) is-roughly ~-1
sin(PI / 2) is-roughly ~1
num-exp(1) is-roughly E
end
Yes - and IIRC, Shriram wanted both the upper- and lower-case versions of both.
Is there any reason you needed to shadow PI? Pretty sure the definition comes from constants anyway, so you should be able to just include constants or import constants as C / provide from C: * end
Right, but PI is provided by essentials2021 and E is not, and to keep the spec runnable that's needed.
The other spec is that all the imports + definitions should go away and the check block should still succeed if the context is starter2024!
And for the default namespace we don't want e and pi because that will be really annoying w/shadowing of e.
Both of your comments help clarify that my goal is the starter2024 namespace spec, not necessarily just the constants change