Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type inference: follow-up tasks #447

Open
11 of 24 tasks
sharkdp opened this issue Jun 4, 2024 · 0 comments
Open
11 of 24 tasks

Type inference: follow-up tasks #447

sharkdp opened this issue Jun 4, 2024 · 0 comments

Comments

@sharkdp
Copy link
Owner

sharkdp commented Jun 4, 2024

see #443 for background information

  • Update documentation #523
  • Fix bug with type parameter name clashes: fn f<A: Dim>(x: A) -> A * Velocity = x * c does not work, giving A a different name works fine.
  • Improve startup time (regression) #525
  • Pretty-printing: do not show forall multiple times #524
  • Better type name generation policy: (1) handle name clashes with existing types (e.g. struct names), (2) try not to show things like T423 to a customer, but rather reset the counter after type-checking a single statement — if possible.
  • Something like fn foo<D1, D2>(x: D1*D2) = 1 should yield a "missing Dim bound" constraint, because the type parameters are used type annotation dimension expression
  • Re-enable generics_unused_type_parameter
  • Equality on function types should be forbidden. Maybe we need to introduce an Eq type class.
  • try_trivial_resolution can easily analyze the constraint structure further to discard constraints like List<T0> ~ Bool, which will yield better error messages in return
  • Better error message for sth. like true(2)
  • Check if we can reduce the number of constraints: (1) by cancelling out equal constraints and (2) by not adding as many constraints. for example, in x + y, we need type(x) ~ type(y) and IsDim(type(x)), but we could potentially save the IsDim(type(y)). On the other hand, that would result in worse error messages.
  • For all (generic) functions that we have, check that we can (1) remove all type annotations and (2) get the same type or a more general type.
  • Add tests for type inference with partial annotations
  • Better error message for fn f<A: Dim>(x: A) -> A = 2x; f(true)
  • Improve error messages for callables, see function_types_in_argument_position test
  • Print parameter names in info <function> #491
  • Bring back (and improve) "readable types" #490
  • update https://numbat.dev/articles/intro.html
  • Re-read http://typesatwork.imm.dtu.dk/material/TaW_Paper_TypesAtWork_Kennedy.pdf
  • Implement mean, stddev, etc in Numbat
  • Give quadratic_equation a List<B/A> return type. #449
  • When quantifying a function type with annotations, use the user-specified identifiers
  • Bring numerical diff functionality to the prelude (Numerical derivatives, integrals #145)
  • Use assert_eq instead of assert in Numbat code tests
@sharkdp sharkdp pinned this issue Jul 2, 2024
@sharkdp sharkdp unpinned this issue Aug 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant