Do I read this correctly?

https://github.com/racket/readline/blob/master/readline-lib/readline/rktrl.rkt#L199

(cond [(and (not use-cs-other-thread?) (eq? 'chez-scheme (system-type 'vm))) where use-cs-other-thread? is defined as:

(eq? 'chez-scheme (system-type 'vm)) Wouldn’t this make the first branch always a dead code?

@mflatt

it’s a predicate for detecting if cond is messed up (/s)

For planning purposes, @asumu, will the PPA builds for this be out soon?

Yes, it’s dead code with the current definition of use-cs-other-thread?. The intent (and use while developing) was to be able to turn that code on and off. Since the use-cs-other-thread? mode has worked out, it would make sense to clean up the dead code.

Assuming no modification between calls to a hash table, are hash-keys and hash-values guaranteed to return the same order (even though the order is unspecified)? E.g. the 3rd key in the returned key list would be guaranteed to match with the 3rd value returned in the values list?

Or should I be certain by doing hash->list and mapping to get keys/values?

Or use in-hash

Is there a particular reason why a string is not a valid JSON key?

Allowing strings would make JSON not always round-trip

There might be other reasons but that’s a significant one

There’s also a discussion at https://github.com/racket/racket/pull/1878

oh wait, I misunderstood. Meant to write https://github.com/racket/racket/pull/1877, but there’s no discussion there

I mostly think that something like that PR would be very valuable, but it’s somewhat of a change from how JSON works in Racket

that doesn’t really make much sense. All strings can be turned into symbols, so it’s pretty much moot. For example:

(write-json #hasheq((\|foo bar\| . 10))) ;=> {"foo bar":10}

Right now, if you have a value and you write it to JSON and the read it back, you get an equal? value.

Allowing strings would make that not true.

Maybe the property isn’t worth it, but that’s a reason why it hasn’t been done.

Strings can be equal? just fine. How would that make it not true? Do you mean that you might write a string key and get back a symbol key?

Right

By the way, relatedly, the author of the PRs I mentioned above has some dissatisfaction with Racket. I don’t know if you have already seen it: https://lobste.rs/s/6rnyn9/why_i_no_longer_contribute_racket#c_fqqb9n

You would always get back a symbol key

Yes, I saw that he was dissattisfied with the response to those PRs.

The equal? requirement I find… uncompelling.

But, it isn’t my code, and I know people who are uncompelled w/ many of my reasons in my code.

Keeping the equal? requirement, but forcing all keys to strings would probably be more inclusive, but it’d likely break a lot of existing code that uses eq? for key comparisons.

It would actually just break existing code.

(hash 'a 1) would not be a valid jsexpr? anymore

true there, too

I think more broadly there are two ways to think about JSON integration into Racket. One is to say “here’s a nice way to write JSON in Racket, by defining some Racket data that maps to and from JSON”. That’s basically what the json library does. Another is to say “I want to serialize my specific kind of data, and potentially deserialize it from JSON into my data structures, and I don’t need to worry about confusing it with other JSON use”. That’s a very valid thing to do, and it’s not served as well by the json library.

I don’t have strong opinions on the value of equal? , but the inability to use strings as keys seems to surprise every new developer trying to do something in Racket (including me), so I do suspect we could call more prominent attention to it in the docs.

It could even be parameterized when writing JSON to allow string keys

(parameterize ([json-i-understand-string-keys #t]) ...)

should read-json also interact with json-i-understand-string-keys?

Nah, IMO it’s less important. But that’s w/ only 2 min of thought put into it

Another option would be to “subclass” hasheq and just make a json-hash object that “did the right thing” when adding non-symbol keys (like implicitly convert strings -> symbols or error out)

yeah, i’m constantly hitting frustrations w/ writing json. e.g. having to use a list for an array, even though in-application usage of a vector is far more efficient for my use-case. This means having to copy a very large vector to a list just to write it out as JSON.

Very frustrating

I have a not ready for pkg server json library that allows a little more control over json parsing. https://github.com/samdphillips/racket-stream-json

Also undocumented.

Is anyone (or ryanc) able to edit the answer? The expression (free-identifier=? #'x2 #'x2) should be (free-identifier=? #'x1 #'x2). Stackoverflow rejected my edit suggestion and wanted me to change at least 6 characters. https://stackoverflow.com/a/6852466/2013713

Done!

Relatedly, I think it would be nice to explain somewhere how free-identifier=? and bound-identifier=? are useful and in what situation which variant you should use.

Thanks! Embarrassingly, I don’t really understand what they are doing and usually just make try a few examples to see if things work out

Well, me too I guess…

free-id is “do these refer to the same binding” bound-id is would one shadow the other

The only situation you should use the latter, basically, is to check for uniqueness in a binding form

(there are other uses but I’ve never needed them)

free-id is relatively understandable. But for the shadowing interpretation of bound-id, what is the context that makes this well-formed (kind of)?

What do you mean by well-formed?

Should I read it as: if bound-id is called in a transformer, and if both identifiers are used in binding positions in different let-forms in the output of the transformer, and that one let-form is nested in the body of the other let-form, then the binding introduced by one id will definitely be shadowed by the binding introduced by the other one

Otherwise I’m not sure how to read “shadowing”

Yes, that’s the idea

okay I see

I think the caveat in the paper you quoted says that “definitely” might not be right

But that’s the idea

Hmm, I thought the paper says: if bound-id is true then shadowing will definitely happen. otherwise nothing is promised

A simpler statement is that if a and b are bound-id=? then (lambda (a) b) is the identity

It says that there are some cases where bound-id produces false but shadowing still happens

It’s not defined to be a conservative approximation, it’s defined to be “has the same scope sets”

Thanks!! I have another question. Is bound-id symmetric because it is defined to be testing whether the two ids have the same scope set?

Yes

Here’s the code, which is symmetric by inspection: https://github.com/racket/racket/blob/master/racket/src/expander/syntax/scope.rkt#L966-L970

I see the symmetric description in the doc (which does not refer to scope sets) and also in Chez’s user guide. I guess the “binding” intuition appeared before scope sets, but it’s surprising that symmetricity looks like a requirement https://scheme.com/tspl4/syntax.html#./syntax:s37

they’re equivalence relations; they’re supposed to be symmetric

Hmm, is being a equivalence relation a spec or a implementation fact? Because I don’t see why “a binds b” (as in (lambda (a) b) )has to be an equivalence relation

That doesn’t have to be an equivalence relation, but functions named =? are supposed to be

ah okay, indeed