One might say it is hack in the sense that it exposes lots of
implementation details to the programmer that the language implementor
(or even someone writing a library in the language) would like to keep
hidden.
For example, in mzscheme:
> (define (f) (lambda () 1))
> (eq? (f) (f))
#t
> (define (g x) (lambda () x))
> (eq? (g 1) (g 1))
#f
What you're seeing there is that the compiler can optimize the first
but not the second case (to avoid re-allocating the closure).
Eq exposes that stuff. And check out the contortions that r5 goes to
in order to underspecify eq's behavior to cope with such issues.
Robby
On 2/10/07, Carl Eastlund <cce_at_ccs.neu.edu> wrote:
> On 2/10/07, Lauri Alanko <la_at_iki.fi> wrote:
> > I consider eq? to be a hack. Now, I have nothing against it as such:
> > hacks are useful, and sometimes necessary. It is nice that there's a way
> > for the programmer to tell the compiler: "Trust me, I know what I'm
> > doing. Give me this little bit of performance, and if things go subtly
> > wrong, I'll carry the blame." However, I think hacks should only be
> > extraneous _additions_ to the language, and the language's design should
> > make sense even without them, for those who don't wish to take risks.
> > Without eq?, the lack of symbol=? is much more obvious, especially since
> > it would then be the fastest way of comparing symbols.
>
> I'm not sure I understand this claim. I do not view eq? as a hack.
> It's not (solely) intended to be "equal? lite", a faster version of
> equal? restricted to "small" values. It is still a meaningful
> comparison operator, even for cons cells: it's instance-equality, not
> structural-equality. Efficiency concerns aside, eq? is often useful
> for cases such as "if I set-car! one of these lists, will it affect
> the other?" instead of equal?'s purpose "do these lists contain equal
> elements?". So some uses of eq? may be a speed-hack, but others have
> an important and distinct meaning.
>
> --
> Carl Eastlund
>
> _______________________________________________
> r6rs-discuss mailing list
> r6rs-discuss_at_lists.r6rs.org
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
>
Received on Sat Feb 10 2007 - 13:54:04 UTC