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

Design decision or implementation detail? #39

Open
bennn opened this issue Jun 30, 2017 · 0 comments
Open

Design decision or implementation detail? #39

bennn opened this issue Jun 30, 2017 · 0 comments

Comments

@bennn
Copy link

bennn commented Jun 30, 2017

I have a small program where MOVING a type annotation adds a dynamic error.

First, the untyped program:

# 1

def cast(f):
  return f

def identity(x):
  return x

def app(f):
  return cast(f)("NaN")

print(app(identity))

Second, a typed version that does not error:

# 2

def cast(f:Dyn)->Function([String],String):
  return f

def identity(x):
  return x

def app(f:Function([Int],Int))->String:
  return cast(f)("NaN")

print(app(identity))

Third, moving the Function annotation to the definition of identity
makes the program raise a dynamic type error:

# 3

def cast(f:Dyn)->Function([String],String):
  return f

def identity(x:Int)->Int:
  return x

def app(f:Dyn)->String:
  return cast(f)("NaN")

print(app(identity))

This is confusing. I would expect both typed programs to error, but apparently the Function type is weaker than a type given at a function definition.

Why doesn't program 2 raise an exception?
Is there a type-system-design reason, or is the reason because of Reticulated's dynamic semantics?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant