[jhc] Re: Ids in Jhc.

[John Meacham]

On Thu, Feb 14, 2008 at 10:10:54PM +0100, Lemmih wrote:
> On Thu, Feb 14, 2008 at 8:01 PM, Samuel Bronson <naesten at gmail.com> wrote:
> > On 2/14/08, Lemmih <lemmih at gmail.com> 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⑈