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

Comments

Projects
None yet
2 participants
@alexnask
Collaborator

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 alexnask added the Discussion label Sep 21, 2014

@alexnask

This comment has been minimized.

Collaborator

alexnask commented Sep 21, 2014

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

@fasterthanlime

This comment has been minimized.

Collaborator

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.

@alexnask

This comment has been minimized.

Collaborator

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)

@alexnask

This comment has been minimized.

Collaborator

alexnask commented Sep 21, 2014

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

@alexnask

This comment has been minimized.

Collaborator

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.

@fasterthanlime

This comment has been minimized.

Collaborator

fasterthanlime commented Jul 9, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment