[TS Calls] Audit and classify existing semantic approximations

Đang mở
#368 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
kotlin, typescript
Lĩnh vực
compilers, devtools

Hướng nghiên cứu

Start with #361's production inventory and recovered archive, then compare them with the historical 29-model registry without repeating the inventory. For each item, record its origin, semantic operation, assumptions, domain, effects, tests and frontend assumptions, and assign a reasoned disposition. Done means every item has a disposition, accepted candidates have an implementation mechanism and validation status, and missing selected-family implementations have bounded follow-up issues.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Part of #360. Reuses #361 and feeds #367/#385.

Goal

Review existing production and historical approximations once, deciding what is sound to retain, migrate or reject.

Scope

  • Start from #361's production inventory and recovered archive. Add historical candidates, including the old 29-model registry, without redoing the same inventory from scratch.
  • For each item record its origin, semantic operation, proven target/receiver assumptions, supported/residual domain, effects/exceptions/aliases, tests and frontend assumptions.
  • Distinguish mandatory language semantics and engine/frontend correctness fixes from optional library-model choices.
  • Classify optional models as source-model migration, genuine engine intrinsic, rewrite, reject or deferred pending evidence.
  • Prefer ordinary TypeScript for expressible library semantics. Choose an intrinsic only for a justified symbolic engine operation.
  • Carry accepted candidates into #367's roadmap, but do not automatically require migration of every historical model.
  • Keep mandatory semantics and correctness fixes identical across #385 profiles; they are not experimental model toggles.

Definition of Done

  • Every inventoried item has a reasoned disposition; blocked cases have a concrete reason.
  • Accepted candidates have a domain, intended implementation mechanism and current validation status.
  • A small evaluation subset can be selected without merging the historical branch.
  • Missing selected-family implementations get bounded follow-up issues that block #385.
  • Inventory/audit work does not wait for unrelated model infrastructure.

This is a reviewed inventory, not implementation of the whole standard library or another registry framework.

Ngôn ngữ chính
Kotlin
Star
33
Fork
27
Merge trung bình
4 ngày 3 giờ
Pull request đã merge (30 ngày)
15

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của UnitTestBot/usvm

Tất cả issue của UnitTestBot/usvm

Issue tương tự

Thêm issue về Kotlin

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.