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

Should the common root of a cover and class type be Object? #827

Closed
alexnask opened this issue Sep 21, 2014 · 6 comments
Closed

Should the common root of a cover and class type be Object? #827

alexnask opened this issue Sep 21, 2014 · 6 comments
Milestone

Comments

@alexnask
Copy link
Collaborator

@alexnask alexnask commented Sep 21, 2014

Rock currently uses findCommonRoot to determine the type of array literals and match expressions.
My goal is to use it in variety of places, pretty much any place where rock must determine a single type from multiple ones.
Current places I am thinking of adding it: built-in (/ C fall-through) binary operators (currently the left hand expressions' type is used ... bleh) and generic type inference (where the first type infered is currently used).

However, right now, every two basic types have a common root: Object.
I feel like this has always been a weakness of the ooc type-system, because code that looks an theoretically should be correct leads to both C compile (scalar conversion) and runtime errors.

I suggest that at least the compiler should start to separate the two making cover types and Object incompatible, at least when referring to common roots.

What this means: nothing changes with function scoring, casting etc (at least at the moment)

Annoying stuff like below stop happening:

// This currently infers to Object[], crashes at C compile time
// After change: Incompatible types Float, String (covers vs. class)
a := [1, 2.0f, "String", 'v']

// a is now an Object (according to rock)
a := match 'a' {
    case 'a' => 0
    case => "Hello World!"
}

// Kaboom!
a class name println()
@alexnask
Copy link
Collaborator Author

@alexnask alexnask commented Sep 21, 2014

Alternatively, covers from C types could stop inheriting Object (is that doable actually?)

Loading

@fasterthanlime
Copy link
Collaborator

@fasterthanlime fasterthanlime commented Sep 21, 2014

Alternatively, covers from C types could stop inheriting Object (is that doable actually?)

I actually tried to fix that recently - last time I touched rock. It's most likely doable, but not trivially. The metaclass business is still a mess.

Loading

@alexnask
Copy link
Collaborator Author

@alexnask alexnask commented Sep 21, 2014

The thing is there is still an issue with compound covers, as they are still value types and casting them to Object is considered legal (ofc, since theytheoretically inherit Object)

Loading

@alexnask
Copy link
Collaborator Author

@alexnask alexnask commented Sep 21, 2014

Another option would be automatic boxing/unboxing of value types into Cell, like the people @cogneco have proposed

Loading

@alexnask
Copy link
Collaborator Author

@alexnask alexnask commented Sep 21, 2014

Imho there should definitively be a system to separate value covers (cover from scalar types and compound covers) from reference covers (cover from pointer type).
There would be issues covering from typedef'ed C pointer types though.

Loading

@fasterthanlime
Copy link
Collaborator

@fasterthanlime fasterthanlime commented Jul 9, 2015

Added your test case @Shamanas, and it does fail with a compile error. Tell me if I missed something.

Loading

@fasterthanlime fasterthanlime added this to the 0.9.10 milestone Jul 10, 2015
@fasterthanlime fasterthanlime added this to the 0.9.10 milestone Jul 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants