unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: MON KEY <monkey@sandpframing.com>
To: emacs-devel@gnu.org
Subject: lexbind, global namespace prefixes, `byte-compile-defvar', and `custom-guess-name-alist'
Date: Wed, 12 Jan 2011 16:00:40 -0500	[thread overview]
Message-ID: <AANLkTiknzoiGMMLPR2TrOayOM_deAHHKtKBrQvNWo5OT@mail.gmail.com> (raw)

It would be nice if `custom-guess-name-alist' recognized the
convention of naming global variables `*with-earmuffs*'.

I propose adding the following element:

 ("\\`\\*.*\\*\\'" variable)

In its current configuration the lexbind branch introduces new
treatmeant around declared special variables.

Specifically, there are these new symbols and primitives:
 `special-variable-p', `declared_special',
 `Vinternal_interpreter_environment',
 `Qinternal_interpreter_environment',

which affect (at least) the following symbols and primitives:

`defvar_per_buffer', `defvar', `defvaralias', `setq', `defconstant',
`let*', `let', `make-symbol', `funcall_lambda', etc.

Likewise, bzr revno: 101441 of 2010-09-15 in trunk says:

,----
|
| (byte-compile-file-form-defvar, byte-compile-defvar): Warn about
|  global vars which don't have a prefix and could hence affect lexical
|  scoping in unrelated files.
|
`----

The above change means that `byte-compile-defvar' now warns when

 (byte-compile-warning-enabled-p 'lexical)

returns non-nil and the symbol-name of a putatively special variable
does not match the regexp "[-*/:$]".

Currently this regexp is "optimized" under the assumption that if any
of the tokens "-" "*" "/" ":" "$" are present in a symbol-name then
that symbol is a potential global/dynamic var which does not lack a
prefix.

Given the warning issued and the regexp which triggers it, there seems
to be an implication that global "special variables" may be named
without a "namespace" so long as one or more magic tokens are present.
Indeed the warning even acknowledges certain lexical lisp conventions
of naming global/special variable symbols `*with-earmuffs*'.

Disregarding the (future) mechanisms by which one may declare a variable
special, there are perhaps unintended consesequence with the current
regexp in that where a symbol is named as `*earmuff', `/slashy',
`-dashy', `:colonic', `%fractured', it will regarded by the
byte-compiler as properly prefixed even though these aren't
file/library contexting namespaces...

As such, it might be be nice to see these pairs included of
`custom-guess-name-alist' as well:

 ("\\`[%$]"        function)  ;; `%private-fun', `$internal-fun'
 ("!\\'"           function)  ;; `set-foo!', `mutate-bar!'
 ("\\`\\+.*\\+\\'" variable)  ;; `+superior-lisp+', `+constant-name+'
 ("\\`-"           variable)  ;; `--some-var--', `-her-buddy-', `--his-pal'

The general thrust of these suggestions is that users should be
presented with a consistent interface to help with disambiguating
global variables in the lexbind esp. where there is potential for
introduction of confusion around local-variables, permanent-locals,
etc. which might otherwise go unnoticed, become difficult to
gain access to and/or become informed of.

--
/s_P\



                 reply	other threads:[~2011-01-12 21:00 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=AANLkTiknzoiGMMLPR2TrOayOM_deAHHKtKBrQvNWo5OT@mail.gmail.com \
    --to=monkey@sandpframing.com \
    --cc=emacs-devel@gnu.org \
    /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).