I think you need to run the tokenizer

Is it possible to (easily?) extend read-syntax to turn comments into syntax objects too?

I think you can do that by adjusting readtable, but I don’t think it will play well with the rest of the system.

For example, if you have (if x #\| abc \|# y z). Now if have 4 subforms. Suddenly every macro needs to take care of these comment syntax object.

What might make more sense is to attach the comment information to the enclosing syntax object’s syntax property.

Good thinking!

Works for me. However you cannot use ,rr successfully for the first load. What I do is:

Welcome to Racket v7.9 [bc]. > ,rr foo.rkt ; requiring "foo.rkt" > ,r foo.rkt > foo 4 > foo 4 > ,rr foo.rkt ; reloading "foo.rkt" > foo 0 So first ,rr to tell the REPL that I want this file to be reloadable, then you can load it, and then reload.

I don’t know if this is the intended use, I remember being bitten by this in the past, and the documentation is not that clear. With typed racket I never got this to work the way I expected and always had to exit the REPL.

Ah. That makes at least some sense, even if it’s awkward

Here’s the now-obvious workaround for this. Though I don’t have the y-coordinate of r (which is an x-coordinate), I have two possibilities for y: either modsqrt(r^3 + 7) or -modsqrt(r^3 + 7). So I can generate two transactions and then try to recover the public key from both. One of the transactions will give me a public key that does not match the right one (and I know the right one) and I throw the other transaction away. It is not the most efficient thing to do, of course, but I’m happy to have this solution right now. Thanks very much for your attention!

I didn’t notice this on Slack until just now — thanks!!!

Yeah, almost anything with intermediate lists could probably be for-ized

(I mean “could be” by a human refactorer. If a machine could do it safely even better!)

When talking about expressions in tail position, “tail position” is succinct. Is there some phrase that’s shorter than “the expression with respect to which the expression is in tail position?” :eyes:

Why I ask: I recently updated Racket Mode to show tooltips for these two things (it can’t draw arrows like DrRacket does).

I settled on showing “head” and “tail” for these two things. I think “tail” is OK but I don’t love “head”. So I’m open to suggestions!

Shorter is better because tooltips take space. Also a given position might have multiple annotations displayed. e.g. an open paren in typed/racket program might show 3 combined Number; tail; imported from typed/racket/base.

“outer” comes to mind? or “parent” maybe?

Non-tail?

Nope. That’s different

front?

top?

‘parent’ seems fine to me

‘enclosing’

I think “enclosing” is the best so far

It doesn’t need to be enclosing syntactically though, right? (with help of some insane macros)

“enclosing” can be a feeling in your heart rather than a rigorous statement about surrounding source code

@notjack like a hug?

exactly

and while @sorawee is technically correct that by using mutation you could construct something like that, it would be horrible and you shouldn’t

I gotta say that reading, "“enclosing” can be a feeling in your heart" made my day :)

Can I get a quick check on something? Is this code: (let ([v <expr>]) (or (and v <expr-not-returning-false-or-referencing-v>) <expr-not-referencing-v>)) Equivalent to this: (if <expr> <expr-not-returning-false-or-referencing-v> <expr-not-referencing-v>)

I think so. I saw a and b or c as a trick to write if somewhere, but it only works when b is not falsy.

Hmm so maybe two separate checks then: • One that rewrites (or (and a b) c) to (if a b c) when it can prove that b is not falsey • One that inlines let expressions when the variable is only used once and doing so wouldn’t change evaluation order (though maybe this one isn’t a worthwhile idea?)

Thanks everyone! I think I’ll go with “enclosing” :people_hugging::people_hugging::people_hugging:

The second one is a potential compiler optimization but I would assume the let is there for a reason

The meaning to a human could be different After all, that <expr-not-returning-false-or-referencing-v> won’t be false could be an inferred fact that the programmer should not need to think about

@samth in the code I’m looking at, the reason is “this used to be scheme code and shoving let in random subexpressions was the easiest way to make variables”

@shu—hung I was only planning on firing in cases where the expression is something like 42 or (list …) or a quoted expression, since those seem like fairly noncontroversial cases

Personally, I would still treat the two as different programs and won’t apply this rule. This is because the or form expresses the intention to choose the first non-false option. The first option, in this case, is guarded by <expr>. And it could be that <expr> is not intended to be interpreted as a choice between <expr-not-returning-false-or-referencing-v> and <expr-not-referencing-v>.

So there could be a logical connection between <expr> and <expr-not-returning-false-or-referencing-v> but not <expr-not-referencing-v>.

I don’t think either form of the program conveys enough meaning on its own to justify one form or the other purely on programmer intent.

The best way to declare that kind of intent is to make a helper function and put the intent in the name.

Choosing the first non-false values using or is pretty idiomatic in Racket But probably each program is different

In general yes, but for the specific case of (or (and a b) c) where b can’t be #f, I think if would be more idiomatic since there’s no way a could possibly be returned anywhere

I’m having a strange issue with http-easy: &gt; (require net/http-easy) &gt; (define chic-url "<https://raw.githubusercontent.com/Z3tt/R-Tutorials/master/ggplot2/chicago-nmmaps.csv>") &gt; (subbytes (response-body (get chic-url )) 0 50) #"city,date,death,temp,dewpoint,pm10,o3,time,season," &gt; (port-&gt;bytes (response-output (get chic-url ))) #"" I would expect those two approaches to produce the same bytes, but I always get an empty byte string when I look at response-output. @popa.bogdanp

response-body drains the response output port

erp. Maybe I should read more carefully that you aren’t reusing the same response twice

I think you need #:stream? #t in your get call…

> (port->bytes (response-output (get chic-url))) #"" > (subbytes (port->bytes (response-output (get chic-url #:stream? #t))) 0 50) #"city,date,death,temp,dewpoint,pm10,o3,time,season,"

Aha, thank you!

(Maybe I’ve asked this before; I can’t remember…) When using define-generics, is there a way to specify that a method is non-optional?

(Other than using contracts that check for implemented methods.)