unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>
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, 05 Aug 2013 10:35:22 -0400	[thread overview]
Message-ID: <jwv1u681aic.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CANtbJLFde6esQcc+oFKDfT4aGLp8p-t2gjdw3gHm6NRQa92hRw@mail.gmail.com> (Klaus-Dieter Bauer's message of "Mon, 5 Aug 2013 10:52:43 +0200")

>> 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.

That's because my fingers fumbled.  The "That's important for things
like" refers to the "warnings for #'" in the previous paragraph.
The "Then make the higher..." line should have come afterwards.

>     (mapcar (if flag 'f1 'f2) list)
>     => (mapcar (if flag #'f1 #'f2) list)

No, I definitely don't want to get into such fanciness.
But I do want compiler warnings if the coder writes

     (mapcar (if flag #'f1 #'f2) list)

and `f1' or `f2' are unknown.
     
>     (defun select-function (flag f)
>       (if flag f 'default-f))
>     ...
>     (mapcar (select-function flag 'f1) alist)

100% agreement.

> Shouldn't the markup for user-written functions be a bit easier?

I'm not too worried about it, no.  We should instead aim to teach people
to write #'foo instead of 'foo.

Given that we can't get warnings for (if a 'foo 'bar), it's OK if you
won't get warnings for all cases of (higher-order-func arg1 'foo).

> 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.

Yes, it's a bit confusing.  But the source is still very useful (Emacs
(and the ideals of Free Software) wants you to have very easy access to
the source), so we could arguably get rid of the preloaded .elc files,
but we'd still have to keep the .el file, so in most cases you'd still
be just as confused.

> Or IS it loaded when changed

No, it's not re-loaded (we do have such a "re-load" hack in
byte-compile-refresh-preloaded but it's only used when rebuilding Emacs
to try and minimize the need to bootstrap).

> and just didn't change `defun-declaration-alist', because it is bound
> already before loading the changed byte-code?

Indeed, that's one of the shortcomings of byte-compile-refresh-preloaded.


        Stefan



  reply	other threads:[~2013-08-05 14:35 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
2013-08-05 14:35                 ` Stefan Monnier [this message]
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=jwv1u681aic.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=bauer.klaus.dieter@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=lunaryorn@gmail.com \
    /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).