Skip to content
Snippets Groups Projects

Add applicable records

Merged David Thompson requested to merge applicable-structs into main
1 unresolved thread

Merge request reports

Pipeline #1610669133 passed

Pipeline passed for 96a30bdf on applicable-structs

Merged by David ThompsonDavid Thompson 2 months ago (Jan 3, 2025 6:13pm UTC)

Loading

Pipeline #1610706739 passed

Pipeline passed for 4f7a07c1 on main

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • David Thompson added 3 commits

    added 3 commits

    Compare with previous version

  • added 1 commit

    Compare with previous version

  • Andy Wingo
  • Andy Wingo
  • Sorry this review was stuck in my drafts yesterday :/

  • David Thompson added 10 commits

    added 10 commits

    Compare with previous version

  • David Thompson changed title from Add applicable structs to Add applicable records

    changed title from Add applicable structs to Add applicable records

  • David Thompson resolved all threads

    resolved all threads

  • added 1 commit

    Compare with previous version

  • 1902 Note that @code{<counter>} objects are recognized as both counters
    1903 @emph{and} procedures!
    1904
    1905 @defvr {Variable} <applicable-record>
    1906 The record type descriptor for applicable records.
    1907 @end defvr
    1908
    1909 @deffn {Procedure} applicable-record? obj
    1910 Return @code{#t} if @var{obj} is an applicable record.
    1911 @end deffn
    1912
    1913 @deffn {Procedure} applicable-record-procedure obj
    1914 Return the procedure stored within the applicable record @var{obj}.
    1915 @end deffn
    1916
    1917 @deffn {Procedure} set-applicable-record-procedure! obj proc
    • This field should be immutable. Read this rationale and think about it and it’ll be clear why

    • Besides that, making this field mutable means no future version of Hoot will ever be able to fully statically optimize calls to statically known applicable record instances

    • I sympathize with the desire to make things immutable, but we have use cases where it would be beneficial to change the procedure. I've been thinking of applicable records as a layer of indirection but I'd be curious if @wingo thinks there is much to gain from compiler optimization of known applicable record calls.

      Edited by David Thompson
    • Then do something like this:

      (define-record-type <my-applicable-thing>
        #:parent <applicable-record>
        (%make-applicable-thing base-proc real-proc blah)
        (real-proc applicable-thing-real-proc applicable-thing-real-proc-set!)
        (blah-field applicable-thing-blah applicable-thing-blah-set!))
      
      (define (make-applicable-thing proc blah)
        (letrec
            ((thing
              (make-applicable-thing
               (lambda args (apply (applicable-thing-real-proc thing) args))
               proc blah)))
          thing))

      Then you can use apply-applicable-thing-real-proc-set! to change the behaviour when called.

      Making the standard applicable record field mutable, so that anyone who has an applicable record of any subtype can call set-applicable-record-procedure! on it and break the contract between the procedure and the fields of the record, sacrifices security and optimizability for everyone for the sake of the cases that need something different, even though this way shows it is possible even without making that sacrifice. With this way, you can control who is allowed to change the procedure by controlling the scopes in which the apply-applicable-thing-real-proc-set! identifier is available.

      Edited by Daphne Preston-Kendal
    • David Thompson changed this line in version 21 of the diff

      changed this line in version 21 of the diff

    • I didn't really want to force another layer of indirection. Either way, I don't love exposing the field setter and it seems we don't need the setter right now for porting Goblins to Hoot so I'm going to leave it out. I'm still unsure if applicable records should be made via subtyping or just using a flag like we already have with #:extensible? and #:opaque? so I commented out the docs so we don't advertise an API we haven't settled on yet.

    • Please register or sign in to reply
  • added goblins label

  • added 1 commit

    Compare with previous version

  • added 1 commit

    Compare with previous version

  • added 1 commit

    Compare with previous version

  • added 1 commit

    Compare with previous version

  • David Thompson added 6 commits

    added 6 commits

    Compare with previous version

  • David Thompson added 5 commits

    added 5 commits

    Compare with previous version

  • David Thompson added 8 commits

    added 8 commits

    Compare with previous version

  • David Thompson added 12 commits

    added 12 commits

    Compare with previous version

  • David Thompson added 6 commits

    added 6 commits

    Compare with previous version

  • David Thompson added 2 commits

    added 2 commits

    Compare with previous version

  • David Thompson added 5 commits

    added 5 commits

    Compare with previous version

  • added 1 commit

    Compare with previous version

  • David Thompson mentioned in commit 4f7a07c1

    mentioned in commit 4f7a07c1

  • Please register or sign in to reply
    Loading