bear <xxxxxx@sonic.net> writes:

> On Sun, 21 Aug 2005, Michael Sperber wrote:
>
>>bear <xxxxxx@sonic.net> 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