POS, OOFS, CL v Scheme, etc.

[Marc Wachowitz]

hbaker@netcom.com (Henry G. Baker) wrote:
> I realize that 'fragmentation' is a problem, but most of that
> fragmentation was caused by real needs.
[...]
> If you find yourself tripping over the language more than once, then
> stop tripping and fix the language!

It's probably true at least for old dialects. I'm not yet convinced
whether what we're discussing here really needs to create yet another
incompatible dialect, rather than a clean extension. For Common Lisp,
its size, complicated interactions between various features and a very
detailed definition are a problem, but Scheme still appears to be a
sound base, leaving much room for fixes (e.g. the report does even
tell explicitly that it doesn't presume to specify the behaviour of
implementation-dependent extensions, mentioning EQV? and "uninterned
symbols" in one example).

As long as our needs can be expressed as new types/procedures/syntax,
or extensions of existing procedures for cases which they currently
don't understand, we can stay clean. I don't have the impression that
there's anything in the standard which we absolutely must get rid of,
and which couldn't be solved via embedding in a good module system with
standard behaviour for unsuspecting modules. Do you see any concrete
difficulties in that area? If there's a tendency (even of a subgroup)
towards Scheme, I'm willing to walk through the report to look for
potential problems and suggest how standard procedures should behave
in the presence of some particular extension. Depending on the nature
of the extensions and the necessary environment, I might even create at
least a prototype implementation (but I doubt whether I'm qualified
for a high-performance implementation with extremely clever inference
and such stuff, or the low-level details for an excellent garbage
collector cooperating with lots of hairy operating system facilities
or memory managament hardware).

> Remember, the goals of CL didn't seem to include LispOS goals --
> notice no threads or anything remotely reflective (except CLOS itself)
> -- so some surgery will be required no matter what.

Neither threads nor reflective capabilities would imply non-conformance
(of the implementation) with the standard, as far as I can tell; just
make sure extensions live in a different package, or extend a standard
feature in an accepted way (e.g. a function which understands a larger
variety of arguments and does interesting things with non-standard types).

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>