141–150 of 156 posts
Earlier quoted context omitted.
> What are you talking about? Please edit swipes like that out of your comments here. The rest is fine and stands on its own.
I would love to edit that out but the two-hour edit window is so short, sometimes.
Earlier quoted context omitted.
If there's a cycle of strong references with Rc or Arc (or shared_ptr in C++), those objects still never get dropped/have their destructors called.
I think that falls into the category I mentioned in the third paragraph of my comment: a serious pre-existing bug with other consequences will potentially cause the guarantee to be violated. A similar effect would happen if you had a double free that sometimes caused a crash, which is a similar level of programming mistake to creating a cyclic reference. To me it sits outside of a reasonable definition of "guaranteed…
Earlier quoted context omitted.
If there's a cycle of strong references with Rc or Arc (or shared_ptr in C++), those objects still never get dropped/have their destructors called.
Rc's drop will be called. But whether the exposed object's drop will be called is dependent on the reference count. But Rc would not work if the drop was not guaranteed to be called.
Earlier quoted context omitted.
I only mean it's visibly more obvious, you have an indented block... what is the purpose of the indented block unless to say "do all your stuff with the resource _inside_ this block". Using the with block is very 'intentional' feeling. I'm not very familiar with Haskell but it seems like you'd get used to the type system telling you everything you need to know. But in this case it doesn't. In Python world we talk abo…
> I only mean it's visibly more obvious, you have an indented block... Haskell is more similar than you realise, it's the difference between this: withSomeResource $ \resource -> do someFunctionOn resource and this: with some_resource() as resource: some_function_on(resource) > I'm not very familiar with Haskell but it seems like you'd get used to the type system telling you everything you need to know As an outsider…
with some_resource() as resource:
some_function_on(resource)
I don't think the claim that it's syntactically obvious in Python is correct. In both cases the typical syntax helps a little but it's easy to get wrong.
It is the case that "the typical syntax" is a little more enforced by Python-the-language.
Earlier quoted context omitted.
Please, don't add them to the language. Use the library approach instead, it is much more Haskellish.
Haskell has such an extensive set of language extensions, I would say adding new features to the type system is probably the MOST Haskell-ish way of doing things. The explicit purpose of Haskell is to be a basis for research into functional language design (edit: among other purposes). By "explicit purpose" I mean exactly that... people got together in 1987 to come up with a language for research. Haskell was never s…
Compare language features and Haskell's approach: Erlang and distributed-process, goroutines and channels and Control.Concurrent(.Chan), (D)STM is a library, Control.Applicative and Control.Monad for many things hardly expressible in any other language, etc, etc.
Linear types, I am afraid, would go the way implicit parameters went - their use is cumbersome and they really do not help much with day-to-day programming and when they are needed they can be perfectly implemented with a library.
Earlier quoted context omitted.
Please, don't add them to the language. Use the library approach instead, it is much more Haskellish.
From a language design perspective it makes a lot of sense to add linear types to the language itself instead of using an encoding. Every encoding that I know of (such as region types encoded as monads, which is what I think the article wants to get at) leads to excessive sequentialization of code. This in turn leads to a lot of boilerplate (or crazy type inference problems) at compile time as well as suboptimal run…
I do not oppose inferring linear use at core and/or intermediate representation (GRIN allowed for that and more). I just do not see their utility at the high level, in the language that is visible to the user.
Earlier quoted context omitted.
Please, don't add them to the language. Use the library approach instead, it is much more Haskellish.
It's extremely difficult to do this and maintain even the figment of usability. Unless, of course, you're implying it's very haskellish to implement libraries with huge usability gotchas (of which ResourceT was one until the Ghosts of Departed Proofs paper reminded us we can reuse the machinery of ST), then I totally agree.
I think it is a better venue which can help many applications simultaneusly. While linear types won't.
Earlier quoted context omitted.
Please, don't add them to the language. Use the library approach instead, it is much more Haskellish.
What is "the library approach"? Library approaches have failed. See http://www.well-typed.com/blog/2016/09/sharing-conduit/
So library approach thrives.
Earlier quoted context omitted.
As I mentioned in my other reply to Steve Klabnik, documenting this edge case would have been a sufficient “resolution” to the bug at hand. I may call it a bug, and you may call it undocumented silent data loss behavior; either way, we’re talking about the same thing. Silent data loss from undocumented behavior is not good, wouldn’t you agree? I certainly was not aware that drops in Rust could throw away potentially…
I mean, I guess it's not documented as well as it could be, but the only alternative to dropping close errors would be panicking, and that would be significantly worse. Destructors aren't supposed to fail.
I think it could take a callback, so it could note the failure somewhere if I care about it.