Re: What kind of Lisp should I learn if I want to start programing with Lisp?

In article <hcSdnbNwZf3H9BPUnZ2dnUVZ_gWdnZ2d@xxxxxxxxxxxxx>,
rpw3@xxxxxxxx (Rob Warnock) wrote:

joswig@xxxxxxxxxxxxxxxxxxxxxxx <joswig@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
+---------------
| p...@xxxxxxxxxxxxxxxxx (Pascal J. Bourguignon) wrote:
| > Rainer Joswig <jos...@xxxxxxx> writes:
| > > EQUAL a gf.
| >
| > This cannot be, in a subset of CL.
| >
| > The criteria is that a program written in the subset must
| > execute the same in CL.
...
| > ...[example]...is not a valid CL program, therefore CL:EQUAL
| > being a generic function cannot be in a subset of CL.
|
| Let's put it in a different package let it call CL:EQUAL
| if necessary (or whatever low-level, even implementation
| specific equal tests). Alternatively one could
| implement the functionality in the new package
| and provide a CL package (a legacy compatibility package ;-) )
| that just calls the new functionality.
| So CL:EQUAL is a function that calls GL:EQUAL.
| 'GL' = Generic Lisp.
+---------------

That's still not a "subset of Common Lisp", since a subset
must not require any special macros or libraries to be loaded
into the full CL first:

1.7 Language Subsets
...
For a language to be considered a subset, it must have the property
that any valid program in that language has equivalent semantics and
will run directly (with no extralingual pre-processing, and no special
compatibility packages) in any conforming implementation of the full
language.

Of course, you could *define* a subset of your GL, say, "GL-",
that was a proper subset of CL, but it doesn't sound like your
full GL is going to be one.

I would not adhere to the standard words where not applicable.
The designers of Common Lisp somehow failed to address
the compatibility problem also. Lots of people used
CLtL1 Common Lisp. Then ANSI CL appeared. Could you
load a non-trivial CLtL1 program into an ANSI CL?
It failed already at IN-PACKAGE. That was a typical
experience - the changes to IN-PACKAGE were trivial,
but you had to change every file (which was using
IN-PACKAGE). For the period of time (many years)
where CLtL1 and CLtL2 (and later) Lisps were used,
one had to put support for both forms of package
functionality into the sources. For some years now,
when I see CLtL1 compatibility code, I take it out,
- it is no longer a problem - because CLtL1 is no
longer relevant. Every time I see a file where
huge feature terms (#+ #- #feature-case ...) is used
around basic Lisp functionality (pathnames, packages, ...)
I can now get rid of almost all of them and have
the code be portable.

So, if we define some derivative of CL, how to deal with that
problem of compatibility with an older standard. Is our
solution constrained by every word of the ANSI CL standard?

Your "GL" proposal (and ISLISP, and others mentioned) actually brings up
a basic problem with subsets of CL [that I mentioned before, albeit
indirectly], namely, that CL has so many not-quite-orthogonalities
that one is strongly tempted to "fix" some of them in the process of
defining a smaller language... whereupon one ends up with something
that isn't a proper "subset".

That's true. I would really look at two different goals.

* a 'real' subset of Common Lisp that still is useful for some
purpose (education, implementation vehicle, ...)

* an intellectual subset of Common Lisp, using reduction
principles.
As an example see aref, bit, char, elt, svref, ...
Just replace all those with a generic function
REF and skip the rest. Then one principle to shrink
the language would be to replace all type specific
functions with methods for fewer generic functions.

But if one *doesn't* fix them, then the corners that are left sticking
out tend to drag in far too much of full CL, and the "smaller" language
ends up being not that much smaller after all.

It's quite a dilemma, actually...

Right. If you look at the simplified Common Lisp named
(prefix) Dylan, the first described version was more
reduced by omitting things (like IO) and a target
domain that had limited requirements (delivery).
Then you start adding those things. Then there
are interactions with the rest of the language. The condition
system for example is the only part of the CL language
that deals with handling conditions and errors - but
it makes absolutely sense to use/integrate it in other
parts (like describing errors in terms of conditions,
having ASSERT using it, etc.). It would be equally
useful to have CLOS classes used for streams.
Unfortunately that's not in the standard. Fortunately
that's still provided by implementations, because it
is useful.

--
http://lispm.dyndns.org/
.

Relevant Pages

  • Re: Haskell: functional languages vs Lisp
    ... > most of the functionality that lisp provides but with a much cleaner ... There exist many subsets of Common Lisp. ... It's not quite clear what you mean by "true" functional language. ...
    (comp.lang.lisp)
  • Re: CLOS usage patterns?
    ... >>Common Lisp has CLOS, which is, I think, the single ... >>most complete set of OO functionality in any language. ... >>anywhere that's not in CLOS, I'd like to hear about it. ...
    (comp.lang.lisp)
  • Re: CLOS usage patterns?
    ... > Common Lisp has CLOS, which is, I think, the single most complete ... > set of OO functionality in any language. ... > any OO technique implemented anywhere that's not in CLOS, ...
    (comp.lang.lisp)
  • Re: CL & Practicality
    ... but Java probably has more than twenty times as ... > many as Common Lisp, depending on what you consider to be the equivalent ... You're conflating core language and core language+library issues but yes, ... the best way to discover the practicality of Common Lisp is to ...
    (comp.lang.lisp)
  • Re: How Common Lisp sucks
    ... necessities in today's world. ... getting acceptance of a considerable number of members in the Common Lisp community. ... Now you are apparently invoking a defacto standard. ... If we don't find a single example for changing the language in a fundamental way that would actually make the language easier to understand for newbies without loosing expressiveness, ...
    (comp.lang.lisp)