Open blerner opened 3 years ago
wrap
should just be removed as vestigial.
It was necessary when PyretNumber
, PyretString
, etc were represented as objects, which hasn't been the case for years, and also when we tried to wrap functions more. There aren't any uses of .wrap
in pyret-lang
, so my best guess without doing a deep history/blame dive is that it got effectively removed in pyret-lang
without its occurrences being removed in code.pyret.org
and hence images.
I'm happy to do this in a standalone commit, wait until other image work you're doing is done, or whatever is more convenient.
Consider the following expression (on current CPO):
image-pinhole-x(point-polygon([list: point(0, 0), point(2.5, 0), point(32, 0)], "solid", "red"))
. It will evaluate to11.5
-- but it's a broken 11.5. It's not an instance ofRoughnum
, but it is a raw JS number, so it renders as a raw JS number, and doesn't render as a fractional quantity. The problem seems to be here, in runtime.js:The definition of
jsnums.isPyretNumber
then saysand
makeNumberBig
saysWe use
wrap
all over the image library, and probably elsewhere too, so it seems quite odd to me thatwrap
doesn't actually wrap numbers correctly... I'm not sure exactly what the right fix should be, though, since I don't thinkwrap
has enough information to know whether to make an exact number or a roughnum. And I don't know what exactly we ought to do in the image library, short of using jsnums.* everywhere instead of raw JS arithmetic, to ensure that we create rationals when we can do so... It seems reasonable that our image library has to discretize its answers to the pixel grid, so things like "what's the pinhole location?" ought to be a rational at worst, if not also forced to an integer on the pixel grid as well...