This page is part of the web mail archives of SRFI 72 from before July 7th, 2015. The new archives for SRFI 72 are here. Eventually, the entire history will be moved there, including any new messages.
bear <bear@xxxxxxxxx> writes: > On Sun, 21 Aug 2005, Michael Sperber wrote: > >>bear <bear@xxxxxxxxx> writes: >> >>> Check me if I'm wrong, but as far as I know the only real problem with >>> that was the performance hit. > >>No, the problem is the loss of abstraction. > > It has always been my position that abstraction is something > the programmer does voluntarily, not something that any automatic > system can or should attempt to do. Attempting to automate > abstraction locks in forms of abstraction which are sometimes > wrong. I have no clue what you mean by "automatic abstraction"---I was suggesting that the specification and the implementation be changed, and I was presuming that would happen manually, by the hand of Andre. >>> I mean, if there were no performance problems, wouldn't it be more >>> powerful to be programming in a lisp where there were no separate >>> macroexpansion and compilation phases, and all the semantics were >>> available at runtime? > >>You're joking, right? > > Actually, no, I'm not. That's a substantial part of what > set Lisp apart initially; that's part of _WHY_ it was the > most powerful programming language ever developed. Separating > phases "for abstraction" seems to me a lot like static typing > with required declarations "for error checking." That is, it's > not a completely bad idea, and absolutely appropriate for some > languages, but it's also not consistent with maximum > expressiveness. The analogy is inappropriate because we're not talking about preventing situations that aren't errors, as static checking does. Phase violations are always errors, and the lack of checking in Common Lisp causes no end of pain. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla