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

remove implicit support for values of "foreign" types #77

Merged
merged 1 commit into from
Jun 24, 2016

Conversation

davidchambers
Copy link
Member

#38 provided a partial solution for sanctuary-js/sanctuary#165. sanctuary-js/sanctuary#206 offers a more complete solution, so this special case now seems unnecessary:

    //  If none of the values is a member of a type in the environment,
    //  and all the values have the same type identifier, the values are
    //  members of a "foreign" type.
    if (isEmpty(filterTypesByValues(env, values)) &&
        all(values.slice(1), $$typeEq($$type(values[0])))) {
      //  Create a nullary type for the foreign type.
      return [type0($$type(values[0]))];
    }

@Avaq
Copy link
Member

Avaq commented Jun 6, 2016

This would mean people have to get into sanctuary-def when they want to use a foreign value, right? What happens when people just try to input a foreign type? Maybe it's best to leave the check in and raise a descriptive error when it happens.

@davidchambers
Copy link
Member Author

Excellent point, Aldwin. It would be unfortunate to force a user to learn about custom environment and type definitions in order to apply S.I to document.body. So while the code quoted above is a special case, it is perhaps a justifiable special case.

I'm pleased I extracted this change from the changes I made over the weekend in an effort to improve performance. Had I not done so, this important change may have slipped through without discussion.

I'm now undecided. I'll leave this pull request open for a while in case I'm able to convince myself that removing the special case is a good idea.

@davidchambers
Copy link
Member Author

I'll leave this pull request open for a while in case I'm able to convince myself that removing the special case is a good idea.

I have convinced myself that this is a good idea. Subsequent efforts to improve performance and add functionality have been hindered by the need to preserve this special case. I'm therefore motivated to remove this special case so I can continue to make progress.

It would be unfortunate to force a user to learn about custom environment and type definitions in order to apply S.I to document.body.

I now believe this to be the correct approach:

const {create, env} = require('sanctuary');
const domTypes = require('sanctuary-dom-types');

const S = create({checkTypes: true, env: env.concat(domTypes)});

@kedashoe
Copy link
Member

const {create, env} = require('sanctuary'); const domTypes = require('sanctuary-dom-types'); const S = create({checkTypes: true, env: env.concat(domTypes)});

looks good to me :shipit:

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.

3 participants