[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: help with regexp function
From: |
Stephen Berman |
Subject: |
Re: help with regexp function |
Date: |
Fri, 24 Nov 2017 17:28:25 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
On Fri, 24 Nov 2017 08:46:59 -0600 "B. T. Raven" <btraven@nihilo.net> wrote:
> On 11/23/2017 09:20, Stephen Berman wrote:
>
>>> It sounded like (append #'string ... was recasting a list to a string.
>> ^^^^^^
>> apply
> Yes, because I tried to type rather than copypaste.
> I was distracted by the # (what does it mean?)
Together with the apostrophe it stands for `function'. I can't explain
it better than the Elisp manual (info "(elisp) Anonymous Functions"):
-- Special Form: function function-object
This special form returns FUNCTION-OBJECT without evaluating it.
In this, it is similar to ‘quote’ (*note Quoting::). But unlike
‘quote’, it also serves as a note to the Emacs evaluator and
byte-compiler that FUNCTION-OBJECT is intended to be used as a
function. Assuming FUNCTION-OBJECT is a valid lambda expression,
this has two effects:
• When the code is byte-compiled, FUNCTION-OBJECT is compiled
into a byte-code function object (*note Byte Compilation::).
• When lexical binding is enabled, FUNCTION-OBJECT is converted
into a closure. *Note Closures::.
The read syntax ‘#'’ is a short-hand for using ‘function’. The
following forms are all equivalent:
(lambda (x) (* x x))
(function (lambda (x) (* x x)))
#'(lambda (x) (* x x))
>> I'm not sure it's helpful to think of it like that, since using a list
>> is an artefact of the function definition here: `string' takes one or
>> more characters but Emacs Lisp functions cannot return multiple values,
>> only single values such as a list of characters. But you can dispense
>> with that intermediate step:
>>
>> (defun reverse-string (str)
>> (let ((l (length str))
>> (nstr ""))
>> (dotimes (i l nstr)
>> (setq nstr (concat (string (aref str i)) nstr)))))
>>
>> In fact, this is essentially how `nreverse' (and 'reverse') operate on
>> strings (so there's no need for `reverse-string'). In any case, I don't
>> see what this has to do with match-string.
>
> That looks like it may be faster than what
> I have now. Is it? Everything is in C except dotimes and string-to-list
> according to the function docs.
I don't know if there's a measurable difference, but again, why do you
want `reverse-string' when you can just use `reverse' (or `nreverse')?
Steve Berman