There seems to be some resistance amongst CL people to the idea of
further standardisation. I think it would be a good idea, here is
why...
There is within the community of a programming language there is a
language that the community uses. That language isn't always the one
specified by the standards applicable to that language. Often parts of
the standards are rejected as unuseful or over-complex, often
additional parts are added to as new applications arise. Mostly both
seem to occur, so the language in active use at a particular time is
both a subset and of the standard language and also an extension of it.
It seems that some people think that it's sufficient to extend the
Common Lisp language by adding libraries to it, or adding features to
some implementations. That is, extending it using libraries is all
that is necessary, no change or augmentation to the existing language
standard is needed. I think this is a mistake.
There are three reason I can see why extending CL using standards is
far more preferable and useful to extending it with libraries.
1. Testing
Complex libaries have complex interactions with their host lisp.
Normally this is OK, but can be a problem in the presence of bugs. What
happens for example if its not obvious if the library writer or the
lisp is to blame. Probably the lisp authors will assume the lib is at
fault and simply ignore it. Probably the lib author will assume the
lisp is at fault and assume it is broken and no progress will be made.
If the failure actually means failure to meet a standard
people will take it more seriously. They may also test for it in
automated tests making anything that breaks it easier to track down.
1. Trade descriptions
How do you improve the library? Let's assume that library FOO has been
written and is extremely popular. FOO-lib does low-level things, it
doesn't always work well on every CL implementation. As a result some
lisp vendors decide to optimize FOO for their specific lisp.
This is relatively easy and results in notable gains. The problem the
vendor has now is how does he/she describe the function on offer. He
could say "FOO-lib provided" but that would be dishonest, it's better
to say "FOO compatible library provided". I expect most would say
this. A vendor could also try to ensure that the FOO they provided
behaved the same as the normal library FOO. Probably some would, but
not necessarily all. A question then arises when there is difference
in behaviour, who is doing it right? If there were a standard it would
be clear, if there are only libraries then the answer is probably the
one with the most users. The same problem can occur of-course if there
are standards, it has in the web for example. But it is less likely
because when there is a standard there is at least a benchmark for
correct behaviour.
2. Changes
Lets say the author of Foo-lib decides it's badly designed. As a
result they redesign it. The redesign is incompatible with the
original design. To the authors this is OK, since all the programs
they maintain use FOO-lib heavily in complex ways. The benefits from
the redesign outweigh the costs of changing the interfaces. This may
not be true of other users of the library, to them the change may be
very difficult indeed. The problem here is that the authors of Foo-lib
have no reason to behave otherwise. Notionally, they control the name,
what they say is Foo-lib is just that. If they had a standard to
follow they may behave differently, or they may decide to abandon it
and create something new on their own. But if there was a standard
then everyone else would at least be aware that they were doing this.
And, another three reasons why I think extending it with standards is
better than extending each implementation ...
1. Implementations die
>From time to time for various reasons people stop working on computer
programs. It doesn't matter if they are free software, open source or
proprietry, it happens. Any programmers who have relied on the
extensions on an implementation in their code are screwed when this
happens. In the short term this isn't a problem, if you're writing a
program to last say 5 years, but if you're attemping to write one to
last 10 or 20 it's a different matter.
2. Changes
This is really the same argument as I made for changes to libraries.
People take their own established standards less seriously than real
standards, they feel they have the right to change them. A nice
demonstration of this would be people who used the GCC extensions in
the GCC2 series. Some of these extensions have been removed from GCC3
& 4 since the authors decided that they were "badly thought out".
Others have been subtly changed as C standards bodies took a slightly
different view to GCC.
Lastly, everyone says standardisation is expensive. This isn't
necessarily true, Common Lisp standardisation was expensive certainly,
but other efforts haven't been so bad. Simple standardisation can
easily be done by setting up something like the SRFI or CDR website and
soliciting feedback.
Rob Thorpe wrote:
> There seems to be some resistance amongst CL people to the idea of
> further standardisation. I think it would be a good idea, here is
> why...
>From what I've observed, CL people differ with each others
views and/or opinions all the time. It's not surprising that
they'd have different opinions on this issue, given that
they'd hardly ever be inclined to agree on anything anyway.
>
> There is within the community of a programming language there is a
> language that the community uses. That language isn't always the one
> specified by the standards applicable to that language. Often parts of
> the standards are rejected as unuseful or over-complex, often
> additional parts are added to as new applications arise. Mostly both
> seem to occur, so the language in active use at a particular time is
> both a subset and of the standard language and also an extension of it.
>
It is usually necessary (in most standardised languages) to
extend an implementation in order to do anything useful with
it. I see no reason why CL should be any different in this
regard.
> It seems that some people think that it's sufficient to extend the
> Common Lisp language by adding libraries to it, or adding features to
> some implementations. That is, extending it using libraries is all
> that is necessary, no change or augmentation to the existing language
> standard is needed. I think this is a mistake.
>
So do I. There are already too many /standard/ functions
which are used inconsistently (wrt to each other). I really
cannot see what the standard library is missing that cannot
be written using the current standard library (no doubt,
some expert and longtime user of lisp would enlighten me:-).
> There are three reason I can see why extending CL using standards is
> far more preferable and useful to extending it with libraries.
>
> 1. Testing
> Complex libaries have complex interactions with their host lisp.
> Normally this is OK, but can be a problem in the presence of bugs. What
> happens for example if its not obvious if the library writer or the
> lisp is to blame. Probably the lisp authors will assume the lib is at
> fault and simply ignore it. Probably the lib author will assume the
> lisp is at fault and assume it is broken and no progress will be made.
> If the failure actually means failure to meet a standard
> people will take it more seriously. They may also test for it in
> automated tests making anything that breaks it easier to track down.
>
I think splitting up the /library/ part of CL and the
/implementation/ part would actually be better. For instance,
one would then be able to specify that one's implementation
is a fully conformant /freestanding/ ANSI Common Lisp; someone
else can write the standard libraries and claim that the
library is a fully conformant /ANSI Common Lisp/ library.
> 1. Trade descriptions
<snipped stuff I agree with>
>
> 2. Changes
<snipped more stuff I agree with>
>
> And, another three reasons why I think extending it with standards is
> better than extending each implementation ...
>
> 1. Implementations die
<snipped yet more stuff I agree with>
>
> 2. Changes
<snipped even more stuff I agree with>
>
> Lastly, everyone says standardisation is expensive. This isn't
> necessarily true, Common Lisp standardisation was expensive certainly,
> but other efforts haven't been so bad. Simple standardisation can
> easily be done by setting up something like the SRFI or CDR website and
> soliciting feedback.
The problem with standardisation, to my newbie mind, is that
a burgeoning standard does not necessarily imply a better
(or even more complete) standard. The standardisation process
should rather look at current implementations, examine the
extensions (and why they were added) and *then* decide which
of the popular extensions make it into the standard.
This process is consistent and then the standard will reflect
reality as what gets standardised will be what is most being
used (the standard should reflect current implementations
as fully and as representatively as possible). Is CFFI in the
standard? It certainly will get adopted if the above process
is followed; maybe an addendum can list proposed and deprecated
stuff (proposed: clsql, cells)?
<grin>
Hell, I figure instead of a standard of 1000 pages or more,
we may as well just write a reference implementation that
will come in under 1000 pages and call that the ANSI standard.
Same difference, less ambiguation. Instead of writing the
standard, fit an implementation into the same space.
goose,
64000 lines of code for a reference implementation is more
than enough (64 lines of code fit on one page of my text
printer).
Rob Thorpe wrote:
>
> Lastly, everyone says standardisation is expensive. This isn't
> necessarily true, Common Lisp standardisation was expensive certainly,
> but other efforts haven't been so bad. Simple standardisation can
> easily be done by setting up something like the SRFI or CDR website and
> soliciting feedback.
>
CDR is there. Just go ahead, work on something concrete, and start
submitting. ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
"Rob Thorpe" <·············@antenova.com> writes:
> There seems to be some resistance amongst CL people to the idea of
> further standardisation. I think it would be a good idea, here is
I think the reason is much more mundane: there are not enough people
with enough skills, time, and energy for that.
> Lastly, everyone says standardisation is expensive. This isn't
> necessarily true, Common Lisp standardisation was expensive certainly,
> but other efforts haven't been so bad. Simple standardisation can
> easily be done by setting up something like the SRFI or CDR website and
> soliciting feedback.
Standardization might be a bit more complicated than it looks. See
for example the update section of this project:
Project FreeSpec
http://wiki.alu.org/Project_FreeSpec
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
From: Friedrich Dominicus
Subject: Re: The Argument for Standards
Date:
Message-ID: <87ejummn0c.fsf@flarge.here>
Paolo Amoroso <·······@mclink.it> writes:
> "Rob Thorpe" <·············@antenova.com> writes:
>
>> There seems to be some resistance amongst CL people to the idea of
>> further standardisation. I think it would be a good idea, here is
>
> I think the reason is much more mundane: there are not enough people
> with enough skills, time, and energy for that.
Well I guess enough skills would be there, enough time less so but if
the Common Lisp standardization works as the C standardization then
you have to invest quite some money (really) what would be the gain?
>
>
>> Lastly, everyone says standardisation is expensive. This isn't
>> necessarily true, Common Lisp standardisation was expensive certainly,
>> but other efforts haven't been so bad.
Well and others are even worse.
Just one thing which I won't ever understand in the c groups the
completly broken gets is still vindicated. And the resitance for
getting rid of the proven insecurities is unbelievable high.
This all in the name of "backward compatbility". I have not idea how
about that in Common Lisp. If that is "similiar" then, getting on is
as easy as moving a mountain ;-)
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Friedrich Dominicus wrote:
> Paolo Amoroso <·······@mclink.it> writes:
>
> > "Rob Thorpe" <·············@antenova.com> writes:
> >
> >> There seems to be some resistance amongst CL people to the idea of
> >> further standardisation. I think it would be a good idea, here is
> >
> > I think the reason is much more mundane: there are not enough people
> > with enough skills, time, and energy for that.
> Well I guess enough skills would be there, enough time less so but if
> the Common Lisp standardization works as the C standardization then
> you have to invest quite some money (really) what would be the gain?
Hopefully making it easier to write portable Common Lisp.
> >> Lastly, everyone says standardisation is expensive. This isn't
> >> necessarily true, Common Lisp standardisation was expensive certainly,
> >> but other efforts haven't been so bad.
> Well and others are even worse.
> Just one thing which I won't ever understand in the c groups the
> completly broken gets is still vindicated. And the resitance for
> getting rid of the proven insecurities is unbelievable high.
>
> This all in the name of "backward compatbility". I have not idea how
> about that in Common Lisp. If that is "similiar" then, getting on is
> as easy as moving a mountain ;-)
Yes. I don't think anyone will get anywhere revisiting old decisions
and trying to clean things up. CL programmers are as attached to CL's
cruft as C programmers are to C's, probably even more so. But adding
things can't be so hard, can it?
"Rob Thorpe" <·············@antenova.com> writes:
> Yes. I don't think anyone will get anywhere revisiting old decisions
> and trying to clean things up. CL programmers are as attached to CL's
> cruft as C programmers are to C's, probably even more so. But adding
> things can't be so hard, can it?
Just do it and let us know whether it was hard.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net