@elyandarin All of the above is fine. Though if you want a quick and simple solution, as I said above you can just use Racket’s reader itself:

(with-input-from-string my-str read) assuming that my-str is the string value you have read in your file, that starts and ends with ", and may have some quoted strings inside.

Note that read can also read numbers (with dots, exponents and all) and nested parenthesized structures, which is pretty handy.

Consider the following scribble/manual code:

@require[@for-label[txexpr]] Imperative app elements use @secref["printing" #:doc '(lib "scribblings/reference/reference.scrbl")] in @racket[write] mode to emit tagged X-Expressions. The zero or more written elements will replace the printing script element in the internal @racket[txexpr] representing the page. ... @racketblock[(require txexpr)]

txexpr is a collection that happens to be named after one of its provided bindings. This means a link is generated inside the racketblock that points to the provided binding from the collection, but not the collection itself. However, the @racket[txexpr] is appropriate in the context of the paragraph. Together, the links appear inconsistent.

Am I to understand that my only options are to either remove the @for-label[txexpr] and manually specify links, or use #:escape in every @racketblock that requires txexpr?

(My hidden question being “is there a more convenient option?”)

If “txexpr” is a general concept then naming it with @racket[txexpr] seems wrong and I’d use an @deftech to define it and @tech to reference it. As in https://docs.racket-lang.org/json/index.html?q=jsexpr#%28tech._jsexpr%29.

:+1:

but also note that racket string is very strict. For example, if you want to allow your string to have regex code, like \s , Racket will complain saying that \s is not valid.

How would I make a contract for something that’s a union type? I was expecting some type of (contract/or a b) thing but I haven’t seen anything like that.

or/c ?

Indeed. I did search through the docs for that, but it’s split up into four separate pages - the docs for racket/contract/base simply say it includes those four, so not as easy to find as I’d like.

While on the subject, is there a way to express things like generics such that two inputs must be the same type?

I think https://docs.racket-lang.org/reference/parametric-contracts.html ? I’ve never used these contracts myself. And I remember seeing something weird with them.

cool, thanks.

@willbanders This is a set of approaches I’ve been taking in situations where a generic operation needs to take more than one instantiation-determining argument:

• If one of the arguments is an obvious choice for instantiation-determining, just use that one. Otherwise, consider adding yet another argument specifically to act as the determiner.

• To let programmers assure consistency of the two inputs’ implementations, have one of the methods on the generic interface be an “accepts?” predicate or an “accepts/c” contract-generating function, and use that in the contract of the operation. Depending on the situation, something like an equal? check may be a sufficient substitute, but I’m betting that making “accepts” methods the user can customize will allow users to specify overly permissive contracts as a tradeoff for better performance.

• If a data structure needs to maintain an invariant based on a particular instantiation of a generic operation, such as a sorted set that needs all its keys to abide by the same ordering, store something that can determine that instantiation in the data structure. Then, for instance, the sorted set can operate only on keys that its favorite instantiation “accepts.”