elisp's cl package. Don't understand the notice about eval-when-compile

elisp's cl package. Don't understand the notice about eval-when-compile

[Xah Lee]

in emacs lisp's CL package documentation “(info "(cl)Overview")”, it
has this passage:

   *Please note:* the "CL" functions are not standard parts of the
Emacs Lisp name space, so it is legitimate for users to define them
with other, conflicting meanings.  To avoid conflicting with those
user
activities, we have a policy that packages installed in Emacs must not
load "CL" at run time.  (It is ok for them to load "CL" at compile
time
only, with `eval-when-compile', and use the macros it provides.)  If
you are writing packages that you plan to distribute and invite
widespread use for, you might want to observe the same rule.

I don't quite understand it.

If i distribute a package xyz.el, which calls

(eval-when-compile (require 'cl))

And, this package does not require users to byte-compile it. Then,
how's the eval-when-compile solve the name conflict problem?

does it imply that if you distribute a package using cl, it must be
byte compiled eventually?

  Xah
∑ http://xahlee.org/

☄

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Michael Ekstrand]

Xah Lee <xahlee@gmail.com> writes:
> in emacs lisp's CL package documentation “(info "(cl)Overview")”, it
> has this passage:
>
>    *Please note:* the "CL" functions are not standard parts of the
> Emacs Lisp name space, so it is legitimate for users to define them
> with other, conflicting meanings.  To avoid conflicting with those
> user
> activities, we have a policy that packages installed in Emacs must not
> load "CL" at run time.  (It is ok for them to load "CL" at compile
> time
> only, with `eval-when-compile', and use the macros it provides.)  If
> you are writing packages that you plan to distribute and invite
> widespread use for, you might want to observe the same rule.
>
> I don't quite understand it.
>
> If i distribute a package xyz.el, which calls
>
> (eval-when-compile (require 'cl))
>
> And, this package does not require users to byte-compile it. Then,
> how's the eval-when-compile solve the name conflict problem?
>
> does it imply that if you distribute a package using cl, it must be
> byte compiled eventually?

No, it just implies that if you distribute a package using cl, and you
want to be nice to your users, you will follow the guideline (only use
macros and put the require in eval-when-compile) and include a warning
or notice with the package that loading it directly from source will
import the cl package.  If this bothers them then they can byte compile
it.

Most substantial third-party packages for Emacs that I have come across
have an installation mechanism, frequently via some form of Makefile,
which performs byte-compilation, so it isn't an issue there.

- Michael

-- 
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files?  I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Thomas F. Burdick]

On Mar 25, 4:02 am, Xah Lee <xah...@gmail.com> wrote:
> in emacs lisp's CL package documentation “(info "(cl)Overview")”, it
> has this passage:
>
>    *Please note:* the "CL" functions are not standard parts of the
> Emacs Lisp name space, so it is legitimate for users to define them
> with other, conflicting meanings.  To avoid conflicting with those
> user
> activities, we have a policy that packages installed in Emacs must not
> load "CL" at run time.  (It is ok for them to load "CL" at compile
> time
> only, with `eval-when-compile', and use the macros it provides.)  If
> you are writing packages that you plan to distribute and invite
> widespread use for, you might want to observe the same rule.
>
> I don't quite understand it.
>
> If i distribute a package xyz.el, which calls
>
> (eval-when-compile (require 'cl))
>
> And, this package does not require users to byte-compile it. Then,
> how's the eval-when-compile solve the name conflict problem?
>
> does it imply that if you distribute a package using cl, it must be
> byte compiled eventually?

No. It's saying that if you are trying to get your package included in
the official Emacs distribution, you can only use macros from cl.el,
not functions.

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Xah Lee]

Xah Lee <xah...@gmail.com> writes:
> > in emacs lisp's CL package documentation “(info "(cl)Overview")”, it
> > has this passage:
>
> >    *Please note:* the "CL" functions are not standard parts of the
> > Emacs Lisp name space, so it is legitimate for users to define them
> > with other, conflicting meanings.  To avoid conflicting with those
> > user
> > activities, we have a policy that packages installed in Emacs must not
> > load "CL" at run time.  (It is ok for them to load "CL" at compile
> > time
> > only, with `eval-when-compile', and use the macros it provides.)  If
> > you are writing packages that you plan to distribute and invite
> > widespread use for, you might want to observe the same rule.
>
> > I don't quite understand it.

On Mar 25, 3:02 am, "Thomas F. Burdick" <tburd...@gmail.com> wrote:
> No. It's saying that if you are trying to get your package included in
> the official Emacs distribution, you can only use macros from cl.el,
> not functions.

Ok, after spent some 30 min starting to write a reply with much more
confusion, i think i understand this now and i think this is the best
explanation. Thanks.

though, there's still the practical question of which ones are macros.
There doesn't seem to have a clear list.

basically, my concern here is practical one. I want to use some
functionalities in cl, but need to know which i can use etc. So, if
programers using cl for their packages for public, they need to have a
list of exactly what they can use.

... after some 10 min thinking and reading the cl doc, at this point i
guess i don't have a question... i guess a clear list of macro isn't
there because the whole thing is rather complex... the cl package is
rather more for CL programers coming to elisp as opposed to simply a
extra library of useful functions...

here's some more confusion i have...

For example, when i do describe-function on “pop”, it says:
«pop is a Lisp macro in `subr.el'.»

but after loading cl, it says:
«pop is a Lisp macro in `cl.el'.»

So, it appears, cl package also shadow elisp symbols (apparantly they
are the same thing, but if so, why there's one in still in cl when
already moved to elisp?).

  Xah
∑ http://xahlee.org/

☄

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Jason Rumney]

On Mar 26, 10:12 am, Xah Lee <xah...@gmail.com> wrote:
> Xah Lee <xah...@gmail.com> writes:

> For example, when i do describe-function on “pop”, it says:
> «pop is a Lisp macro in `subr.el'.»
>
> but after loading cl, it says:
> «pop is a Lisp macro in `cl.el'.»
>
> So, it appears, cl package also shadow elisp symbols (apparantly they
> are the same thing, but if so, why there's one in still in cl when
> already moved to elisp?).

The doc string of the version in subr.el states "LISTNAME must be a
symbol whose value is a list", while the cl.el version handles non-
symbol values by calling cl-do-pop.

In general, cl versions with the same name provide a superset of the
elisp functionality.

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Thomas F. Burdick]

On Mar 26, 3:12 am, Xah Lee <xah...@gmail.com> wrote:
> Xah Lee <xah...@gmail.com> writes:
> > > in emacs lisp's CL package documentation “(info "(cl)Overview")”, it
> > > has this passage:
>
> > >    *Please note:* the "CL" functions are not standard parts of the
> > > Emacs Lisp name space, so it is legitimate for users to define them
> > > with other, conflicting meanings.  To avoid conflicting with those
> > > user
> > > activities, we have a policy that packages installed in Emacs must not
> > > load "CL" at run time.  (It is ok for them to load "CL" at compile
> > > time
> > > only, with `eval-when-compile', and use the macros it provides.)  If
> > > you are writing packages that you plan to distribute and invite
> > > widespread use for, you might want to observe the same rule.
>
> > > I don't quite understand it.
>
> On Mar 25, 3:02 am, "Thomas F. Burdick" <tburd...@gmail.com> wrote:
>
> > No. It's saying that if you are trying to get your package included in
> > the official Emacs distribution, you can only use macros from cl.el,
> > not functions.
>
> Ok, after spent some 30 min starting to write a reply with much more
> confusion, i think i understand this now and i think this is the best
> explanation. Thanks.
>
> though, there's still the practical question of which ones are macros.
> There doesn't seem to have a clear list.
>
> basically, my concern here is practical one. I want to use some
> functionalities in cl, but need to know which i can use etc. So, if
> programers using cl for their packages for public, they need to have a
> list of exactly what they can use.

The Emacs maintainers have a really schizophrenic policy when it comes
to cl.el, and it's resulted in a mess. On the one hand, they
distribute a bunch of language extensions as part of the distribution.
On the other hand, they disapprove of the very package they
distribute, so they don't want any other bundled code to use it. So of
course the extensions run the range from nice, idiomatic things that
ought to be incorporated into elisp (support for places/setf, for
example), to very useful extensions like loop, to strange duplications
of existing functionality (concatenate?), to bizzare and horrible
ideas like lexical-let.

If you want your code incorporated into the official Emacs
distribution, I would avoid cl.el altogether. Or maybe use loop and
setf, but I'm not sure you can count on them always expanding into cl-
free code. The reason there's no good documentation about what you can
use is that the Emacs maintainers frown on the whole package. So as a
practical matter, avoid it.

If you just have an elisp package that you want to make publicly
available, I see no need to avoid cl.el. It's distributed with emacs,
so there's no reason not to use it. Just, stick to the tasteful
parts :-)

> ... after some 10 min thinking and reading the cl doc, at this point i
> guess i don't have a question... i guess a clear list of macro isn't
> there because the whole thing is rather complex... the cl package is
> rather more for CL programers coming to elisp as opposed to simply a
> extra library of useful functions...

It's both. I think RMS has an irrational hatred of CL, so there are a
lot of the useful things in cl.el that should have migrated into the
core elisp. As it is, they're ghettoized along with the parts of that
package that exist just as a crutch for Common Lispers.

>
> here's some more confusion i have...
>
> For example, when i do describe-function on “pop”, it says:
> «pop is a Lisp macro in `subr.el'.»
>
> but after loading cl, it says:
> «pop is a Lisp macro in `cl.el'.»
>
> So, it appears, cl package also shadow elisp symbols (apparantly they
> are the same thing, but if so, why there's one in still in cl when
> already moved to elisp?).
>
>   Xah
> ∑http://xahlee.org/
>
> ☄

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Miles Bader]

"Thomas F. Burdick" <tburdick@gmail.com> writes:
> If you just have an elisp package that you want to make publicly
> available, I see no need to avoid cl.el. It's distributed with emacs,
> so there's no reason not to use it. Just, stick to the tasteful
> parts :-)
...
> It's both. I think RMS has an irrational hatred of CL, so there are a
> lot of the useful things in cl.el that should have migrated into the
> core elisp. As it is, they're ghettoized along with the parts of that
> package that exist just as a crutch for Common Lispers.

The problem with cl.el is that it's a giant glutinous mess, that seems
to offer the vague promise to be kinda-like-common-lisp, but really
isn't (it can't be, the elisp core cannot support much of common-lisp
efficiently), and as a result is kind of misleading to users (especially
to common-lisp users, who might think "oh great, I can just use
common-lisp!" ... hahaha, sorry bub...).

I agree that many _parts_ of cl.el are quite good, and useful, but while
you may be able to pick and choose wisely, I think many users aren't as
skillful, and would end up using the horrible grotty bits as well -- and
we really don't want to increase the number of dependencies on horrible
grotty things.

Personally, I'd use a different tactic for addressing this problem --
I'd try to split out the useful parts into separate packages (maybe a
"setf" package, a "struct" package, a "sequence" package etc), and pull
the best and simplest bits into core elisp -- but rms's approach is at
least simple and easy.

[Maybe in the future, elisp will gain more features will allow it to
better implement some of the parts it now can't do very well (e.g.,
multiple return-values and keyword arguments), but for now that stuff is
just muck.]

-Miles

-- 
Brain, n. An apparatus with which we think we think.

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Leo]

On 2009-03-25 10:02 +0000, Thomas F. Burdick wrote:
>> And, this package does not require users to byte-compile it. Then,
>> how's the eval-when-compile solve the name conflict problem?
>>
>> does it imply that if you distribute a package using cl, it must be
>> byte compiled eventually?
>
> No. It's saying that if you are trying to get your package included in
> the official Emacs distribution, you can only use macros from cl.el,
> not functions.

So many packages come up with their own ugly versions of functions that
are already in cl.el. I think this policy is utterly insane these days.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.

               www.git-scm.com
    git - the one true version control system

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Juanma Barranquero]

On Thu, Mar 26, 2009 at 09:58, Leo <sdl.web@gmail.com> wrote:

> So many packages come up with their own ugly versions of functions that
> are already in cl.el. I think this policy is utterly insane these days.

I wouldn't call it "utterly insane", but I certainly am on the
"please, just preload cl as XEmacs has been doing for years" group.

That is not going to happen, though. Apparently, the only way to go
forward with such functions is either:

 - turn them into cl macros, or
 - move them (or, as in push, pop, etc, dumbed-down versions of them)
out of cl, if they are deemed useful enough

Unfortunately, many of the sequence-handling operations that would be
really useful to have (reduce, find, count, member, etc. and their
variants) depend on keywords, so neither of the above fixes is going
to fly; at least, easily.

    Juanma

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Leo]

On 2009-03-26 09:32 +0000, Juanma Barranquero wrote:
>> So many packages come up with their own ugly versions of functions that
>> are already in cl.el. I think this policy is utterly insane these days.
> 
> I wouldn't call it "utterly insane", but I certainly am on the
> "please, just preload cl as XEmacs has been doing for years" group.

;)

> That is not going to happen, though. Apparently, the only way to go
> forward with such functions is either:
>
>  - turn them into cl macros, or
>  - move them (or, as in push, pop, etc, dumbed-down versions of them)
> out of cl, if they are deemed useful enough
>
> Unfortunately, many of the sequence-handling operations that would be
> really useful to have (reduce, find, count, member, etc. and their
> variants) depend on keywords, so neither of the above fixes is going
> to fly; at least, easily.

Emacs is resistant to innovations. This is going to kill it at some
point. But maybe it is good as it shows emacs is subject to 'survival of
the fittest' after all.

Having used GNU/Linux for 7 years and windows for 9 months, I am getting
my first macbook. I think paying a price for a good service, a peace of
mind and most importantly, saving hours and hours of time is far more
important in life than having the feeling of 'I'm using 100% free/open
source software', and the mac world is full of innovations. In this
regard, it seems the free software movement is out of touch.

I learnt from #emacs on freenode the saying "Free software is free if
your time is useless", which wakes me up to the guilt of wasting time.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.

               www.git-scm.com
    git - the one true version control system

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Samuel Wales]

Has the inclusion of cl.el caused big problems for anybody?  For most
things, experienced people seem to use a personal prefix.

If Emacs Lisp has been adopting cl.el for many years, why not fast forward?

Package developers and experienced users seem to use it a lot.  It is
not just for people who come from CL.

-- 
Myalgic encephalomyelitis denialism is causing death (decades early;
Jason et al. 2006) and severe suffering (worse than nearly all other
diseases studied; e.g. Schweitzer et al. 1995) and grossly corrupting
science.  http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Leo]

On 2009-03-26 15:09 +0000, Samuel Wales wrote:
> Has the inclusion of cl.el caused big problems for anybody? For most
> things, experienced people seem to use a personal prefix.

No, I don't think the problem lies in cl.el; it is more a political
decision or RMS personal preference.

>
> If Emacs Lisp has been adopting cl.el for many years, why not fast
>forward?
> 
> Package developers and experienced users seem to use it a lot.  It is
> not just for people who come from CL.

Many people have argued for this. Nobody can bend RMS's will. For this,
I rather have XEmacs around, which is welcoming innovations.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.

               www.git-scm.com
    git - the one true version control system

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Lennart Borgman]

On Thu, Mar 26, 2009 at 9:09 PM, Leo <sdl.web@gmail.com> wrote:
> On 2009-03-26 15:09 +0000, Samuel Wales wrote:
>> Has the inclusion of cl.el caused big problems for anybody? For most
>> things, experienced people seem to use a personal prefix.
>
> No, I don't think the problem lies in cl.el; it is more a political
> decision or RMS personal preference.

I have seen some problems, but I can't remember where any more.

Maybe changing this policy should be done after Emacs has a lot of
unit tests? (Someone started to work on this, but I do not know what
has happened.)

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Kevin Rodgers]

Leo wrote:
> Emacs is resistant to innovations. This is going to kill it at some
> point. But maybe it is good as it shows emacs is subject to 'survival of
> the fittest' after all.

Or the converse: Emacs is the environment, and alleged innovations
survive or not if they are fit for Emacs.

> Having used GNU/Linux for 7 years and windows for 9 months, I am getting
> my first macbook. I think paying a price for a good service, a peace of
> mind and most importantly, saving hours and hours of time is far more
> important in life than having the feeling of 'I'm using 100% free/open
> source software', and the mac world is full of innovations. In this
> regard, it seems the free software movement is out of touch.

I used various proprietary Unix implementations (primarily Sun) for most
of my 24 years in the profession before being forced to Windows 3 or 4
years ago.  I only got a computer for home use a couple years ago, and
it is an Apple (Mac OS X).  But I am very aware of the enormous open
software and free software contributions to the technical success of
both commercial Unix and Mac OS X.  They are both far more useable in
the true sense than any Microsoft OS _because_ of open software and free
software.  And I've never felt like I've wasted time using or
contributing to the open and/or free software in those systems.

> I learnt from #emacs on freenode the saying "Free software is free if
> your time is useless", which wakes me up to the guilt of wasting time.

That saying is false on a couple levels:

1. The freedom granted by free software is what allows you to use your
    time as _you_ wish.

2. Using non-free software makes you guilty of wasting the time of the
    persons who designed, implemented, documented, and distributed it:
    because inevitably there will be bugs to fix or opportunities to
    enhance it that will go undone because *you and everybody else*
    _can't_.

2. It reminds me of a _former_ CTO at my company who made this point
    when he introduced himself to the IT staff: We are not system
    integrators. He is long gone, because he didn't understand that
    _all_ software development is system integration.  And that depends
    on open and free software, which the present CIO of my company (who
    hired that CTO) still doesn't understand.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Xah Lee]

I just want to note here that wild non-fact and philosophical elements
are starting to flying in.

Richard Stallman, his use of “free” in his concept of Free Software
and Free Software Foundation, is a abuse of English. I do not know he
did this with the intent to ride the ambiguity for the marketing
benefit of the catcher word “free”, or innocently due to the fuzziness
of English. In any case, from the numerous talks and lectures he gave,
it is apparent he is abusing the concept of freedom to gain
supporters.

Please do not use the word “free” like he want you to. When referring
to his philosophical stance of software and his foundation, please say
perhaps put a quote such as: “Free Software” and “Free Software
Foundation”, or FSF Software.

Don't say “non-free” to refer to commercial software that are disliked
by FSF. Simply just say software, or commercial software if so, or non-
FSF ideal software.

For those of you FSF or Open Source fanatics who are ignorant of basic
literacy of pertinent social sciences, i recommend:

• Basic Economics 3rd Ed: A Common Sense Guide to the Economy
by Thomas Sowell
http://www.amazon.com/Basic-Economics-3rd-Ed-Economy/dp/0465002609

I read the first edition in the dot come age circa 2000, alone with
other books that helped me understand stocks and related financial
things. I've read Thomas's book 2 more times in the early 2000s.

• A Conflict of Visions: Ideological Origins of Political Struggles
by Thomas Sowell
http://www.amazon.com/Conflict-Visions-Ideological-Political-Struggles/dp/0465002056

The above can teach you something about FSF ideals.

Personally, i'm a mild FSF supporter. Not out of any moral senses, but
simply the fact that software can be duplicated without cost,
therefore traditional copy right law may not work well and FSF's model
might be better. For detail, see:

• “Free” Software Morality, Richard Stallman, and Paperwork
Bureaucracy
  http://xahlee.org/UnixResource_dir/writ2/FSF_philosophy.html

• Responsible Software Licensing
  http://xahlee.org/UnixResource_dir/writ/responsible_license.html

  Xah
∑ http://xahlee.org/

☄

On Mar 26, 6:42 pm, Kevin Rodgers <kevin.d.rodg...@gmail.com> wrote:
> Leo wrote:
> > Emacs is resistant to innovations. This is going to kill it at some
> > point. But maybe it is good as it shows emacs is subject to 'survival of
> > the fittest' after all.
>
> Or the converse: Emacs is the environment, and alleged innovations
> survive or not if they are fit for Emacs.
>
> > Having used GNU/Linux for 7 years and windows for 9 months, I am getting
> > my first macbook. I think paying a price for a good service, a peace of
> > mind and most importantly, saving hours and hours of time is far more
> > important in life than having the feeling of 'I'm using 100% free/open
> > source software', and the mac world is full of innovations. In this
> > regard, it seems the free software movement is out of touch.
>
> I used various proprietary Unix implementations (primarily Sun) for most
> of my 24 years in the profession before being forced to Windows 3 or 4
> years ago.  I only got a computer for home use a couple years ago, and
> it is an Apple (Mac OS X).  But I am very aware of the enormous open
> software and free software contributions to the technical success of
> both commercial Unix and Mac OS X.  They are both far more useable in
> the true sense than any Microsoft OS _because_ of open software and free
> software.  And I've never felt like I've wasted time using or
> contributing to the open and/or free software in those systems.
>
> > I learnt from #emacs on freenode the saying "Free software is free if
> > your time is useless", which wakes me up to the guilt of wasting time.
>
> That saying is false on a couple levels:
>
> 1. The freedom granted by free software is what allows you to use your
>     time as _you_ wish.
>
> 2. Using non-free software makes you guilty of wasting the time of the
>     persons who designed, implemented, documented, and distributed it:
>     because inevitably there will be bugs to fix or opportunities to
>     enhance it that will go undone because *you and everybody else*
>     _can't_.
>
> 2. It reminds me of a _former_ CTO at my company who made this point
>     when he introduced himself to the IT staff: We are not system
>     integrators. He is long gone, because he didn't understand that
>     _all_ software development is system integration.  And that depends
>     on open and free software, which the present CIO of my company (who
>     hired that CTO) still doesn't understand.

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Kojak]

Le Thu, 26 Mar 2009 23:30:37 -0700 (PDT),
Xah Lee a écrit :

> Don't say “non-free” to refer to commercial software that are disliked
> by FSF. Simply just say software, or commercial software if so, or
> non- FSF ideal software.

No problem!  We will call them "racketwar" or "hustlewar".  Select as
it suit you.

You're really pathetic.  Poor guy!

P.S. His Eminence should select more groups to post his valuable
contributions.  Three groups, only?  What a pity!

-- 
Jacques.

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[David Kastrup]

Xah Lee <xahlee@gmail.com> writes:

> I just want to note here that wild non-fact and philosophical elements
> are starting to flying in.
>
> Richard Stallman, his use of “free” in his concept of Free Software
> and Free Software Foundation, is a abuse of English. I do not know he
> did this with the intent to ride the ambiguity for the marketing
> benefit of the catcher word “free”, or innocently due to the fuzziness
> of English. In any case, from the numerous talks and lectures he gave,
> it is apparent he is abusing the concept of freedom to gain
> supporters.

Supporters for his cause of making available free software.  Which is
pretty much what he claims.  He did it his way, starting at a time where
software distribution meant magnetic tapes.  And, give and take
drawbacks, his way worked and made an impact.

On a scale few other people can boast.  And inspiring further people
wildly opposed to him to work on different brands of free software.

His success is not restricted to those who support him.  I don't see him
being side-tracked either, so I don't see why he would be "abusing the
concept of freedom".

-- 
David Kastrup

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Eli Zaretskii]

> From: Xah Lee <xahlee@gmail.com>
> Date: Thu, 26 Mar 2009 23:30:37 -0700 (PDT)
> 
> I just want to note here that wild non-fact and philosophical elements
> are starting to flying in.
> 
> Richard Stallman, his use of “free” in his concept of Free Software
> and Free Software Foundation, is a abuse of English. I do not know he
> did this with the intent to ride the ambiguity for the marketing
> benefit of the catcher word “free”, or innocently due to the fuzziness
> of English. In any case, from the numerous talks and lectures he gave,
> it is apparent he is abusing the concept of freedom to gain
> supporters.
> 
> Please do not use the word “free” like he want you to. When referring
> to his philosophical stance of software and his foundation, please say
> perhaps put a quote such as: “Free Software” and “Free Software
> Foundation”, or FSF Software.
> 
> Don't say “non-free” to refer to commercial software that are disliked
> by FSF. Simply just say software, or commercial software if so, or non-
> FSF ideal software.

Don't listen to this ignorant hogwash.  FSF does not dislike
commercial software (in fact, FSF sells GNU software and books about
GNU software itself).  FSF dislikes _proprietary_ software, which is
entirely different.

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[B. T. Raven]

Xah Lee wrote:
> dear Eli Zaretskii idiot,

It will be infra dig for Eli to respond, so ....

> 
> On Mar 29, 11:20 am, Eli Zaretskii <e...@gnu.org> wrote:
>>> From:XahLee<xah...@gmail.com>
>>> Date: Thu, 26 Mar 2009 23:30:37 -0700 (PDT)
>>> I just want to note here that wild non-fact and philosophical elements
>>> are starting to flying in.
>>> Richard Stallman, his use of “free” in his concept of Free Software
>>> and Free Software Foundation, is a abuse of English. I do not know he
>>> did this with the intent to ride the ambiguity for the marketing
>>> benefit of the catcher word “free”, or innocently due to the fuzziness
>>> of English. In any case, from the numerous talks and lectures he gave,
>>> it is apparent he is abusing the concept of freedom to gain
>>> supporters.

Are the authors of the American State papers fuzzy on the notion of 
freedom too?

You write: "the intent to ride the ambiguity for the marketing..." What 
marketing?

>>> Please do not use the word “free” like he want you to. When referring
>>> to his philosophical stance of software and his foundation, please say
>>> perhaps put a quote such as: “Free Software” and “Free Software
>>> Foundation”, or FSF Software.
>>> Don't say “non-free” to refer to commercial software that are disliked
>>> by FSF. Simply just say software, or commercial software if so, or non-
>>> FSF ideal software.

I don't think RMS would have problem with calling it "commercial" 
(that's accurate); he is just interested in calling attention to another 
dimension of the phenomenon.

>> Don't listen to this ignorant hogwash.  FSF does not dislike
>> commercial software (in fact, FSF sells GNU software and books about
>> GNU software itself).  FSF dislikes _proprietary_ software, which is
>> entirely different.

Thanks for reminding me Eli. I think I'll order a book now.

> 
> commercial software, in this context, refers to proprietary software.
> If you have read the article, you should know.
> 
> it is not wrong, to pointing out my sloppiness in terminology.
> However, you had to add sweeping remarks with insult.

Eli is condemning the sin and not the sinner. In other words it wasn't 
ad personam but ad rem.

> 
> perhaps you wonder why i called you a idiot. 

That's ad personam.

For the reason, please > see:
> 
> • (Knowledge + Love) / Disrespectfulness
>   http://xahlee.org/Netiquette_dir/disrespectfulness.html
> 
> excerpt follows:
> --------------------------------------------------
> (Knowledge + Love) / Disrespectfulness
> 
> Xah Lee, 2008-07
> 
> The respect in my response to people's writings is based on this
> ratio: (knowledge+love)/disrespectfulness exhibited in their posts.
> For example, if disrespectfulness is constant, then the greater their
> knowledge and love, the greater will be my respect for them. Suppose
> the knowledge+love is constant, then the greater their outward
> disrespect, will gain greater of my disrepsect. If their knowledge
> +love is greater than their outward disrespect, then overall they
> still gain my respect. However, if their knowledge+love is less than
> their show of disrespectfulness, then i dispise them.

This is a silly mathematization of matters far too involved to be 
modeled in this way.

> 
> We all have different levels of IQs, environment we grew up, areas of
> expertise, weaknesses. No human animal, knows all (in fact in modern
> word hardly any human animal knew 1/10^googolplex percent of
> knowledge). 

This is an exaggeration since certainly all men (corporately) know ALL 
of [human] knowledge and there are far fewer than 10^(10 ^ 100) humans. 
Why didn't you use a power series of googleplex googleplex levels high? 
Or Graham's number?


This is when discussion, comes in. When you know
> something, and you sincerely believe you know it, don't be shy. When
> you don't know something, don't be a ass. The problem with most
> sophomorons, is not knowing the extent of their ignorance. Coupled
> with the male nature, they become aggressive in pissing fights.
> 
> When i encounter tech geekers, usually they don't know shit of the
> subject relative to me, yet they are outright insulting to point of
> views outside their community (may it be unix ways; perl, lisp...). If
> you don't take the extra mile to kiss their ass when presenting
> unorthodox views, they either call you stupid outright, or become
> aggressive and hateful, to the point to kick/ban you or whatnot (e.g.
> eliminating any possible discussion or explanation i could contribute
> or defend of their accusations). That is when, you begin to see
> fuckheads and motherfucks sprinkled in my writings.

This is a good example why you shouldn't respond in anger (or when 
tonguing your meds).
> 
> ...
> 
> 2008-08-24 Addendum

[addendum snipped. Vide supra]


By the way, I agree that Sowell's book is top-notch but his views should 
be tempered by reading something by Naomi Klein. Remember Economics is 
not all. There is also Political Economy.

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Lennart Borgman]

On Mon, Mar 30, 2009 at 10:03 PM, B. T. Raven <nihil@nihilo.net> wrote:
> By the way, I agree that Sowell's book is top-notch but his views should be
> tempered by reading something by Naomi Klein. Remember Economics is not all.
> There is also Political Economy.

Thanks for mentioning Sowell, I have never noticed him before. I
recently saw Greg Bern's article on brain functioning when we admire
someone and believe they are experts. It looks like we just shut of
our brains then (which surely have implications for discussions
everywhere).

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Xah Lee]

Dear B T Raven,

non-free, is misleading term for proprietary software. People started
to refer to proprietary as non-free, because Richard Stallman abuses
the words “free” and “freedom”, and as a consequence, people started
to call other software that are not compatible with his ideal, as “non-
free”.

Despite the fact that the word “free” does not refer to price, but
proprietary software isn't necessarily restraining freedom. In fact,
the issue of whether source code is proprietary or non-public has
little to do with the concept of liberty. Richard Stallman's vision of
software is “free”, in the sense that coder community can freely look
at the source code and make use of it. That sense of “free” is a point
of view. As a contrast, proprietary software is also free, in the
sense that entrepreneurs and businesses can freely develop and sell
their software without worrying about some coder making copies with
minor or no changes put it out free of charge that robs their work.

  Xah
∑ http://xahlee.org/

☄

On Mar 30, 1:03 pm, "B. T. Raven" <ni...@nihilo.net> wrote:
> XahLeewrote:
> > dear Eli Zaretskii idiot,
>
> It will be infra dig for Eli to respond, so ....
>
>
>
> > On Mar 29, 11:20 am, Eli Zaretskii <e...@gnu.org> wrote:
> >>> From:XahLee<xah...@gmail.com>
> >>> Date: Thu, 26 Mar 2009 23:30:37 -0700 (PDT)
> >>> I just want to note here that wild non-fact and philosophical elements
> >>> are starting to flying in.
> >>> Richard Stallman, his use of “free” in his concept of Free Software
> >>> and Free Software Foundation, is a abuse of English. I do not know he
> >>> did this with the intent to ride the ambiguity for the marketing
> >>> benefit of the catcher word “free”, or innocently due to the fuzziness
> >>> of English. In any case, from the numerous talks and lectures he gave,
> >>> it is apparent he is abusing the concept of freedom to gain
> >>> supporters.
>
> Are the authors of the American State papers fuzzy on the notion of
> freedom too?
>
> You write: "the intent to ride the ambiguity for the marketing..." What
> marketing?
>
> >>> Please do not use the word “free” like he want you to. When referring
> >>> to his philosophical stance of software and his foundation, please say
> >>> perhaps put a quote such as: “Free Software” and “Free Software
> >>> Foundation”, or FSF Software.
> >>> Don't say “non-free” to refer to commercial software that are disliked
> >>> by FSF. Simply just say software, or commercial software if so, or non-
> >>> FSF ideal software.
>
> I don't think RMS would have problem with calling it "commercial"
> (that's accurate); he is just interested in calling attention to another
> dimension of the phenomenon.
>
> >> Don't listen to this ignorant hogwash.  FSF does not dislike
> >> commercial software (in fact, FSF sells GNU software and books about
> >> GNU software itself).  FSF dislikes _proprietary_ software, which is
> >> entirely different.
>
> Thanks for reminding me Eli. I think I'll order a book now.
>
>
>
> > commercial software, in this context, refers to proprietary software.
> > If you have read the article, you should know.
>
> > it is not wrong, to pointing out my sloppiness in terminology.
> > However, you had to add sweeping remarks with insult.
>
> Eli is condemning the sin and not the sinner. In other words it wasn't
> ad personam but ad rem.
>
>
>
> > perhaps you wonder why i called you a idiot.
>
> That's ad personam.
>
> For the reason, please > see:
>
>
>
>
>
> > • (Knowledge + Love) / Disrespectfulness
> >  http://xahlee.org/Netiquette_dir/disrespectfulness.html
>
> > excerpt follows:
> > --------------------------------------------------
> > (Knowledge + Love) / Disrespectfulness
>
> >XahLee, 2008-07
>
> > The respect in my response to people's writings is based on this
> > ratio: (knowledge+love)/disrespectfulness exhibited in their posts.
> > For example, if disrespectfulness is constant, then the greater their
> > knowledge and love, the greater will be my respect for them. Suppose
> > the knowledge+love is constant, then the greater their outward
> > disrespect, will gain greater of my disrepsect. If their knowledge
> > +love is greater than their outward disrespect, then overall they
> > still gain my respect. However, if their knowledge+love is less than
> > their show of disrespectfulness, then i dispise them.
>
> This is a silly mathematization of matters far too involved to be
> modeled in this way.
>
>
>
> > We all have different levels of IQs, environment we grew up, areas of
> > expertise, weaknesses. No human animal, knows all (in fact in modern
> > word hardly any human animal knew 1/10^googolplex percent of
> > knowledge).
>
> This is an exaggeration since certainly all men (corporately) know ALL
> of [human] knowledge and there are far fewer than 10^(10 ^ 100) humans.
> Why didn't you use a power series of googleplex googleplex levels high?
> Or Graham's number?
>
> This is when discussion, comes in. When you know
>
> > something, and you sincerely believe you know it, don't be shy. When
> > you don't know something, don't be a ass. The problem with most
> > sophomorons, is not knowing the extent of their ignorance. Coupled
> > with the male nature, they become aggressive in pissing fights.
>
> > When i encounter tech geekers, usually they don't know shit of the
> > subject relative to me, yet they are outright insulting to point of
> > views outside their community (may it be unix ways; perl, lisp...). If
> > you don't take the extra mile to kiss their ass when presenting
> > unorthodox views, they either call you stupid outright, or become
> > aggressive and hateful, to the point to kick/ban you or whatnot (e.g.
> > eliminating any possible discussion or explanation i could contribute
> > or defend of their accusations). That is when, you begin to see
> > fuckheads and motherfucks sprinkled in my writings.
>
> This is a good example why you shouldn't respond in anger (or when
> tonguing your meds).
>
>
>
> > ...
>
> > 2008-08-24 Addendum
>
> [addendum snipped. Vide supra]
>
> By the way, I agree that Sowell's book is top-notch but his views should
> be tempered by reading something by Naomi Klein. Remember Economics is
> not all. There is also Political Economy.

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[B. T. Raven]

Xah Lee wrote:
> Dear B T Raven,
> 
> non-free, is misleading term for proprietary software. People started
> to refer to proprietary as non-free, because Richard Stallman abuses
> the words “free” and “freedom”, and as a consequence, people started
> to call other software that are not compatible with his ideal, as “non-
> free”.
> 
> Despite the fact that the word “free” does not refer to price, but
> proprietary software isn't necessarily restraining freedom. In fact,
> the issue of whether source code is proprietary or non-public has
> little to do with the concept of liberty. Richard Stallman's vision of
> software is “free”, in the sense that coder community can freely look
> at the source code and make use of it. That sense of “free” is a point
> of view. As a contrast, proprietary software is also free, in the
> sense that entrepreneurs and businesses can freely develop and sell
> their software without worrying about some coder making copies with
> minor or no changes put it out free of charge that robs their work.
> 
>   Xah
> ∑ http://xahlee.org/
> 

[...]

I think we'll have to agree to disagree. It's clear though that GPL'd 
software is freer since you may copy it and sell it for whatever you can 
get for it as long as you package it with the source code. Proprietary 
vendors won't allow that. And both of you have to worry about what the 
competition will do. Notice that the *About GNU Emacs* buffer mentions 
"Copyright* not Copyleft. This ensures that free software, like 
proprietary, is protected by the same law of the land.

Ed

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Nikolaj Schumacher]

Xah Lee <xahlee@gmail.com> wrote:

> non-free, is misleading term for proprietary software.

> software is “free”, in the sense that coder community can freely look
> at the source code and make use of it. That sense of “free” is a point
> of view.

Speech is almost always subjective.  That doesn't make it inappropriate.
This isn't an encyclopedia.  We don't have to remain neutral and put
everything in quotation marks when we touch political topics.

And, as tempting as that might be, we don't have to call each other out
on our opinions at every opportunity.

regards,
Nikolaj Schumacher

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Alan Mackenzie]

Hi, Xah,

On Mon, Mar 30, 2009 at 09:12:54PM -0700, Xah Lee wrote:
> Dear B T Raven,

> non-free, is misleading term for proprietary software. People started
> to refer to proprietary as non-free, because Richard Stallman abuses
> the words ???free??? and ???freedom???, and as a consequence, people
> started to call other software that are not compatible with his ideal,
> as ???non- free???.

It's hardly an abuse, it's the essential meaning of "free".  What RMS has
been doing for ~30 years is drawing attention to an important facet of
software, and in doing so shaking up people's ideas; the use of the term
"non-free" was an important part of this.

> Despite the fact that the word ???free??? does not refer to price, but
> proprietary software isn't necessarily restraining freedom. In fact,
> the issue of whether source code is proprietary or non-public has
> little to do with the concept of liberty.

On the contrary, it is overwhelmingly important to the concept of
liberty, and becoming steadily more so.  Consider software's use in
voting machines, or the ease with which certain operating systmes can be
compromised via the internet; consider how the encryption of electronic
books can deprive blind users of the freedom to read them.

> Richard Stallman's vision of software is ???free???, in the sense that
> coder community can freely look at the source code and make use of it.
> That sense of ???free??? is a point of view. As a contrast, proprietary
> software is also free, in the sense that entrepreneurs and businesses
> can freely develop and sell their software without worrying about some
> coder making copies with minor or no changes put it out free of charge
> that robs their work.

Indeed.  Every politician there's ever been has been in favour of
freedom, and round the world you'll find political parties of all hues
calling themselves "liberal".  The real question is "freedom for whom?".
It is scarcely possible to exercise any freedom without imposing on
somebody else, no matter how slightly.

The people who post on this list believe that freedom for software's
users trumps that of its writers.

>   Xah

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: elisp's cl package. Don't understand the notice about eval-when-compile

[Kevin Rodgers]

Xah Lee wrote:
> in emacs lisp's CL package documentation “(info "(cl)Overview")”, it
> has this passage:
> 
>    *Please note:* the "CL" functions are not standard parts of the
> Emacs Lisp name space, so it is legitimate for users to define them
> with other, conflicting meanings.  To avoid conflicting with those
> user
> activities, we have a policy that packages installed in Emacs must not
> load "CL" at run time.  (It is ok for them to load "CL" at compile
> time
> only, with `eval-when-compile', and use the macros it provides.)  If
> you are writing packages that you plan to distribute and invite
> widespread use for, you might want to observe the same rule.
> 
> I don't quite understand it.
> 
> If i distribute a package xyz.el, which calls
> 
> (eval-when-compile (require 'cl))
> 
> And, this package does not require users to byte-compile it. Then,
> how's the eval-when-compile solve the name conflict problem?
> 
> does it imply that if you distribute a package using cl, it must be
> byte compiled eventually?

Of course, no library _must_ be compiled.  But the unstated assumption
is that every library is byte-compiled because of the performance
benefits (during loading _and_ execution).

And if you load and execute a compiled library that uses CL macros (but
not CL functions) via eval-when-compile, then the obarray remains pure.
:-)

-- 
Kevin Rodgers
Denver, Colorado, USA