Skip to content
This repository has been archived by the owner on Sep 19, 2023. It is now read-only.

Feature/auto casting function arguments #103

Merged

Conversation

jitsedesmet
Copy link
Member

@jitsedesmet jitsedesmet commented Aug 11, 2021

This pull request aims to provide an implementation on auto casting functions as talked about in #102 .
This pull request should NOT be merged before the scheme talked about in #102 is added.

There are a few questions to be answered before merging this PR too, those questions should be marked with a TODO.

Edit:
We can close a few issues with this PR: #13, #94 and #103.
When merging we open issues about: cast decimal so we can close #12 , questions surrounding arithmeticWidening, revision of #103 (comment) (I think this issue is mainly for @wschella) and an issue surrounding caching and open world types.
The PR also makes implementation of #87 a lot easier.

@coveralls
Copy link

coveralls commented Aug 11, 2021

Pull Request Test Coverage Report for Build 1138484875

  • 291 of 307 (94.79%) changed or added relevant lines in 10 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+2.4%) to 90.735%

Changes Missing Coverage Covered Lines Changed/Added Lines %
lib/functions/Helpers.ts 26 27 96.3%
lib/functions/NamedFunctions.ts 3 4 75.0%
lib/functions/RegularFunctions.ts 8 9 88.89%
lib/functions/SpecialFunctions.ts 36 49 73.47%
Totals Coverage Status
Change from base Build 1128445387: 2.4%
Covered Lines: 1389
Relevant Lines: 1499

💛 - Coveralls

Copy link
Member

@rubensworks rubensworks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the size of this PR, I'm a bit scared of the lack of tests related to this.
We did indeed have tests already that will now cover part of this implementation, but looking at the coveralls output, it seems like coverage is not complete.

Therefore, I would recommend to add more detailed unit tests to the parts of the code you touched. Should be straightforward to do, now that this code is still fresh.

@jitsedesmet
Copy link
Member Author

Therefore, I would recommend to add more detailed unit tests to the parts of the code you touched. Should be straightforward to do, now that this code is still fresh.

Do you think about changing the test directory structure at the same time? Like talked about in #34 ? So we can create a dir for unit tests as well?

@rubensworks
Copy link
Member

Do you think about changing the test directory structure at the same time? Like talked about in #34 ? So we can create a dir for unit tests as well?

Oh, I thought we did that one already 😅

I think that's quite urgent, yes. But I would do it in a separate PR.

@wschella
Copy link
Collaborator

I can review the PR this afternoon. I think changing the test folder structure can be done & and merged quickly. Then this PR can be rebased on it (since it will be a significant one, and I do really propose fixing everything mentioned in #102 at once here, it's too closely related). We should indeed strive to not decrease test coverage here, but everything should be able to be tested in theory with some entries in a TestTable somewhere.

@jitsedesmet jitsedesmet force-pushed the feature/auto-casting-function-arguments branch from e3bc73f to 8c8e69c Compare August 12, 2021 09:10
Comment on lines 91 to 116
if (argumentType === TypeURL.XSD_STRING) {
this.addPromotedOverload(TypeURL.XSD_ANY_URI, func, arg => string(arg.str()), _argumentTypes);
}
this.subTrees[argumentType]._addOverload(argumentTypes, func);
if (argumentType === TypeURL.XSD_FLOAT) {
this.addPromotedOverload(TypeURL.XSD_DOUBLE, func, arg =>
number((<E.NumericLiteral>arg).typedValue, TypeURL.XSD_DOUBLE), _argumentTypes);
}
if (argumentType === TypeURL.XSD_DECIMAL) {
this.addPromotedOverload(TypeURL.XSD_FLOAT, func, arg =>
number((<E.NumericLiteral>arg).typedValue, TypeURL.XSD_FLOAT), _argumentTypes);
this.addPromotedOverload(TypeURL.XSD_DOUBLE, func, arg =>
number((<E.NumericLiteral>arg).typedValue, TypeURL.XSD_DOUBLE), _argumentTypes);
}
}

private addPromotedOverload(typeToPromote: ArgumentType, func: E.SimpleApplication,
conversionFunction: (arg: E.TermExpression) => E.TermExpression, argumentTypes: ArgumentType[]): void {
if (!this.subTrees[typeToPromote]) {
this.subTrees[typeToPromote] = new OverloadTree(this.depth + 1);
}
this.subTrees[typeToPromote]._addOverload(argumentTypes, args => func([
...args.slice(0, this.depth),
conversionFunction(args[this.depth]),
...args.slice(this.depth + 1, args.length),
]));
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code should allow type promotion as talked about in https://www.w3.org/TR/xpath-31/#promotion . At least, how I understand it. If this is wrong please let me know.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At first glance it looks like it could work.
But we'll now for certain once we have tests covering these cases.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I will add the scheme first and then start writing the tests. With 'wrong' I meant the interpretation of 'promotion'. :)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A special thing to consider here is that subtype substitution and type promotion can work at the same time. There certainly should be tests for that, as I'm not sure the code handles this like it is (but it's also likely that I'm just missing something).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pretty sure this wouldn't be a problem since promotion is always from a non super type. To another type. And of course like it is now, having a restriction of anyURI provided to a function expecting an xsd_string, the restriction will be substituted to anyUri and will then be promoted to xsd_string.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still convinced we can't really test this. So unless someone can give an example on when this could create a problem I consider this to be done.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added some documentation so people don't break the system and also a test that first performs substitution and that promotion.

README.md Show resolved Hide resolved
Copy link
Collaborator

@wschella wschella left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice work, very important, and cleans things up nicely.

I also think we we can make it a bit cleaner still: see comments and suggested changes.

lib/Transformation.ts Outdated Show resolved Hide resolved
lib/util/Consts.ts Show resolved Hide resolved
lib/util/Consts.ts Outdated Show resolved Hide resolved
lib/util/Consts.ts Outdated Show resolved Hide resolved
lib/util/TypeHandling.ts Outdated Show resolved Hide resolved
lib/util/Consts.ts Outdated Show resolved Hide resolved
lib/util/TypeHandling.ts Outdated Show resolved Hide resolved
test/integration/functions/onStrings.test.ts Outdated Show resolved Hide resolved
test/integration/functions/onStrings.test.ts Outdated Show resolved Hide resolved
type-scheme.svg Outdated Show resolved Hide resolved
lib/expressions/Term.ts Outdated Show resolved Hide resolved
@jitsedesmet
Copy link
Member Author

jitsedesmet commented Aug 15, 2021

When merging this PR we should also open 2 new issues.

  1. Is arithmetic widening the right choice? This PR creates a function arithmetic widening this function copy's previous behavior. We should check if this behavior is spec compliant and add links to that part of the spec. Reason: it could be that short + short \ne short. Example: is 240 + 100 still a short? It can not be represented as a short. Should we check this? Or do we need to return a short with value 340 which is not a valid short value.
  2. The requested change by @wschella right here Feature/auto casting function arguments #103 (comment) . Should be checked closer. resolving that issue should also provide an explanation on any choices made there.

@jitsedesmet
Copy link
Member Author

If we wish to implement https://www.w3.org/TR/xpath-31/#promotion completely, we should make sure we cast the decimal to double or float when promoting decimal. I will leave this for now. I think we should open a new issue adding this (I think small) feature. I feel like we better do this in a new issue because we might need a package for this? I'm not sure though

Copy link
Member

@rubensworks rubensworks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This stuff wasn't trivial, so really good work!

Before we merge, can you again double-check if all tests (unit, integration, spec, ...) still pass in Comunica?

Could you also list in the main description of this PR, what issues can be closed?

I'll wait a bit for merging until @wschella gives his 👍

@jitsedesmet
Copy link
Member Author

Thank you!

Before we merge, can you again double-check if all tests (unit, integration, spec, ...) still pass in Comunica?

I checked the overal tests and ran test, integration and spec in the actor-init-sarql package. All tests succeeded.

I will add the closing issues.

@rubensworks rubensworks merged commit d020e29 into comunica:master Aug 17, 2021
@rubensworks
Copy link
Member

@wschella Merged this one already. Feel free to open issues in case you still see issues with this.

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

Successfully merging this pull request may close these issues.

Implement Type Promotion
4 participants