>>27
It will never go anywhere. Those who care about performance will always produce programs that can be reasonably compiled. Those who care about
fexprs can write an interpreter any time they like.
This argument is like saying that I am unreasonably restricted by a law requiring people to drive on a particular side of the street. In practice, such freedoms make it extremely difficult to accomplish anything. In those instances where such regulation is prohibitive, we can eliminate them easily enough (e.g. parking lots).
fexprs are like turning lexical lisps into C++. In C++ you only
think you know what a statement like
x = a + b equals at a glance, until you have to look up the definitions of a and b, and then find out whether someone ``cleverly'' redefined
+ for such objects. This is
unmaintainable garbage of the highest order.
You see that commented very plainly at the LtU thread:
(define (foo f)
(f (+ 2 3)))
Seems like you know what this does, right? But, whoops! You can't! Because
(+ 2 3) isn't
5 all the time. In defense, one poster says:
Have fexprs but just make sure it isn't too hard to write code in a style that makes it trivially apparent to a compiler that the hard / impossible cases won't show up.
And now we have all kinds of fucking garbage keywords and syntax as compiler hints.
No thank you,
Bjarne.