[cltl3-devel] RFC: CLtL3 Charter

[Drew Crampsie]

2009/9/1 Malcolm Reynolds <malcolm.reynolds at gmail.com>:
> On Tue, Sep 1, 2009 at 6:21 PM, Drew Crampsie<drewc at tech.coop> wrote:
>> 2009/9/1 Gustavo <gugamilare at gmail.com>:
>>> Hello,
>>>
>>> I also like to keep things simple. Here are a few suggestions, though.
>>>
>>> In paragraph 4, you didn't mention "sockets" explicitly in the list. I don't
>>> know if that is intended to be included in "Networking", because Unix
>>> sockets are local to the computer.
>>
>> To be quite honest, i don't know if CLtL3 actually needs sockets or
>> networking. If we have FFI and extensible streams, we can build
>> sockets and networking as library code.. right? I'm interested in
>> hearing dissent on this one.
>>
>
> I've only been working with CL for 6 months so take all my opinions
> with that in mind.. but I think not having native sockets / networking
> is a big minus for a language in this day and age.

Section 2 of the charter mentions a 'standard library', which will
include sockets and networking code. It is a lot easier, as a
community,  to ship a library than it is implementation-specific code.
You, as a user, would use the 'standard library' and not care.

>To a relative
> beginner like me, having to use FFI (I know what this is but have
> never touched it myself) and extensible streams (I don't really have a
> concrete idea of what these entail, is it in any way similar to Java
> *OutputStream classes?) just to write to the network seems like quite
> a lot of hoops to jump through as opposed to just using some
> standardised functions.

As a user, you would not need to write your own networking library
just to use the network.. library implementors would do this for you,
as they do now. The fact is that current implementations build their
networking code on the equivalent of FFI and extensible streams, so
that's all that really needs describing (read 'standardised') in order
to build a portable sockets/networking library.

>And I understand the situation now is that
> there are a plethora of networking libraries, which no doubt causes
> confusion when coming to the language for the first time...

The goal of the CLtL3 project is not to make the language easier for
those using it the first time, it's to provide a solid foundation for
library authors and promote portability among implementations. Many
things in CL are confusing to newcomers, and it is not our expressed
goal to change this.

Rather, the goals of CLtL3 are to provide enough of a "Common Lisp"
base language so that things like networking libraries and the like
may be implemented using portable constructs rather than
implementation-specific ones. As a newcomer, this may not seem as
important to you has using the same network library as everyone else,
but from those trying to provide that networking library, it's
extremely important... vital even.

> I think
> forcing implementations to include network code which you can rely on
> to be maintained and debugged is a big win.

"forcing implementations" is not something we want or plan to do. We
rather hope to keep things simple enough that the cost of adoption for
implementations is a minimal as possible. If we have to force
implementors to do anything, we'll have lost the battle before it's
even begun.

For a new user like yourself, it's not going to matter if networking
is in CLtL3 or the 'standard library' whatsoever. For an implementor,
not having to support all that extra code in the library is a big plus
and lowers the barriers to adoption... they can just ship CLtL3
compatibility, and let us worry about the 'standard library'.

Which do you think is better, many implementations of the same
protocol scattered among lisps, or a single-sourced library built on
portable constructs that have been provided by each implementation? My
opinion is that the latter is likely to provide a better user
experience with less effort to implementors than the former, and hence
more likely to see wide adoption.

I'm playing devil's advocate to a certain extent, so please don't take
my arguments as a brushing off of your needs. I'm interested in
hearing rebuttals and more dissent, but the goals expressed in the
charter must be kept in mind... keeping CLtL3 small and simple is the
only way it's going to work, and if we can remove the need to describe
something large and complex like networking and sockets, we'll have a
better chance of actually achieving something rather than just arguing
about it :).


Cheers,
drewc







>
> Cheers,
>
> Malcolm
>