functions from cl package called at runtime

functions from cl package called at runtime

[Achim Gratz]

The sources in ob.el have picked up several runtime invocations to
functions from the cl package via two commits from Eric:

fc92b2e2 lisp/ob.el (let ((tempvar (gensym "file")))
fc92b2e2 lisp/ob.el (let ((tempvar (gensym "file")))
fc92b2e2 lisp/ob.el (let ((tempvar (gensym "file")))
fc92b2e2 lisp/ob.el (let ((tempvar (gensym "file"))
fc92b2e2 lisp/ob.el   (rx (gensym "rx")))
abf3060e lisp/ob.el (flet ((intersection (as bs)
abf3060e lisp/ob.el                      (intersection (cdr as) bs)))))
abf3060e lisp/ob.el   (intersection (case context

These may need to be revised...


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: functions from cl package called at runtime

[Eric Schulte]

Thanks for catching this, I've just pushed up a fix.

Is there a convention for which macros from cl-macs are allowable and
which are forbidden?  For example `flet' is used extensively throughout
the Org-mode code base.  Is the convention that macros are allowable
while functions are not?

Also, while intersection below is a function defined in cl-seq, the use
of `intersection' in ob.el refers to a local function and not the cl-seq
function, so it should be fine.

Thanks,

Achim Gratz <Stromeko@nexgo.de> writes:

> The sources in ob.el have picked up several runtime invocations to
> functions from the cl package via two commits from Eric:
>
> fc92b2e2 lisp/ob.el (let ((tempvar (gensym "file")))
> fc92b2e2 lisp/ob.el (let ((tempvar (gensym "file")))
> fc92b2e2 lisp/ob.el (let ((tempvar (gensym "file")))
> fc92b2e2 lisp/ob.el (let ((tempvar (gensym "file"))
> fc92b2e2 lisp/ob.el   (rx (gensym "rx")))
> abf3060e lisp/ob.el (flet ((intersection (as bs)
> abf3060e lisp/ob.el                      (intersection (cdr as) bs)))))
> abf3060e lisp/ob.el   (intersection (case context
>
> These may need to be revised...
>
>
> Regards,
> Achim.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: functions from cl package called at runtime

[Achim Gratz]

Eric Schulte <eric.schulte@gmx.com> writes:
> Is there a convention for which macros from cl-macs are allowable and
> which are forbidden?

You might want to ask on the Emacs list, but my understanding is that no
Emacs core packages should depend on cl _at runtime_, but it is OK to
use the cl package during byte-compilation.

>  For example `flet' is used extensively throughout
> the Org-mode code base.  Is the convention that macros are allowable
> while functions are not?

A macro would typically be expanded at compile time, so that would be
OK.  AFAIK gensym is a function, not a macro.  The calls to gensym that
the byte-compiler complains about are expanded at runtime because they
are themselves inside a macro definition.

> Also, while intersection below is a function defined in cl-seq, the use
> of `intersection' in ob.el refers to a local function and not the cl-seq
> function, so it should be fine.

The byte-compiler thinks otherwise, so I'd check that assumption
again... but it might be a good idea to disambiguate the name with a
prefix anyway.  I've just tested the latter approach (renaming
intersection to ob-intersection) and it does work, so somehow the
byte-compiler doesn't quite get what is going on in the flet expansion
when the symbol is already present via the cl package.

I've just looked at the comments in cl-macs.el and it seems that flet
should be used with care anyway, since it is not quite doing what it is
supposed to do...


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: functions from cl package called at runtime

[Eric Schulte]

>
>> Also, while intersection below is a function defined in cl-seq, the use
>> of `intersection' in ob.el refers to a local function and not the cl-seq
>> function, so it should be fine.
>
> The byte-compiler thinks otherwise, so I'd check that assumption
> again... but it might be a good idea to disambiguate the name with a
> prefix anyway.  I've just tested the latter approach (renaming
> intersection to ob-intersection) and it does work, so somehow the
> byte-compiler doesn't quite get what is going on in the flet expansion
> when the symbol is already present via the cl package.
>
> I've just looked at the comments in cl-macs.el and it seems that flet
> should be used with care anyway, since it is not quite doing what it is
> supposed to do...
>

Thanks for looking into this, I've just disambiguated the name of
"intersection" as you suggest.  The word of warning with respect to flet
is well taken, in looking at gensym it seems it also doesn't quite
deliver on its promises.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/