

Woah, that’s a very nice effort!


“With the upcoming version 8.0 release, Racket on Chez Scheme (Racket CS) will become the default implementation of Racket.” Congratulations and thank you for the immense amount of work this has been. I can’t even comprehend it.

Thanks!

“throwing out around 200k lines of C code to replace it with around 150k lines of Scheme and Racket code.” That’s not really news, but still, woah!

Echoing Stephen, probably only few people ever write a project of 100k+ lines of code, so performing such a huge transformation while maintaining almost perfect backward compatibility is an amazing accomplishment that I can only applaud. Congrats Racket team!

glad to see that compose
is now so much faster!

what’s the actual name of the first-s...t-loop
test? (the slowest CS vs BC) Couldn’t find it by looking at the filenames

It’s first-some/prompt-loop
, I believe


How did you find it? Search in github returns not a single it for “first-some/prompt-loop”

Also, thanks!

Regex in Emacs :slightly_smiling_face:

of course :slightly_smiling_face:

It’s pretty impressive that there’s only 1 benchmark where CS is slower by more than a factor 2

I was about to open an issue that, at least in e.g. Racket 7.8 CS, continuation-mark-set->context
would return full paths until you do a raco make
and then it would return .../
prefixed truncated paths. But I double-checked and it looks like this is fixed in 8.0.0.3. Nice!

I hate to put stickers on my laptop, and in these quarantine days, who even would see it? But I’m tempted to add a big “I :heart: COMPLETE PATHS” sticker as a result of working on things for Racket Mode. :wink:

@apompa has joined the channel


8.* that just looks wrong :slightly_smiling_face:

Thailand uses the Buddhist calendar. But I haven’t used it for so long that I got it off by two years. That is, I thought 2021 is still 2019.

:slightly_smiling_face:

I noticed that the first email from Matthew about Chez is dated January 27, almost exactly 4 years ago

it has been 0 days since I had an extremely confusing bug in a syntax-parse
macro that was caused by writing #:with (id …) #'some-id

Is there a standard procedure or form for taking a sequence (or just a list) and splitting it into several sequences (or lists), using only one traversal?

group-by?

Hm, that might be what I’m looking for, though I’m not sure how I’d express what I’m doing.
What I’m trying to do is turn (listof (or/c A B C))
into (listof A)
, (listof B)
, (listof C)
.

If you’re using match
to destructure the first thing into a list like '(a b c)
, you could use app
to make each one be (listof a)
as each one is matched. I think that counts as one traversal.

e.g. #lang racket/base
(require racket/match
racket/function)
(match '(listof (or/c a b c))
[`(listof (or/c ,(app (λ (v) (list 'listof v)) xs) ...))
xs])

Oh, sorry, when I said (listof (or/c a b c))
, I was talking about the type/contract of the sequence.

@kellysmith12.21 (define li (list 'a 1 "3" 'b 2 "4"))
(group-by (lambda (arg)
(cond
[(number? arg) 1]
[(string? arg) 2]
[(symbol? arg) 3]
[else (error 'test "you are drunk ~a ~n" arg)])) li)
# '((a b) (1 2) ("3" "4"))

@capfredf Ah, now I see. Thank-you!

@greg, a quick question about customizing indentation in Racket-mode. How can I make the indentation for typed lambda forms be the same as untyped ones? (lambda ([arg : Number]) : Number
10)
;;;
(lambda (arg)
10)

Although I haven’t looked at that in N years, I recall adding cases for common Typed Racket forms like define
and let
. It’s possible that I just overlooked lambda
. Let me check….

@capfredf Yes there’s just no attempt yet to handle that. I can take a look tomorrow.

Thank you!

@capfredf My brain isn’t in indentation-mode right now, but I’m not sure why lambda
can’t just use the same indent as define
. (I might just be forgetting edge cases.)
You could try that if you want. e.g. (put 'lambda 'racket-indent-line 'defun)
as described here https://www.racket-mode.com/#racket_002dindent_002dline

Derp. No that doesn’t work. I will look at it tomorrow with a fresher brain.

you might want to look at for/fold
if you know how many lists you want to produce statically. @kellysmith12.21

In the process of developing resyntax
and running it on old scheme-y code, I occasionally encounter uses of let
that are… frustrating (let ([a (assq id (let ([a (assoc export-phase exports)])
(if a
(cdr a)
null)))])
Please. Other variable names exist. I’m begging you.

That entire snippet is rather obtuse.

this is the file in question https://github.com/racket/scribble/blob/master/scribble-lib/scribble/search.rkt


Can we change caddddddddddr
to stuff like first
, second
, … too? Note that you might need to require racket/list

Unfortunately not safely, because I think cxxxxr
and friends work on pairs but first
, second
, etc. need proper lists

yes

Wow, there’s (let ([queue (cdr queue)]) ...)
left. Does resyntax
analyze that it cannot convert this let
?

Also, comment placement looks difficult to solve. What’s the policy?

Looking at:
;; abc
(if …
;; def
…
;; ghi
…)
being rewritten to:
(cond
;; abc
[...
;; def
...]
[else
;; ghi
...])

Comment placement was manual, I did that myself after resyntax
obliterated a bunch of comments.

Resyntax does analyze let
forms to leave behind those that can’t be turned into definitions.

The bulk of that logic is here: https://github.com/jackfirth/resyntax/blob/0c3ec1bc9da84dfa45a5c113d042f18753c13632/refactoring-rule.rkt#L288

I should have read your commit message. It answers a lot of my questions already…

on the plus side it made me double check that I answered that in the commit message :p

Since first
& al. require a proper list, perhaps instead there could be a rule to transform caddddr
and friends into list-ref
and list-tail
, which only require a pair.

What if instead there were rules to look for cases where it’s provable that they’re proper? For instance I see some of this: (list (car xs) (cadr xs) (list-ref xs 2) ...)

Wouldn’t proving that a list is proper require static contract verification?

In the general case yes, but resyntax
doesn’t need to deal with general cases. Just specific cases that occur commonly in real code.

If there are some common cases where it’s trivially proven that a list is proper, then I’d say go ahead and add handling for them.