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

Safer env for recursives + variable identity. #56

Merged
merged 1 commit into from
Mar 8, 2016

Conversation

hishamhm
Copy link
Contributor

The change with the "@" characters is a bit of paranoia, as different pairs of types may concatenate to the same string ("aa".."b" and "a".."ab") and this may cause evaluation errors in the future.

Note the change in subtype_variable for when the two entries have equal names. This is the important one. Please verify if this is semantically correct. Here it seems to solve #55, but I don't know if that's enough. Maybe this is just hiding the real problem.

I don't know if I'm understanding correctly the way the structural type system is supposed to work. With this patch, the code in #55 gives no errors, but the variant below still fails:

interface ELEM
   x: integer
end

interface OBJ
   parent: OBJ?
   atr: ELEM -- if I change ELEM to {"x":integer}, I no longer get an error
end

local function f(o:OBJ)
   local parent = o.parent
   if parent then
      f({atr={x=2}}) -- isn't this structurally equivalent to OBJ?
   end
end

The change with the "@" characters is a bit of paranoia, as different
incompatible subtypes may concatenate to the same string ("aa".."b" and
"a".."ab") and this may cause evaluation errors in the future.

Note the change in `subtype_variable` for when the two entries have equal
names. This is the important one. Please verify if this is semantically
correct. Here it seems to solve andremm#55, but I don't know if that's enough.
mascarenhas added a commit that referenced this pull request Mar 8, 2016
Safer env for recursives + variable identity.
@mascarenhas mascarenhas merged commit ebea1c8 into andremm:master Mar 8, 2016
@mascarenhas
Copy link
Collaborator

Yep, the code above should compile. What we need is a global environment that maps named types to their structure, with this environment being used throughout the type checker (including the subtype relation). Note that this is environment is not a type environment (type environments map variables names to types).

@hishamhm
Copy link
Contributor Author

hishamhm commented Mar 9, 2016 via email

@mascarenhas
Copy link
Collaborator

I improved the name resolution code, and this example now works fine (fixed the loop in issue #50 too), but there is still more to be done. Ideally global type names like ELEM and OBJ should be left as is, so we can have mutually recursive global types. These types should also be exported along with the other names in the module, and modules that import this one should be able to access them:

local mod = require "pr56" -- pr56.tl is the module above
local e: mod.ELEM = { x = 10 }

@hishamhm
Copy link
Contributor Author

Yes. I also missed a way to make one .tld require another (should be a separate issue?).

@hishamhm
Copy link
Contributor Author

Ah, nevermind, that's #66.

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

Successfully merging this pull request may close these issues.

2 participants