jackfirth / jackfirth/resyntax

Easier way for rules to check identifier usages

Open
#400 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Racket
Stars
70
Forks
11
PR merge metrics
No merged PRs in 30d

Description

Consider the hash-ref-set!-to-hash-ref! rule:

(define-refactoring-rule hash-ref-set!-to-hash-ref!
  #:description "This expression can be replaced with a simpler, equivalent `hash-ref!` expression."
  #:literals (hash-ref hash-set! define)
  (hash-ref
   h1:id
   k1:pure-expression
   (_:lambda-by-any-name
    ()
    (define v1:id initializer:value-initializer)
    (hash-set! h2:id k2:pure-expression v2:id)
    v3:id))
  #:when (free-identifier=? #'h1 #'h2)
  #:when (syntax-free-identifier=? #'k1 #'k2)
  #:when (free-identifier=? #'v1 #'v2)
  #:when (free-identifier=? #'v1 #'v3)
  (hash-ref! h1 k1 initializer.failure-result-form))

It needs to do quite a bit of work to check that some identifiers are usages of others. Those free-identifier=? checks ought to be easier to write. It might be useful to have a (~usage id) syntax pattern that matches any identifier that's free-identifier=? to #'id. That would let me write the above rule like this:

(define-refactoring-rule hash-ref-set!-to-hash-ref!
  #:description "This expression can be replaced with a simpler, equivalent `hash-ref!` expression."
  #:literals (hash-ref hash-set! define)
  (hash-ref
   h:id
   k1:pure-expression
   (_:lambda-by-any-name
    ()
    (define v:id initializer:value-initializer)
    (hash-set! (~usage h) k2:pure-expression (~usage v))
    (~usage v)))
  #:when (syntax-free-identifier=? #'k1 #'k2)
  (hash-ref! h k1 initializer.failure-result-form))

Might be worthwhile to make it match any syntax object that's syntax-free-identifier=? too. This could also help with #379, as ~usage could default to (resyntax-local-phase-level) (or whatever equivalent I come up with) instead of (syntax-local-phase-level) like free-identifier=? does.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the refactoring-rule pattern-matching and identifier-comparison code; the issue does not name specific files or tests. Define what “done” means for a (~usage id) pattern matching free-identifier usages, syntax-free-identifier usages, and the proposed phase-level default, while checking the related requirements in #379.

Written by the indexing model from the issue text.

Assessment

Domain
devtools
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.