On Thu, Feb 14, 2008 at 10:10:54PM +0100, Lemmih wrote:
On Thu, Feb 14, 2008 at 8:01 PM, Samuel Bronson
wrote: On 2/14/08, Lemmih
wrote: I mean something like: data Id = Phantom | Unnamed Int | Named Atom Giving special meaning to numbers seems like a hack. Optimizations should not come at the sacrifice of readability.
It's not a hack if you use a newtype... at least, not observably. Yhc didn't, and it did do some really nasty stuff. (Possibly nhc predated newtypes?)
If you hide the implementation then you might as well provide the user with an ADT instead of an Int.
The newtype Int _is_ an ADT. as in, all that will be exported from Name.Id is Id(). Haskell's ability for abstraction is one of its great qualities. :) Exposing it abstractly would be something I'd want to do no matter how it was implemented, The internal representation doesn't matter as long as the API is clean and APIs are what I care about.
The optimizations in Jhc seems to be geared towards making things more "basic". Data types are unrolled so they can fit in an integer, Haskell code is replaced by C code. These optimizations give the illusion of improvements at the cost of readability. Rewriting a piece of Haskell code in C is rather silly when it is the algorithm that's broken.
It is about providing a strong foundation with good abstract APIs. Hopefully it will get to the point where these little things do make a difference. I don't find it hurting readability really. or if it does, that is more of an issue of documentation. like having to look inside how ids are represented means that I didn't document how they behave externally enough rather than the representation needs to change. John -- John Meacham - ⑆repetae.net⑆john⑈