"Kent M Pitman" <······@world.std.com> wrote:
>> Please tell me the parts of (1)Common Lisp (2) Scheme that are "broken
>> as designed".
>
> why? in what context do you ask the question? what use do you plan to
> make of the information? what do you mean by broken?
Personal interest - specifically for some possible point in the future if
I reimplement a lisp-alike, I don't want to make any of the same mistakes.
Broken in this context means:
- inconsistencies in the spec such that conforming implementations can
fail to interoperate. especially subtle ones I might make again myself.
- misfeatures that make implementation unnecessarily hard, or
resource-wasteful, or unnecessarily force the runtime to be more complex
- security holes, things with unintended consequences
- design slips that make the language less generally useful than could
have been possible, or make certain uses impractical or impossible
- ugly special-cased hacks that break out of the cleanness of the design
- design anachronisms, language features unhelpfully tied to dated tech
limitations
etc etc. That sort of thing.
>"i'm designing my own language, what should i do differently".
That's more or less the context, without any implied promise of imminent
action ;-)