Re: Some improvements for cl-flet

[akater]

I must leave one more notice.

What will the following forms return, with cl-flet being implemented as is?

(let ((n 0))
  (cl-symbol-macrolet ((f0 (progn (cl-incf n) #'identity)))
    (cl-flet ((f f0))
      (f t) (f t)
      n)))

(let ((n 0))
  (cl-symbol-macrolet ((f0 (progn (cl-incf n) #'identity)))
    (cl-flet ((f (identity f0)))
      (f t) (f t)
      n)))

Turns out, the value is not determined by cl-flet spec but rather by its 
implementation.  If it is optimized in a certain way (which is the case right 
now), the values will diverge.

While of course they shouldn't.

> Personally I wouldn't mind when this functionality would be provided by
> some other form, but there is backward compatibility.
>

> Don't you think that cl-lib (see Stefan's answer) differs from CL
> much more in other aspects?

No.  The note was about cl- prefix.  I can often write CL code easily
portable to Elisp and back again by merely writing cl: prefixes in it.
Of course, even without them, porting is trivial.  The ability to share
code is beneficial.  I think we should aim to eliminate the difference
between cl-lib and CL rather than extend it.

> I see your point.  OTOH, removing the expression syntax case would be a
> backward incompatible change potentially break existing code - right?

Introducing it potentially broke existing code in the first place.

signature.asc
Description: PGP signature