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

Merge Small_Integer and Big_Integer types #7636

Merged

Conversation

Akirathan
Copy link
Member

@Akirathan Akirathan commented Aug 22, 2023

Closes #6959

Pull Request Description

Merge Small_Integer and Big_Integer types into a single Integer type. Both Small_Integer and Big_Integer used to be the only internal types that were not visible in Enso, i.e., typing Small_Integer in REPL resulted in an identifier not found error.

Important Notes

  • Possible to call some methods on Integer as static ones, e.g., Integer.+, Integer.*, etc.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • The documentation has been updated, if necessary.
  • All code follows the
    Scala,
    Java,
  • All code has been tested:
    • Unit tests have been written where possible.

Test.specify "should be able to invoke methods on Integer via static method call" <|
Integer.+ 1 2 . should_equal 3
Integer.+ 1 2.5 . should_equal 3.5
Test.expect_panic_with (Integer.+ 1.5 1) Type_Error
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 results in Type_Error because self is 1.5 which is Decimal, and not Integer

@Akirathan Akirathan self-assigned this Sep 6, 2023
@Akirathan Akirathan force-pushed the wip/akirathan/6959-Integer.+-cannot-be-invoked-statically branch from 70cd83f to 6adb207 Compare September 7, 2023 14:28
Comment on lines 36 to 38
@Specialization
boolean doDouble(EnsoBigInteger self, double that) {
return BigIntegerOps.toDouble(self.getValue()) < that;
Copy link
Member

Choose a reason for hiding this comment

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

Shall we rename these to avoid overloads?

I'm not sure if this has any implications for the compilation, probably no.

But still, it feels cleaner and more consistent to have names be unique - AFAIK in other places all of our specializations do have unique names.

Copy link
Member

@radeusgd radeusgd left a comment

Choose a reason for hiding this comment

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

Looks good to me. I'd like to see a test as mentioned in one of the comments.

Copy link
Member

@JaroslavTulach JaroslavTulach left a comment

Choose a reason for hiding this comment

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

Conceptually OK. If tests are passing and benchmarks are sane, then let's integrate!


@BuiltinMethod(type = "Small_Integer", name = "abs", description = "Absolute value of a number")
@BuiltinMethod(type = "Integer", name = "abs", description = "Absolute value of a number")
public abstract class AbsNode extends Node {
private @Child ToEnsoNumberNode toEnsoNumberNode = ToEnsoNumberNode.create();
Copy link
Member

Choose a reason for hiding this comment

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

We should probably make ToEnsoNumberNode inlineable. Otherwise all integer nodes will have two nodes - the main one and the ToEnsoNumberNode one.

import org.enso.interpreter.runtime.error.PanicException;
import org.enso.interpreter.runtime.library.dispatch.TypesLibrary;

public final class IntegerUtils {
Copy link
Member

Choose a reason for hiding this comment

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

Consider merging BigIntegerOps and IntegerUtils into a single class.

}

@TruffleBoundary
static PanicException throwTypeErrorIfNotInt(Object self, Node node) {
Copy link
Member

Choose a reason for hiding this comment

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

Technically this doesn't have to be behind @TruffleBoundary - all of the operations can run on fast path. But maybe such errors are infrequent and we don't need them to run at full speed.

test/Tests/src/Semantic/Meta_Spec.enso Show resolved Hide resolved
@Akirathan
Copy link
Member Author

Akirathan commented Sep 8, 2023

Engine benchmarks scheduled at https://github.com/enso-org/enso/actions/runs/6118815952, stdlib benches at https://github.com/enso-org/enso/actions/runs/6118827261

GitHub
Hybrid visual and textual functional programming. Contribute to enso-org/enso development by creating an account on GitHub.
GitHub
Hybrid visual and textual functional programming. Contribute to enso-org/enso development by creating an account on GitHub.

@Akirathan
Copy link
Member Author

Benchmark results are stable. Merging ....

@Akirathan Akirathan merged commit e0ee8fd into develop Sep 8, 2023
28 checks passed
@Akirathan Akirathan deleted the wip/akirathan/6959-Integer.+-cannot-be-invoked-statically branch September 8, 2023 14:04
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.

Integer.+ cannot be invoked "statically"
4 participants