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

optional static typing #104

Closed
hartsantler opened this Issue Jun 6, 2014 · 4 comments

Comments

Projects
None yet
2 participants
@hartsantler
Member

hartsantler commented Jun 6, 2014

Performance can be easily increased if the translator knew more about the type of each variable. And in the future, do better translation time type checking.

For example the + operator currently use a runtime ternary expression to check if the first operand is a number, and if so then simply add the operands, otherwise it falls back to the __add_op function that checks if the first operand is a list and if so return a new list that contains the contents of both; or if the first operand is a string then concatenate them; otherwise it fallbacks to calling __add__ method if the left operand has that method, or raise an Error. This could be fully optimized away if the translator knew that the left operand was a number.

Python3 features function annotation syntax, however this only allows typing of arguments and the function return type. There is no syntax to type local variables inside a function. PythonJS is still only compatible with Python2.

C style typing syntax is very clear and readable, it can be implemented as a simple text pre-processor that transform the text without doing much heavy parsing. By hijacking multiple target assignment and making the typedef the first target, the translator can check for those special typedef names when looking at assignments.

new syntax

def f():
  int x = 1
  return x+x

intermediate output

def f():
  int = x = 1
  return x+x

610edf8

@hartsantler

This comment has been minimized.

Show comment
Hide comment
@hartsantler
Member

hartsantler commented Jun 6, 2014

@hartsantler

This comment has been minimized.

Show comment
Hide comment
@hartsantler

hartsantler Jun 7, 2014

Member

new long type translates to using Long.js API
d534822

Member

hartsantler commented Jun 7, 2014

new long type translates to using Long.js API
d534822

@techtonik

This comment has been minimized.

Show comment
Hide comment
@techtonik

techtonik Jun 8, 2014

Contributor

How about x = int(1)? Otherwise PythonJS risks to become yet another DSL.

Contributor

techtonik commented Jun 8, 2014

How about x = int(1)? Otherwise PythonJS risks to become yet another DSL.

@hartsantler

This comment has been minimized.

Show comment
Hide comment
@hartsantler

hartsantler Jun 8, 2014

Member

The translator can easily support x = int(n) for typing as well, i'll add that in the future.

The goal of this project is not to become a domain specific language. However, having it there as an option is a good thing, so long as typedpython.py can strip away the DSL and transform the source back to regular python, which is what it is doing now when running the regression tests against Python2 and Python3.

Member

hartsantler commented Jun 8, 2014

The translator can easily support x = int(n) for typing as well, i'll add that in the future.

The goal of this project is not to become a domain specific language. However, having it there as an option is a good thing, so long as typedpython.py can strip away the DSL and transform the source back to regular python, which is what it is doing now when running the regression tests against Python2 and Python3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment