From: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Sebastian Wiesner <lunaryorn@gmail.com>, emacs-devel@gnu.org
Subject: Re: Can the byte-compiler check whether functions passed by name are defined?
Date: Mon, 5 Aug 2013 10:52:43 +0200 [thread overview]
Message-ID: <CANtbJLFde6esQcc+oFKDfT4aGLp8p-t2gjdw3gHm6NRQa92hRw@mail.gmail.com> (raw)
In-Reply-To: <jwvwqo12n1l.fsf-monnier+emacs@gnu.org>
2013/8/4 Stefan Monnier <monnier@iro.umontreal.ca>:
>
> As mentioned, the best option is to start by adding warnings for the
> #'symbol form (should be easy: handle it in the same way we handle
> warnings for function calls).
>
> Then make the higher-order functions turn 'symbol into #'symbol.
> That's important for things like
>
> (if foo #'a #'b)
>
I am not sure I understand what you have in mind. Is the following
snippet such a case?
(mapcar (if flag 'f1 'f2) list)
=> (mapcar (if flag #'f1 #'f2) list)
I don't see much point in that, because I don't like the notion that
the above code behaves different from
(defun select-function (flag f)
(if flag f 'default-f))
...
(mapcar (select-function flag 'f1) alist)
In my implementation still warnings would be created if the programmer
explicitly writes #'f1, #'f2 in `select-function', which I suppose
would happen with yours too. Handling cases like computed function
names seems fairly complex -- what about e.g.
(mapcar (catch 'function
(dolist (f function-list)
(when (PREDICATE f)
(throw 'function f)))
'default-function)
list)
When the simple if-case generates a warning, naively I'd expect this
to generate a warning too, but I'd expect it to become impossibly
complex then.
> Sadly, I defined the `compiler-macro' declaration to take a function
> rather than an exp that returns a function, so you can't just
> write a function macroexp--rewrite-function-arguments and then use:
>
> (defun my-combine (func1 func2)
> (declare (compiler-macro (macroexp--rewrite-function-arguments 0 1)))
>
> But you can do something like
>
> (defun my-combine (func1 func2)
> (declare (compiler-macro
> (lambda (body)
> (macroexp--rewrite-function-arguments
> body (rewrite func1) (rewrite func2)))))
>
> (defun my-mapcar (func list)
> (declare (compiler-macro
> (lambda (body)
> (macroexp--rewrite-function-arguments
> body (rewrite func) list))))
>
> Still, this annotation is only needed to turn a ' into a #', so it's not
> the most important.
Shouldn't the markup for user-written functions be a bit easier?
Something along the lines of using a list of positions (like specified
by my declare form) and having the rewriting, if any, done inside
byte-compile-normal-call or whichever function would be the correct
place. Especially since `compiler-macro' seems to be undocumented...
>> I couldn't define the handler in "byte-run.el" however, as when I added it
>> to the declaration of `defun-declaration-alist', it would suddenly be
>> missing again during compilation.
>
> Probably because you didn't re-dump Emacs (byte-run.el is preloaded
> into the `emacs' executable so if you change it, you need to rebuild
> `emacs').
Indeed I did not, since I did not expect this behaviour. Rebuilding
emacs is fairly slow on windows, so I didn't even think of this
possibility.
Anyway, I find the behaviour confusing. Having code preloaded into
the binary is okay, but having code in installation directory that is
ignored even when it has been changed seems a bit awkward. Or IS it
loaded when changed and just didn't change `defun-declaration-alist',
because it is bound already before loading the changed byte-code?
- Klaus
next prev parent reply other threads:[~2013-08-05 8:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-29 10:35 Can the byte-compiler check whether functions passed by name are defined? Klaus-Dieter Bauer
2013-07-29 15:21 ` Stefan Monnier
2013-07-31 13:44 ` Klaus-Dieter Bauer
2013-07-31 17:49 ` Stefan Monnier
2013-07-31 18:01 ` Sebastian Wiesner
2013-08-01 20:31 ` Stefan Monnier
2013-08-04 18:41 ` Klaus-Dieter Bauer
2013-08-04 21:11 ` Stefan Monnier
2013-08-05 8:52 ` Klaus-Dieter Bauer [this message]
2013-08-05 14:35 ` Stefan Monnier
2013-08-05 18:17 ` Klaus-Dieter Bauer
2013-08-07 11:27 ` Klaus-Dieter Bauer
2013-08-07 14:41 ` Stefan Monnier
2013-08-07 15:11 ` Klaus-Dieter Bauer
2013-08-07 15:21 ` Stefan Monnier
2013-08-07 17:34 ` Stefan Monnier
2013-08-07 21:11 ` Glenn Morris
2013-08-07 21:59 ` Glenn Morris
2013-08-08 1:25 ` Stefan Monnier
2013-08-08 8:44 ` Klaus-Dieter Bauer
2013-08-08 13:07 ` Stefan Monnier
2013-08-07 19:59 ` Klaus-Dieter Bauer
2013-08-07 21:14 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANtbJLFde6esQcc+oFKDfT4aGLp8p-t2gjdw3gHm6NRQa92hRw@mail.gmail.com \
--to=bauer.klaus.dieter@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=lunaryorn@gmail.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).