Re: Proposal: Don't require users to use undefined

Hi all, On 27.10.2010, at 09:01, Bas van Dijk wrote:

On Wed, Oct 27, 2010 at 7:57 AM, Michael Snoyman wrote:

...

On Wed, Oct 27, 2010 at 7:51 AM, Bas van Dijk wrote:

...

On Tue, Oct 26, 2010 at 9:09 PM, Henning Thielemann wrote:

...

4. In the future you may deprecate the immediate use of 'sizeOf' and 'alignment'.

We could deprecate sizeOf immediately in favor of sizeOfTagged. Deprecating it doesn't break any code but does gives warnings so that users are encouraged to upgrade. I don't see a reason to wait.

We can't immediately switch to using sizeOfTagged since many people will still be using old versions of base. If we waited one cycle to deprecate the old functions, it won't annoy people. By the next cycle, in theory a majority of people will already have sizeOfTagged, and it would be feasible to switch our code to sizeOf.

Yes, that's what I meant. We should {-# DEPRECATE #-} sizeOf now and provide sizeOfTagged as an alternative. In a further cycle we can remove sizeOf.

I think this whole proposal is a bad idea. There is a cost-benefit tradeoff in every library change. I do not see the problem that anybody is every going to accidentally evaluate sizeOf or alginment and get an unexpected "undefined" value back. I don't see the compiler optimization problem - it may exists but if the argument of Storage is fixed (and it always is in any use of Storage) then the compiler should be able to inline the 4 or 8 or whatever alignment evaluates to. So the only benefit I see is that code becomes slightly prettier. But it is not code that is read a lot, it's boilerplate code that is used internally. No sane Haskell library that interfaces to C exports Ptr values and expects the user to use sizeOf and alignment to operate on the C data structure. Instead C data structures are accessed using a Haskell interface. So the danger of library users calling sizeOf and getting an "undefined" is really zero. Even as a library maintainer, I've never managed to evaluate sizeOf by accident. In Gtk2Hs, we create a lot of Storable instances. If we were to implement the proposed change, we would have to manually edit a lot of code. There is no benefit for the user. None. There is only a lot of work. For future code, the benefit is also near to zero since, from my past experience, the problems that motivated this proposal do not exist in practice. Cheers, Axel