GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Implement --infer · Issue #305 · lcompilers/lpython

Implement --infer #305

New issue
Copy link
New issue
Copy link
Open
Open
Implement --infer#305
Copy link

Description

@certik
certik
opened on Mar 31, 2022
Issue body actions

The --infer flag specified at the command line of lpython would infer the type of the variable from the RHS, thus allowing not to declare variable types in most cases. The return type of a function can be inferred from the "return" statements. The arguments of functions would still need to be typed, but later as we implement generics, say with syntax something like:

T = TypeVar("T")
def f(a: T, b: T):
    c = a + b
    return c

print(f(3, 4)) # would instantiate f as f(i32, i32) -> i32
print(f(3.5, 4.5)) # would instantiate f as f(f64, f64) -> f64

which with --infer would automatically infer the return type of "f" as T (as well as the type of c as T) and then the instantiation of the generics would correctly create full types at compile time.

Then we could go further, and --infer could simply make the following equivalent to the above:

def f(a, b):
    c = a + b
    return c

print(f(3, 4)) # would instantiate f as f(i32, i32) -> i32
print(f(3.5, 4.5)) # would instantiate f as f(f64, f64) -> f64

One tricky part is taht f(a, b) would technically be f(a: T, b: U), and I am currently not sure how one would infer the type of c = a + b. But maybe there is a way.


Initially --infer should not be on by default. It should be an opt-in feature, and we should gain experience with it and see if this is useful and if it can be on by default, or if will make Python code not as readable (such as like overuse of auto in C++). This option might be helpful for interactive use.

Reacted by Thirumalai Shaktivel, akshānsh and Rushikesh Mohakum

Activity

  1. namannimmo10 commented on Mar 31, 2022

    @namannimmo10
    namannimmo10
    on Mar 31, 2022
    Collaborator
    More actions

    Initially --infer should not be on by default

    +1

    This would also be helpful while dealing with NumPy: #5 (comment)
    In general, I think strict type checking is useful for a large codebase, as it is easier to find bugs, or rather I should say: one would encounter fewer bugs.

    Reacted by Ondřej Čertík
  2. rebcabin commented on Mar 24, 2023

    @rebcabin
    rebcabin
    on Mar 24, 2023
    Contributor
    More actions

    Suggestion: when a constructor appears on the right-hand side of a definition, it's pure noise to repeat the hard type on the left-hand side. This ONE CASE should be safe always.

  3. certik commented on Apr 19, 2023

    @certik
    certik
    on Apr 19, 2023
    ContributorAuthor
    More actions

    A related idea is to infer both the types as well as casting, e.g.:

    • 2 * 3.0 -> f64(2) * f64(3.0)
    • f32(3.0) * 3.0 -> f64(3.0) * f64(3.0)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.