Re: [elpa] master 68bcf86 2/4: package/names: :group can be given a list

Re: [elpa] master 68bcf86 2/4: package/names: :group can be given a list

[Stefan Monnier]

>    '((:group
>       1 (lambda (x)
> -         (if (symbolp x)
> +         (if (or (symbolp x) (listp x))
>               (setq names--group-parent x)
>             (names--warn
>              "Argument given to :group is not a symbol: %s" x)))

Just like we don't like '(lambda ...), we don't like '(... (lambda ...)
...) either (tho it's still found at many places in Emacs's source code
since you can't "grep" for it quite as easily).  Better use
`(... ,(lambda ...) ...) instead, so the lambda is byte-compiled.  


        Stefan

Re: [elpa] master 68bcf86 2/4: package/names: :group can be given a list

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Just like we don't like '(lambda ...), we don't like '(... (lambda ...)
 > ...) either (tho it's still found at many places in Emacs's source code
 > since you can't "grep" for it quite as easily).  Better use
 > `(... ,(lambda ...) ...) instead, so the lambda is byte-compiled.  

Doesn't Emacs support #', and wouldn't that be more readable?

Re: [elpa] master 68bcf86 2/4: package/names: :group can be given a list

[Nicolas Richard]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Stefan Monnier writes:
>
>  > Just like we don't like '(lambda ...), we don't like '(... (lambda ...)
>  > ...) either (tho it's still found at many places in Emacs's source code
>  > since you can't "grep" for it quite as easily).  Better use
>  > `(... ,(lambda ...) ...) instead, so the lambda is byte-compiled.  
>
> Doesn't Emacs support #', and wouldn't that be more readable?

I don't think it will help :
`(... ,#'(lambda ...) ...) doesn't look more readable and
#'(... (lambda ...) ...) would be wrong

-- 
Nico

Re: [elpa] master 68bcf86 2/4: package/names: :group can be given a list

[Stephen J. Turnbull]

Nicolas Richard writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 > > Stefan Monnier writes:
 > >
 > >  > Just like we don't like '(lambda ...), we don't like '(... (lambda ...)
 > >  > ...) either (tho it's still found at many places in Emacs's source code
 > >  > since you can't "grep" for it quite as easily).  Better use
 > >  > `(... ,(lambda ...) ...) instead, so the lambda is byte-compiled.  
 > >
 > > Doesn't Emacs support #', and wouldn't that be more readable?
 > 
 > I don't think it will help :
 > `(... ,#'(lambda ...) ...) doesn't look more readable and
 > #'(... (lambda ...) ...) would be wrong

I'm suggesting

    '(... #'(lambda ...) ...)

to tell the byte-compiler that the lambda expression is a function,
and can be replaced by an equivalent function (ie, the byte-compiled
version).

Re: [elpa] master 68bcf86 2/4: package/names: :group can be given a list

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Nicolas Richard writes:
>  > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > 
>  > > Stefan Monnier writes:
>  > >
>  > >  > Just like we don't like '(lambda ...), we don't like '(... (lambda ...)
>  > >  > ...) either (tho it's still found at many places in Emacs's source code
>  > >  > since you can't "grep" for it quite as easily).  Better use
>  > >  > `(... ,(lambda ...) ...) instead, so the lambda is byte-compiled.  
>  > >
>  > > Doesn't Emacs support #', and wouldn't that be more readable?
>  > 
>  > I don't think it will help :
>  > `(... ,#'(lambda ...) ...) doesn't look more readable and
>  > #'(... (lambda ...) ...) would be wrong
>
> I'm suggesting
>
>     '(... #'(lambda ...) ...)
>
> to tell the byte-compiler that the lambda expression is a function,
> and can be replaced by an equivalent function (ie, the byte-compiled
> version).

That's equivalent to

'(... (function (lambda ...)) ...)

with (function (lambda ...)) being a quoted list rather than a function.
Nothing to do here for the bytecompiler.

-- 
David Kastrup

Re: [elpa] master 68bcf86 2/4: package/names: :group can be given a list

[Artur Malabarba]

I'll use the backquoted version. But I'm at a place of spotty internet
at the moment, so it may take me a few days.

-- 
Artur Malabarba

School of Physics,
University of Bristol, UK
(+44) 07450 374440

Re: [elpa] master 68bcf86 2/4: package/names: :group can be given a list

[David Kastrup]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> I'll use the backquoted version. But I'm at a place of spotty internet
> at the moment, so it may take me a few days.

Many versions of quoted lambda functions may these days be _so_ much
better written using lexical binding instead that I think XEmacs should
really try catching up here.  Otherwise the amount of code that cannot
be easily brought to run on XEmacs will likely become much larger.

I'm currently writing some package, and there are things like

(defun lily-pitch-insert-for (note)
  "Calculate a pitch insertion routine for Midi note NOTE.

This takes a look at `lily-midi-keysig' and determines the proper
enharmonic variant to insert."
  (lambda () (interactive)
    (lily-note-insert
     (apply #'lily-notename (lily-midi-to-note note)))))

or

(defun midikbd-filter-create ()
  "Create one Midi process filter keeping state across calls."
  (let ((state (make-vector 9 nil)))
    (lambda (_process string)
      (setq unread-command-events
	    (append unread-command-events
		    (mapcar (lambda (x) (aref midikbd-keys x))
			    (ccl-execute-on-string 'midikbd-decoder
						   state string t t)))))))

and other stuff.  That's quite nicer and more efficient than the awkward

(defun midikbd-filter-create ()
  "Create one Midi process filter keeping state across calls."
  (let ((state (make-vector 9 nil)))
    `(lambda (_process string)
      (setq unread-command-events
	    (append unread-command-events
		    (mapcar (lambda (x) (aref midikbd-keys x))
			    (ccl-execute-on-string 'midikbd-decoder
						   ,state string t t)))))))

or similar.

-- 
David Kastrup

Re: [elpa] master 68bcf86 2/4: package/names: :group can be given a list

[Stephen J. Turnbull]

David Kastrup writes:
 
 > Many versions of quoted lambda functions may these days be _so_
 > much better written using lexical binding instead that I think
 > XEmacs should really try catching up here.

We've been talking about that for a while, but it's not possible to
port Emacs's implementation directly, not to mention the usual set of
"technical differences" (Aidan doesn't like "-*- lexbind: t -*-" which
matters because he's the only competent person who's shown interest in
writing code for this, the others being Mike -- as a Schemer you'd
think he'd be on it like a cat on catnip, but no interest shown as yet
-- and Ben -- not in evidence on XEmacs channels for many moons).

I'll see if this gives Aidan a reason to be happier about file-level
declarations.

Re: [elpa] master 68bcf86 2/4: package/names: :group can be given a list

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>  
>  > Many versions of quoted lambda functions may these days be _so_
>  > much better written using lexical binding instead that I think
>  > XEmacs should really try catching up here.
>
> We've been talking about that for a while, but it's not possible to
> port Emacs's implementation directly, not to mention the usual set of
> "technical differences" (Aidan doesn't like "-*- lexbind: t -*-" which

Make no mistake: it's an awful crutch (I think that Stefan would likely
agree that it's only justification is that it is hard to come up with
something better) and should at some point of time be the default.

I don't think I've written code that would mind that switch: relying on
dynamical binding, particularly without properly declaring the involved
variables, is just so awkward.  Nevertheless, there likely _will_ be
non-negligible amounts of code around that do mind.

> matters because he's the only competent person who's shown interest in
> writing code for this, the others being Mike -- as a Schemer you'd
> think he'd be on it like a cat on catnip, but no interest shown as yet
> -- and Ben -- not in evidence on XEmacs channels for many moons).
>
> I'll see if this gives Aidan a reason to be happier about file-level
> declarations.

I don't think anybody is happy about them.  Come up with a better
migration mechanism, and I guess you'll have people's attention.

At least it is a noticeable clue of the "if this module does not work on
your version of Emacs, this will likely be the reason" kind.

-- 
David Kastrup

Re: [elpa] master 68bcf86 2/4: package/names: :group can be given a list

[Stefan Monnier]

> I'll use the backquoted version.  But I'm at a place of spotty internet
> at the moment, so it may take me a few days.

No, no, this is super extra urgent.  Think of all those wasted bits
screaming in the night, alone.


        Stefan

Re: [elpa] master 68bcf86 2/4: package/names: :group can be given a list

[Artur Malabarba]

2015-01-12 19:41 GMT-02:00 David Kastrup <dak@gnu.org>:
> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>
>> I'll use the backquoted version. But I'm at a place of spotty internet
>> at the moment, so it may take me a few days.
>
> Many versions of quoted lambda functions may these days be _so_ much
> better written using lexical binding instead that I think XEmacs should
> really try catching up here.  Otherwise the amount of code that cannot
> be easily brought to run on XEmacs will likely become much larger.

There might be some confusion here. What Stefan suggested (which I'm
going to apply) is precisely to UNquote the lambda. I'm going to do:
`(... ,(lambda (x) ...)) so the lambda is *not* quoted. It is
evaluated by the "," and thus seen by the byte-compiler.

Or maybe I'm just misunderstanding what you said. :-)

Re: [elpa] master 68bcf86 2/4: package/names: :group can be given a list

[David Kastrup]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> 2015-01-12 19:41 GMT-02:00 David Kastrup <dak@gnu.org>:
>> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>>
>>> I'll use the backquoted version. But I'm at a place of spotty internet
>>> at the moment, so it may take me a few days.
>>
>> Many versions of quoted lambda functions may these days be _so_ much
>> better written using lexical binding instead that I think XEmacs should
>> really try catching up here.  Otherwise the amount of code that cannot
>> be easily brought to run on XEmacs will likely become much larger.
>
> There might be some confusion here. What Stefan suggested (which I'm
> going to apply) is precisely to UNquote the lambda. I'm going to do:
> `(... ,(lambda (x) ...)) so the lambda is *not* quoted. It is
> evaluated by the "," and thus seen by the byte-compiler.
>
> Or maybe I'm just misunderstanding what you said. :-)

Well, the example does not match really well.  However, many uses of
delayed evaluation (of which backquoted lambda functions are one) are
not necessary once you can use closures.

-- 
David Kastrup