is requiring cl bad?

is requiring cl bad?

[Ivan Kanis]

Hello,

I was under the impression that requiring cl was bad (TM). I can't
remember why. Is it still so?
-- 
Ivan Kanis
http://ivan.kanis.fr

Friendship is like a sheltering tree.
    -- Samuel Taylor Coleridge

Re: is requiring cl bad?

[Xue Fuqiao]

On Sun, 16 Dec 2012 10:29:30 +0100
Ivan Kanis <ivan.kanis@googlemail.com> wrote:

> I was under the impression that requiring cl was bad (TM). I can't
> remember why. Is it still so?

You can see these pages:
http://lists.gnu.org/archive/html/emacs-devel/2003-08/msg00436.html
http://www.gnu.org/gnu/rms-lisp.html
http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01472.html

BTW, what does "TM" mean(English is not my native language)?
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: is requiring cl bad?

[Pascal J. Bourguignon]

Xue Fuqiao <xfq.free@gmail.com> writes:

> On Sun, 16 Dec 2012 10:29:30 +0100
> Ivan Kanis <ivan.kanis@googlemail.com> wrote:
>
>> I was under the impression that requiring cl was bad (TM). I can't
>> remember why. Is it still so?
>
> You can see these pages:
> http://lists.gnu.org/archive/html/emacs-devel/2003-08/msg00436.html
> http://www.gnu.org/gnu/rms-lisp.html
> http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01472.html
>
> BTW, what does "TM" mean(English is not my native language)?

It should be written as: ™  meaning Trade Mark, meaning "cl is bad" is a
registered trade mark.  No it's not, but it's as famous as if it was.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: is requiring cl bad?

[Xue Fuqiao]

On Sun, 16 Dec 2012 11:26:10 +0100
"Pascal J. Bourguignon" <pjb@informatimago.com> wrote:

> It should be written as: ™  meaning Trade Mark, meaning "cl is bad" is a
> registered trade mark.  No it's not, but it's as famous as if it was.

Thanks for your explanation.

-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: is requiring cl bad?

[Ivan Kanis]

Hi Xue,

I guess my point is if I decide to use CL functions I should not be
polluted with warnings when I compile.

To get rid of all warnings I had to put this on top:

(require 'cl)

and tack at the end:

;; Local Variables:
;; byte-compile-warnings: (not cl-functions)
;; End:

It shouldn't be so obscure. At least it ought to be documented
somewhere...

Xue Fuqiao <xfq.free@gmail.com> wrote:

> On Sun, 16 Dec 2012 10:29:30 +0100
> Ivan Kanis <ivan.kanis@googlemail.com> wrote:
>
>> I was under the impression that requiring cl was bad (TM). I can't
>> remember why. Is it still so?
>
> You can see these pages:
> http://lists.gnu.org/archive/html/emacs-devel/2003-08/msg00436.html
> http://www.gnu.org/gnu/rms-lisp.html
> http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg01472.html

Thanks for the links it made interesting reading. 

I understand RMS doesn't like Common Lisp because it uses weird
keywords. That is fine by me.



> BTW, what does "TM" mean(English is not my native language)?

Trade Mark, it's just a joke.
-- 
Ivan Kanis
http://ivan.kanis.fr

A cruel crafty crocodile,
Which in false grief hiding his harmful guile,
Doth weep full sore, and sheddeth tender tears.
    -- Edmund Spenser

Re: is requiring cl bad?

[Stefan Monnier]

> I was under the impression that requiring cl was bad (TM).  I can't
> remember why.  Is it still so?

The CL package is unclean w.r.t to its use of the namespace.  Using its
macros is tolerated because it only imposes this namespace mess during
byte-compilation of your package, but using its functions imposes the
mess during actual use of your package.

24.3 finally provides an alternative: `cl-lib' which offers the
same functionality but in a namespace-clean way (i.e. using a "cl-"
prefix everywhere).


        Stefan

Re: is requiring cl bad?

[Pascal J. Bourguignon]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I was under the impression that requiring cl was bad (TM).  I can't
>> remember why.  Is it still so?
>
> The CL package is unclean w.r.t to its use of the namespace.  Using its
> macros is tolerated because it only imposes this namespace mess during
> byte-compilation of your package, but using its functions imposes the
> mess during actual use of your package.
>
> 24.3 finally provides an alternative: `cl-lib' which offers the
> same functionality but in a namespace-clean way (i.e. using a "cl-"
> prefix everywhere).

This is a silly solution. 
The right solution is to implement a package system.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: is requiring cl bad?

[Ivan Kanis]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> I was under the impression that requiring cl was bad (TM).  I can't
>> remember why.  Is it still so?
>
> The CL package is unclean w.r.t to its use of the namespace.  Using its
> macros is tolerated because it only imposes this namespace mess during
> byte-compilation of your package, but using its functions imposes the
> mess during actual use of your package.
>
> 24.3 finally provides an alternative: `cl-lib' which offers the
> same functionality but in a namespace-clean way (i.e. using a "cl-"
> prefix everywhere).

In case someone is reading this thread, here's what I did in the end:

(require 'cl-lib)

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

Rename all common lisp functions, for example coerce -> cl-coerce. I had
to keep 'cl for macro expansion such as incf.

I removed the following at the end of the file :

;; Local Variables:
;; byte-compile-warnings: (not cl-functions)
;; End:

Now it compiles without warning.
-- 
Ivan Kanis
http://ivan.kanis.fr

The essence of science: ask an impertinent question, and you are on
the way to a pertinent answer.
    -- Jacob Bronowski

I am listening to "Coldplay - In My Place".

Re: is requiring cl bad?

[Tony Day]

On 18 Dec 2012, at 06:09, Pascal J. Bourguignon <pjb@informatimago.com> wrote:

>> 
>> 24.3 finally provides an alternative: `cl-lib' which offers the
>> same functionality but in a namespace-clean way (i.e. using a "cl-"
>> prefix everywhere).
> 
> This is a silly solution. 
> The right solution is to implement a package system.

FWIW, I had a lot of trouble with cl when I started learning elisp.  Did I have to learn the entire cl way of doing things to be proficient in emacs coding?  Why was it 'special' in comparison to any other library/package but not so special as to be fully part of elisp?  In retrospect, treating cl functionality as non-core helped accelerate my learning phase and better understand how to write useful emacs code.

cl-lib is an awesome library that I hope to understand and use properly (one day).  That it was partially tolerated in the past is one of those difficult to reverse mistakes and I think the solution is quite respectful and graceful considering.

Tony      

Re: is requiring cl bad?

[Stefan Monnier]

> Rename all common lisp functions, for example coerce -> cl-coerce. I had
> to keep 'cl for macro expansion such as incf.

If you're requiring cl-lib for cl-coerce, then you may as well use
cl-incf and drop `cl' altogether.


        Stefan

Re: is requiring cl bad?

[David De La Harpe Golden]

On 17/12/12 19:09, Pascal J. Bourguignon wrote:
>> 24.3 finally provides an alternative: `cl-lib' which offers the
>> same functionality but in a namespace-clean way (i.e. using a "cl-"
>> prefix everywhere).
>
> This is a silly solution.
> The right solution is to implement a package system.
>

The consistent-prefix approach may be a C-like solution, but is still 
noticeably better than the previous conflicty mess, and widely
used for other emacs lisp libs.

But regarding the idea of "a package system" in particular, as you may 
mean a system similar to common lisp "packages":

If emacs ever did go toward adding new facilities in the general area of 
modularity (however unlikely it is in reality in the near future), I 
reckon Ron Garret's common lisp land "lexicons" work [1] might be a 
better "lispy modularity thingy" for emacs lisp to be inspired by than 
common lisp packages in particular.  At least, I'd take a hard look at 
lexicons (and at least glance at what some other languages do), before 
just blindly adding common lisp style packages.

Emacs lisp is lexically scoped now after all.

To people coming from quite a few other languages with more 
[nowadays-]conventional module systems, lexicons might well seem less 
weird than packages.

In emacs lisp land there is obviously no prior usage of common lisp 
style packages in the first place (yes I am vaguely aware you can feck 
about with non-default obarrays in emacs lisp for some purposes, but 
meh), unlike the situation in common lisp land where inertia and  compat 
concerns will probably keep most people on packages anyway despite the 
existence of lexicons there now.

[1] http://www.flownet.com/ron/lisp/lexicons.pdf
"""
Lexicons are first-class global lexical environments, what are sometimes 
called "modules" or "namespaces" in other languages.
[...]
instead of mapping strings to symbols, lexicons map symbols to (global) 
bindings.
"""

Re: is requiring cl bad?

[Ivan Kanis]

David De La Harpe Golden <david@harpegolden.net> wrote:

> On 17/12/12 19:09, Pascal J. Bourguignon wrote:
>>> 24.3 finally provides an alternative: `cl-lib' which offers the
>>> same functionality but in a namespace-clean way (i.e. using a "cl-"
>>> prefix everywhere).
>>
>> This is a silly solution.
>> The right solution is to implement a package system.
>>
> If emacs ever did go toward adding new facilities in the general area
> of modularity (however unlikely it is in reality in the near future),

Sounds like a good candidate for emacs 25. Someone complained we didn't
have a roadmap... ;)

> I reckon Ron Garret's common lisp land "lexicons" work [1]

Thanks for the link, I will read it later.
-- 
Ivan Kanis
http://ivan.kanis.fr

Temporary routing anomaly.
    -- BOFH excuse number 35

Re: is requiring cl bad?

[Helmut Eller]

On Thu, Dec 20 2012, David De La Harpe Golden wrote:

> If emacs ever did go toward adding new facilities in the general area
> of modularity (however unlikely it is in reality in the near future),
> I reckon Ron Garret's common lisp land "lexicons" work [1] might be a
> better "lispy modularity thingy" for emacs lisp to be inspired by than
> common lisp packages in particular.  At least, I'd take a hard look at
> lexicons (and at least glance at what some other languages do), before
> just blindly adding common lisp style packages.

Have you actually taken a "hard look" at Ron Garret's lexicons?  What
was your experience?  I played with them a few years back, but I quickly
concluded that lexicons are only a crude prototype and that it was never
used in the "field"; not something I would use.  Ron Garret's code only
worked with Clozure CL and since then CCL's internals have changed a bit
so that lexicons no longer work.

Common Lisp's packages are not prefect, but they get the job done.  The
problems (and workarounds) are by now well known.

> Emacs lisp is lexically scoped now after all.

If you want Scheme-like modules based on lexical scoping you will also
need hygienic macros.  (Something that Common Lisp nicely avoids.)

Helmut

Re: is requiring cl bad?

[David De La Harpe Golden]

On 20/12/12 09:16, Helmut Eller wrote:

> Have you actually taken a "hard look" at Ron Garret's lexicons?
> What  was your experience?  I played with them a few years back, but I quickly
> concluded that lexicons are only a crude prototype

Well, the last version I looked much at was ~2.0 when he started to 
reuse packages extensively as part of the underlying implementation 
(something I disliked actually [1], but he saw lexicons as a complete 
replacement for packages, I remember in the CL case I would have 
preferred if they had been independent facilities (but my concerns about 
packages vs. lexicons in the CL cases /would not apply/ here in emacs 
land, because there are no packages))

> and that it was never used in the "field"; not something I
> would use.

Not exactly mature, no - but hey, was new, shrug.  Anyway, there's 
presumably no way at his /implementation/ could be reused for emacs 
unless emacs was first made into a common lisp.

However, I mentioned lexicons as something to look at for inspiration 
for a hypothetical emacs system: the quality of Ron's actual 
implementation for [C]CL is not of particular concern for that purpose, 
in fact you could avoid looking at it completely (though it appears to 
be liberally licensed) and just read the paper for that purpose.

>> Emacs lisp is lexically scoped now after all.
>
> If you want Scheme-like modules based on lexical scoping you will also
> need hygienic macros.  (Something that Common Lisp nicely avoids.)
>

Ron actually presented lexicons plus an escaping hack as an 
/alternative/ to scheme-style hygienic macros in his paper, mind, you 
may or may not be convinced that's better than a hygienic macro DSL, not 
sure I was.

I figure implementation innards would need amendment regardless in the 
emacs case, practically if not in theory (I didn't mean to suggest 
lexicons be built on top of existing facilities at a purely lisp level 
or something in the emacs case, whereas despite CCL-isms, Ron used 
mostly portable CL)

[1] 
http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2008-12/msg00359.html

Re: is requiring cl bad?

[Helmut Eller]

On Fri, Dec 21 2012, David De La Harpe Golden wrote:

> On 20/12/12 09:16, Helmut Eller wrote:
>
>> Have you actually taken a "hard look" at Ron Garret's lexicons?
>> What  was your experience?  I played with them a few years back, but I quickly
>> concluded that lexicons are only a crude prototype
>
> Well, the last version I looked much at was ~2.0 when he started to
> reuse packages extensively as part of the underlying implementation
> (something I disliked actually [1], but he saw lexicons as a complete
> replacement for packages, I remember in the CL case I would have
> preferred if they had been independent facilities (but my concerns
> about packages vs. lexicons in the CL cases /would not apply/ here in
> emacs land, because there are no packages))

Emacs symbols may not have packages but (funcall '<some-symbol>) is used
a lot in Emacs Lisp.  AFAICS, modules based on lexical scoping don't
handle this case, because funcall doesn't resolve the symbol to a module
binding.  Which module should be used at runtime?

>> and that it was never used in the "field"; not something I
>> would use.
>
> Not exactly mature, no - but hey, was new, shrug.  Anyway, there's
> presumably no way at his /implementation/ could be reused for emacs
> unless emacs was first made into a common lisp.
>
> However, I mentioned lexicons as something to look at for inspiration
> for a hypothetical emacs system: the quality of Ron's actual
> implementation for [C]CL is not of particular concern for that
> purpose, in fact you could avoid looking at it completely (though it
> appears to be liberally licensed) and just read the paper for that
> purpose.

Some ideas look nice on paper but when used in practice all sorts of
problems appear that aren't covered in the paper.  IMO lexicons fall
into that category.

>>> Emacs lisp is lexically scoped now after all.
>>
>> If you want Scheme-like modules based on lexical scoping you will also
>> need hygienic macros.  (Something that Common Lisp nicely avoids.)
>>
>
> Ron actually presented lexicons plus an escaping hack as an
> /alternative/ to scheme-style hygienic macros in his paper, mind, you
> may or may not be convinced that's better than a hygienic macro DSL,
> not sure I was.

Either way you need to resolve a symbol to the module binding.  So the
result of a macro must either contain the resolved binding (if you do
the resolution early) or the symbol plus the module (in some way) to
that the compiler can do the resolution.

> I figure implementation innards would need amendment regardless in the
> emacs case, practically if not in theory (I didn't mean to suggest
> lexicons be built on top of existing facilities at a purely lisp level
> or something in the emacs case, whereas despite CCL-isms, Ron used
> mostly portable CL)

I would not call this "mostly portable" because the compiler patch is
crucial and it was not even portable to the next version of the
compiler.

Helmut