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 typestate, etc. #2178

Closed
brson opened this Issue Apr 9, 2012 · 11 comments

Comments

Projects
None yet
5 participants
@brson
Contributor

brson commented Apr 9, 2012

Typestate does a lot of things, most of which we don't use. It's the longest compiler pass, discounting trans. Without it we can get rid of check, if check, claim, pure, constraints.

I like the idea of typestate, but it's not pulling its weight.

@catamorphism

This comment has been minimized.

Show comment
Hide comment
@catamorphism

catamorphism Apr 9, 2012

Contributor

You mean removing user-specified constraints? Or also getting rid of late initialization and early returns?

It's possible to do the first, but it wouldn't eliminate that much code since most of it is still needed to check definite-assignment and must-return anyway.

Contributor

catamorphism commented Apr 9, 2012

You mean removing user-specified constraints? Or also getting rid of late initialization and early returns?

It's possible to do the first, but it wouldn't eliminate that much code since most of it is still needed to check definite-assignment and must-return anyway.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Apr 9, 2012

Contributor

I mean removing everything that we don't rely upon, and probably rewriting whatever is left to be faster.

Contributor

brson commented Apr 9, 2012

I mean removing everything that we don't rely upon, and probably rewriting whatever is left to be faster.

@catamorphism

This comment has been minimized.

Show comment
Hide comment
@catamorphism

catamorphism Apr 10, 2012

Contributor

Ok. The code has never been optimized and should certainly be rewritten. To me that's separate from the language design question. Removing constraints altogether seems premature to me. As far as I know, they're not used not because they aren't useful (there are lots of places where they would be useful just in the compiler), but because people found the overhead of using them (as far as cognitive burden) to be too high. I'm not seeing the evidence that there isn't a more usable design that still lets us state more precise properties about code. It's not like we've tried to revise the design and failed to find something that works better -- there just haven't been enough person-hours available to do so. I think it's worth putting in some effort there before we raise the white flag completely.

Contributor

catamorphism commented Apr 10, 2012

Ok. The code has never been optimized and should certainly be rewritten. To me that's separate from the language design question. Removing constraints altogether seems premature to me. As far as I know, they're not used not because they aren't useful (there are lots of places where they would be useful just in the compiler), but because people found the overhead of using them (as far as cognitive burden) to be too high. I'm not seeing the evidence that there isn't a more usable design that still lets us state more precise properties about code. It's not like we've tried to revise the design and failed to find something that works better -- there just haven't been enough person-hours available to do so. I think it's worth putting in some effort there before we raise the white flag completely.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Apr 10, 2012

Contributor

Continuing to push on typestate would also be good.

Contributor

brson commented Apr 10, 2012

Continuing to push on typestate would also be good.

@catamorphism

This comment has been minimized.

Show comment
Hide comment
@catamorphism

catamorphism Apr 10, 2012

Contributor

There just has to be someone to do it. I'm reluctant for that person to be me, because the longer I'm the only one who works on / uses it, the less anyone else will believe that it's really something they want to use :-) Intern project?

Contributor

catamorphism commented Apr 10, 2012

There just has to be someone to do it. I'm reluctant for that person to be me, because the longer I'm the only one who works on / uses it, the less anyone else will believe that it's really something they want to use :-) Intern project?

@graydon

This comment has been minimized.

Show comment
Hide comment
@graydon

graydon Apr 10, 2012

Contributor

I feel a sense of deja vu here wrt. issue #1805

I posted what I felt then and nobody's had time to do anything new with typestate since then -- indeed, @catamorphism moved to doing classes specifically to get involved with the rest of the compiler, leaving typestate aside to come back to it later -- so my preference is mostly the same as then:

#1805 (comment)
#1805 (comment)

It's a bit like the macro system. It's not dead, it's just resting. I still want to give it a chance.

Contributor

graydon commented Apr 10, 2012

I feel a sense of deja vu here wrt. issue #1805

I posted what I felt then and nobody's had time to do anything new with typestate since then -- indeed, @catamorphism moved to doing classes specifically to get involved with the rest of the compiler, leaving typestate aside to come back to it later -- so my preference is mostly the same as then:

#1805 (comment)
#1805 (comment)

It's a bit like the macro system. It's not dead, it's just resting. I still want to give it a chance.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Apr 10, 2012

Contributor

I am eager to reimplement it. I think it can be made substantially faster. That said, I am not convinced yet of its worth---I haven't seen a use yet that could not also have been achieved with types. However, I have used it a few times and even caught a bug that might have gone unnoticed otherwise (though as I said I could have used types to catch that same bug, albeit in a non-obvious way).

Contributor

nikomatsakis commented Apr 10, 2012

I am eager to reimplement it. I think it can be made substantially faster. That said, I am not convinced yet of its worth---I haven't seen a use yet that could not also have been achieved with types. However, I have used it a few times and even caught a bug that might have gone unnoticed otherwise (though as I said I could have used types to catch that same bug, albeit in a non-obvious way).

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Apr 10, 2012

Contributor

Still I do think that if we want to simplify the language, @brson is right that type state is not "carrying its weight" with regard to language complexity. But I guess we're not quite at the "simplify" stage yet---still in the "expand" stage.

Contributor

nikomatsakis commented Apr 10, 2012

Still I do think that if we want to simplify the language, @brson is right that type state is not "carrying its weight" with regard to language complexity. But I guess we're not quite at the "simplify" stage yet---still in the "expand" stage.

@graydon

This comment has been minimized.

Show comment
Hide comment
@graydon

graydon Apr 10, 2012

Contributor

We're ostensibly in the "simplify" stage -- so says the manual! -- I just don't think the next appropriate simplification to typestate is "remove it entirely". I think that's premature given the number of incomplete portions, lack of recent attention, number of plausibly-useful reduced-functionality DBC-like or contract-like forms it could assume, and the fact that we need at very least the init-predicate tracking for memory safety (hard to emulate any other way given the existence of move operators and whatnot).

Contributor

graydon commented Apr 10, 2012

We're ostensibly in the "simplify" stage -- so says the manual! -- I just don't think the next appropriate simplification to typestate is "remove it entirely". I think that's premature given the number of incomplete portions, lack of recent attention, number of plausibly-useful reduced-functionality DBC-like or contract-like forms it could assume, and the fact that we need at very least the init-predicate tracking for memory safety (hard to emulate any other way given the existence of move operators and whatnot).

@pcwalton

This comment has been minimized.

Show comment
Hide comment
@pcwalton

pcwalton Apr 11, 2012

Contributor

We definitely need init to stay. For that reason we need typestate to stay around, even if it morphs into just our version of Flow.java.

We should also think about what a DBC system would look like. Something like DBC + QuickCheck might be pretty awesome for unit testing.

Contributor

pcwalton commented Apr 11, 2012

We definitely need init to stay. For that reason we need typestate to stay around, even if it morphs into just our version of Flow.java.

We should also think about what a DBC system would look like. Something like DBC + QuickCheck might be pretty awesome for unit testing.

@catamorphism

This comment has been minimized.

Show comment
Hide comment
@catamorphism

catamorphism Apr 19, 2012

Contributor

I see a pretty clear lack of consensus, so I'm closing this, but there are certainly discussions in the comments that we should go back to.

Contributor

catamorphism commented Apr 19, 2012

I see a pretty clear lack of consensus, so I'm closing this, but there are certainly discussions in the comments that we should go back to.

nivkner added a commit to nivkner/rust that referenced this issue Sep 30, 2017

address some `FIXME`s whose associated issues were marked as closed
remove FIXME(#13101) since `assert_receiver_is_total_eq` stays.
remove FIXME(#19649) now that stability markers render.
remove FIXME(#13642) now the benchmarks were moved.
remove FIXME(#6220) now that floating points can be formatted.
remove FIXME(#18248) and write tests for `Rc<str>` and `Rc<[u8]>`
remove reference to irelevent issues in FIXME(#1697, #2178...)
update FIXME(#5516) to point to getopts issue 7
update FIXME(#7771) to point to RFC 628
update FIXME(#19839) to point to issue 26925

nivkner added a commit to nivkner/rust that referenced this issue Sep 30, 2017

address some `FIXME`s whose associated issues were marked as closed
remove FIXME(#13101) since `assert_receiver_is_total_eq` stays.
remove FIXME(#19649) now that stability markers render.
remove FIXME(#13642) now the benchmarks were moved.
remove FIXME(#6220) now that floating points can be formatted.
remove FIXME(#18248) and write tests for `Rc<str>` and `Rc<[u8]>`
remove reference to irelevent issues in FIXME(#1697, #2178...)
update FIXME(#5516) to point to getopts issue 7
update FIXME(#7771) to point to RFC 628
update FIXME(#19839) to point to issue 26925

nivkner added a commit to nivkner/rust that referenced this issue Sep 30, 2017

address some `FIXME`s whose associated issues were marked as closed
remove FIXME(#13101) since `assert_receiver_is_total_eq` stays.
remove FIXME(#19649) now that stability markers render.
remove FIXME(#13642) now the benchmarks were moved.
remove FIXME(#6220) now that floating points can be formatted.
remove FIXME(#18248) and write tests for `Rc<str>` and `Rc<[u8]>`
remove reference to irelevent issues in FIXME(#1697, #2178...)
update FIXME(#5516) to point to getopts issue 7
update FIXME(#7771) to point to RFC 628
update FIXME(#19839) to point to issue 26925
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment