这是indexloc提供的服务,不要输入任何密码
Skip to content

Add typed/json which exports almost all of json #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Add typed/json which exports almost all of json #3

wants to merge 1 commit into from

Conversation

lexi-lambda
Copy link
Member

This doesn't include jsexpr?, nor does it support for custom JavaScript nulls, but is otherwise entirely functional. The former has been excluded due to its inability to be typechecked properly (see this SO question and this mailing list thread). The latter has been excluded for similar reasons as well as its relative uselessness.

I've been using these type definitions in working code for some time, and I've encountered no problems despite those missing bindings.

@samth
Copy link
Member

samth commented Dec 21, 2014

This is great. I think we should include a type for jsexpr? even if it doesn't have the predicate we would want.

@lexi-lambda
Copy link
Member Author

@samth Alright, updated to include jsexpr?.

Does not include support for custom nulls, but is otherwise entirely
functional.
@samth
Copy link
Member

samth commented Dec 21, 2014

@AlexKnauth commented about a possible problem, but the comment seems to have disappeared. He said:

Won't something like this break it?:
typed.rkt:

#lang typed/racket
(require typed/json)
(require/typed "untyped.rkt" [change-null (-> Void)])
(change-null)
(ann (string->jsexpr "null") JSExpr) ; #<procedure:not-a-jsexpr>

untyped.rkt:

#lang racket
(provide change-null)
(require json)
(define (not-a-jsexpr) "whatever")
(define (change-null)
  (json-null not-a-jsexpr))

@samth
Copy link
Member

samth commented Dec 21, 2014

However, just to reply to Alex, I think that will produce a contract error in string->jsexpr. So it doesn't seem like a problem to me.

@AlexKnauth
Copy link
Member

I took it away because I realized it wouldn't be a problem because it would produce a contract error.

@samth
Copy link
Member

samth commented Dec 21, 2014

@AlexKnauth I think it's useful to have thought about it, so thanks! Next time, feel free to just add another comment.

@samth samth closed this in 9fe834d Dec 23, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants