Re: professional package use?

In article <873bq02mrd.fsf@xxxxxxxxxxxxxxxxxx>,
Don Geddis <don@xxxxxxxxxx> wrote:

> >> > Ron Garret <rNOSPAMon@xxxxxxxxxxx> wrote on Tue, 26 Jul 2005:
> >> > > CL is missing a feature, namely, first-class top-level lexical scopes,
> >> > > what in T were called "locales", what in modern functional programming
> >> > > languages are called "modules."
>
> >> Don Geddis <don@xxxxxxxxxx> wrote:
> >> > FWIW, this idea sounds promising. I certainly wouldn't object to its
> >> > being fleshed out and proposed as an enhancement to ANSI Common Lisp.
>
> > Ron Garret <rNOSPAMon@xxxxxxxxxxx> writes:
> >> So how do I go about proposing it?
>
> Kent M Pitman <pitman@xxxxxxxxxxx> wrote on Wed, 27 Jul 2005:
> > Figure out what you want it to do. Spec it out to at least your
> > own satisfaction.
> > Figure out if you can implement it yourself as a user. If you can, do so.
> > If you can't, figure out if you can implement it in either a free
> > CL where you have access to sources or talk a vendor into why it's
> > important enough to implement.
>
> It seems to me that a good model for this, and a topic fairly close to your
> module idea, is system definitions. That's also not part of the ANSI CL
> spec,
> and yet desired by almost any programmer of significant CL systems.
>
> Very early on, MK:DEFSYSTEM got implemented, passed around, and became a
> de facto expectation, if not quite a standard. And there's even a
> competitor:
> ASDF:DEFSYSTEM is quite popular these days. Such layered "standards" didn't
> require changing the ANSI CL spec, but are so useful that some
> implementations
> (such as CMUCL) automatically include them in the basic lisp image.
>
> Is there any reason that your idea couldn't follow the path of DEFSYSTEM?

Of course not, but you're missing the point. This isn't about locales.
I don't care if they are adopted or not (well, that's not quite true --
it would be nice to see them adopted, but that's not the point). I am
just using the locales experience as an illustration. I could just as
easily have made the same point with mk:defsystem actually, but I'm not
nearly as familiar with its history, so it's easier for me to use my own
experience. I'm less likely to get tripped up by simple ignorance.

Consider:

http://www.python.org/doc/current/modindex.html

This page is one of Python's big selling points, I claim. Here you can
find, all gathered in one place, a very large collection of (evolving)
extensions to Python that have been in some sense "blessed" by the
Python community. (Python has the advantage of having a benevolent
dictator at the helm, which makes it easier for them to do this, but
that too is beside the point.) Actually, what you find there is not the
extensions themselves, but *specifications*. CL has nothing analogous.
CL only has anarchy and free market forces resulting in "emergent" de
facto standards in varying degrees of de factoness. Python has all that
too, but, crucially, it also has a mechanism for saying "Yey verily."
CL does not. And this is bad for CL IMO because it makes it harder for
newbies (and non-newbies for that matter) to assess the current state of
things, yada yada yada.

rg
.

Relevant Pages

  • Re: perl to python
    ... > requiring more typing to get the same effect. ... The spec didn't say how to handle improperly formatted data. ... But then, eof is handled wrongly, and the loop doesn't exit. ... Try your test again with 'python -u'. ...
    (comp.lang.python)
  • Re: float("nan") in set or as key
    ... A foolish consistency to the spec would be a hobgoblin for little minds. ... which then becomes problematic with Unicode. ... That's why in Python 3 the Unicode text type is called ‘unicode’, ...
    (comp.lang.python)
  • Re: Using both keyword=something and *unknownqty arguments in a function
    ... I think there's a deeper issue here: you want Python to assign default args ... and it may get it wrong, which means the programmer has to figure out ... and hence has to sort through a complex spec. ... is always on us, in the end, to learn to use a language. ...
    (comp.lang.python)
  • installing my own module: module not recognized
    ... I followed the online docs on how to create and install a module. ... setup.py install seems to work fine, I did python setup.py register as ... from Spec.analysis import * complains that there is no ... from Spec import * gives the same complaint. ...
    (comp.lang.python)
  • Re: Private functions and inheritance
    ... Maciej Blizi?ski wrote: ... (BTW, there is no:: operator in Python. ... probably goes along with Python's spec, ...
    (comp.lang.python)