Subject: Re: Core Lisp (was Re: cautios question (about languages))
From: Erik Naggum <>
Date: 1999/07/30
Newsgroups: comp.lang.lisp
Message-ID: <>

* Chuck Fry
| What's the difference between "proto-Lisp" and "Core Lisp"?  No one has
| so much as posted a hypothetical description of a Core Lisp, so where is
| your basis for comparison?

  a proto-Lisp is very close to the compiler and the machine and has access
  to a lot of low-level stuff, like pointers, representational details of
  complex types, etc, and allows you to isolate them from the exported
  Lisp.  as a Core Lisp has been described (by intended use), it would be a
  programming language in its own right, defining primitives upon which the
  rest of Common Lisp needs to be defined, but which are primitives and
  which need access to the machine is very hard to tell.  CLOS could be
  defined entirely in a Common Lisp sans CLOS, but to make it perform well,
  you need a lot of access to lower-level stuff.  efficient stream I/O is
  the same way, and the two combined really need special support to do well.

| >  this is wrong -- startup time is unaffected by total system size.
| Again, since no spec has been made available for comparison, I don't see
| how one can draw a conclusion either way.

  by watching other systems, large and small, of course.  size of the
  system has nothing to do with it.  that is, other factors are so much
  more important that system size becomes completely irrelevant.

| >  haven't various people tried to produce a Core English already?  
| What does that have to do with programming languages?

  if you ask hard enough questions, no answer about programming languages
  has to do with programming languages.  take Kent's many philosophic,
  linguistic, and psychologic comments.  they aren't about programming
  languages per se, but about people defining and using programming
  languages, and as long as we are human, that actually has strong merit.

  if we aren't considering humans, however, a lot more options become
  available in programming language design, and none of the lessons learned
  from other experiments involving languages and humans have any bearing on
  what we do.

| Users have been screaming for a core + libraries architecture for years.
| It's time we gave it to them.

  users have asked for features and extensions to Perl and C++, and that's
  what they got.  I think the tobacco industry uses the same core argument.
  the good way is to give people what they need to be happy, not what they
  want.  they want core + libraries, but that's not what they need, as
  every person who has set out to do this in the past have discovered.
  what they _do_ need is very hard to figure out as long as they keep
  thinking they need core + libraries.  the problem is: when people _get_
  core + libraries, they want languages with everything in them, because
  it's a terrible mess to deal with core + incompatible and overlapping

  let's take a good look at what core + libraries would solve, and let's at
  least pretend that core + libraries is not the solution.  which _other_
  ways to obtain the desiderata will we find in our search?

  suppose we blasted all politicians into space.
  would the SETI project find even one of them?