Floating point numbers are notoriously ‘inaccurate’ as they are an approximation and so using equality with them is very hit and miss. See https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html for a full explanation.
@gregor.kiczales for the teaching languages, DrRacket sets the read-decimal-as-inexact parameter to false (I don’t know the details how the teaching languages are mapped to reader settings, though, sorry). If you’re are feeding the sandbox evaluator text, then I would expect a sandbox set up for the teaching languages to have the right reader settings already. But if you’re feeding the evaluator S-expressions (or syntax objects), it’s probably already too late; the numbers have already been read using the enclosing environment’s rules, which default to inexact numbers.
What exactly is going on here? Is it that the value of json-null in the type of JsonExpr is determined when you require it? Or when you define the module?
@maxsnew the code for typed/json pretends that json-null doesn’t exist, and that thus null in json is always translated to 'null in Racket
of course, that’s not right, and so you can make string->json produce values that don’t fit the JSExpr type it’s supposed to have
which triggers a contract error, similar to if the type for JSExpr was String or something else totally wrong
these types are trusted?
no
sorry I meant is this ordinary typed racket code? Why does it type check?
Is it because you just “ann” some untyped code?
fundamentally the issue is the same as if you write (require/typed racket/base [string->number (-> String String)])
right so it’s not really typed code
typed/json is typed code
But it’s just a require and provide essentially?
yes
ok so I don’t really see what Matthias is so up in arms about
could you make a version of this that worked correctly with the parameterization using typed units?
that would be a different approach to the parameterization, and I don’t think typed units support type parameterization that way
right not the same library
but @dan would know better
Matthias is making two points — 1 that I don’t understand about getting around the boundary, and 2 that it’s not the untyped code’s “fault” that it failed to live up to the contract
I think the second point is about error messages and debugging approaches, rather than a formal claim
agreed
Also would there be some type in TR that says “precondition: #:null is ’null?”
though what liberalartist just proposed is more reasonable/faithful
(to what TR is doing)
(typed/json rather)
it’s easy to make the type require the #:null keyword argument and require that it be the symbol 'null
but that sounds annoying to use
does that mean you would always have to supply the #:null keyword?
or would it “just work” if the json-null parameter is ’null?
you’d always have to supply it
TR can’t reason about the current values of parameters
oh ofc duh
@ryanc and others. thanks, very helpful
I guess I had gotten used to the exact numbers of the teaching languages and somehow thought they were default in Racket.
question about raco pkg install --scope-dir option if I use that option, then dependency checking ignores any packages already installed under -i or -u scopes and will attempt to install the entire dependency tree of a package, including base and racket-lib even though they already are present in the installation scope. Is that intended?
The original intent was for a scope directory to be even more “installation” than installation – so, something like “/usr/share/.…” while installation is “/usr/local/share/….“. But the package-search configuration lets you order the directories either way. I think probably --scope-dir should pay attention the search order and look in directories later than the specified one in the search list. That would be a change to get-scope-list in “pkg-db.rkt” to use the same member-based approach as used for 'user or 'installation.
I think that would be a welcome change, I can take a look and see if I can make the change myself. My motivating reason was to create binary libs for a set of pkgs and their dependencies so I was hoping to be able to install the source versions and their uninstalled deps into a —scope-dir directory, and run raco pkg create —binary-lib over the installed pkgs. That approach didn’t work due to the above complication. Do you have a better suggestion?
Ideally I’d like to be able to take advantage of automated dependency management and avoid needing to locate each missing package to create the binary lib version from. I’m assembling a minimal Racket distribution for a particular application.
I’ve made no further progress on this. @samth, any other info would be appreciated, though it’s not urgent
I don’t really have any further suggestions right now, I would open a bug report