unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Helmut Eller <eller.helmut@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 32252@debbugs.gnu.org
Subject: bug#32252: [PATCH] %o and %x now format signed numbers
Date: Thu, 26 Jul 2018 10:43:52 +0200	[thread overview]
Message-ID: <m2effqgzef.fsf@gmail.com> (raw)
In-Reply-To: <1c3c61c4-f93f-3bea-f6ed-b89e1cdea89b@cs.ucla.edu> (Paul Eggert's message of "Thu, 26 Jul 2018 00:59:56 -0700")

On Thu, Jul 26 2018, Paul Eggert wrote:

> Helmut Eller wrote:
>
>> What's more interesting:
>> (format "%x" (lognot 8)) => "-9"
>> or
>> (format "%x" (lognot 8)) => "3ffffffffffffff7"
>>
>> For me, the first version is totally useless.
>
> Shrug. It's what Common Lisp and Scheme do, and it works pretty well
> once you get used to it.

It's because I happen to know a thing or two about Common Lisp that I
know that I almost always would prefer the way that Emacs Lisp prints
negative fixnums.

> Programs that need negative integers
> displayed modulo some power of 2 can use the mod or logand functions;
> that's the mathematically right way to do it anyway, and it's
> machine-independent.

Do you think I don't know that?  It's always possible to write a helper
function that does the formatting in the variant that you need.

>> Of course there have been proposals: Do your bignum stuff with a
>> different format specifier.
>
> And prohibit %x on bignums? That would make little sense.

It would prohibit only negative bignums just like negative flonums are
forbidden.  Besides I still think that it would make much more sense to
print flonums the way %a does in C; another reason for having %a or
another format specifier to do the hex conversion in a world with
bignums.

> Common Lisp and Scheme don't have any such prohibition; why should
> Emacs Lisp?

Because Emacs Lisp was very successful without bignums.  Even more
successful than most other Lisps with all their fancy bignums, complex
numbers, ratios and other numeric stuff that hardly anyone needs.  And
the stuff that almost everybody would like to have like, fast unboxed
arithmetic, is not offered in a reliable and portable way.

>> Here is another proposal: Add a read syntax for unsigned fixnums like
>> #x3fffffffffffffffu or alternatively #xu3fffffffffffffff.
>
> That's heading down the wrong path. Emacs Lisp does not have unsigned
> fixnums, so why add a syntax for a data type that does not exist?  And
> Emacs Lisp should not add such a data type, as it is a low-level
> machine concept unsuitable for Lisp, is not needed in Emacs Lisp, and
> would cause unnecessary complexity in documentation and
> implementation.

In my mind Emacs does have negative fixnums and there are various ways
to write negative fixnums.  Of course a special syntax is not absolutely
needed but it may be convenient.

Helmut





  reply	other threads:[~2018-07-26  8:43 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-23 19:12 bug#32252: [PATCH] %o and %x now format signed numbers Paul Eggert
2018-07-23 19:48 ` Helmut Eller
2018-07-23 19:49 ` Drew Adams
2018-07-23 23:30   ` Paul Eggert
2018-07-24  1:20     ` Drew Adams
2018-07-24  2:04       ` Paul Eggert
2018-07-24  2:38         ` Eli Zaretskii
2018-07-24  2:44           ` Paul Eggert
2018-07-24 14:29             ` Eli Zaretskii
2018-07-24  4:15         ` Drew Adams
2018-07-23 23:39 ` Paul Eggert
2018-07-24  1:16   ` Drew Adams
2018-07-25  3:53     ` Richard Stallman
2018-07-25 21:56       ` Drew Adams
2018-07-27  3:20         ` Richard Stallman
2018-07-24  4:49   ` Helmut Eller
2018-07-24 14:22     ` Paul Eggert
2018-07-24 14:35       ` Andreas Schwab
2018-07-24 18:15       ` Helmut Eller
2018-07-25  0:50         ` Paul Eggert
2018-07-25  2:41           ` Eli Zaretskii
2018-07-25 17:21             ` Paul Eggert
2018-07-25 17:28               ` Eli Zaretskii
2018-07-26  7:44                 ` Paul Eggert
2018-07-26  8:04                   ` Helmut Eller
2018-07-26  8:16                     ` Paul Eggert
2018-07-25  6:58           ` Helmut Eller
2018-07-26  7:59             ` Paul Eggert
2018-07-26  8:43               ` Helmut Eller [this message]
2018-07-26  9:15                 ` Paul Eggert
2018-07-26  9:39                   ` Helmut Eller
2018-07-26  9:31                 ` Andreas Schwab
2018-07-26  9:40                   ` Robert Pluim
2018-07-26  9:56                   ` Helmut Eller
2018-07-26 16:55                     ` Paul Eggert
2018-07-26 17:16                       ` Helmut Eller
2018-07-26 17:50                         ` Paul Eggert
2018-07-26 18:35                           ` Helmut Eller
2018-07-26 21:07                             ` Paul Eggert
2018-07-24 18:27     ` Eli Zaretskii
2018-07-25  0:54       ` Paul Eggert
2018-07-25  8:09         ` Andreas Schwab
2018-07-25 20:16           ` Paul Eggert
2018-07-25 14:17         ` Eli Zaretskii
2018-07-25 23:33         ` Brett Gilio
2018-07-26  7:26           ` Paul Eggert
2018-07-24 16:26 ` Andy Moreton
2018-07-25 10:08 ` Andy Moreton
2018-07-26 12:52 ` Andy Moreton
2018-07-26 12:54 ` Andy Moreton
2018-07-26 17:18 ` Helmut Eller
2018-08-23  9:37 ` Helmut Eller
2022-07-04  1:03 ` bug#32252: i find binary-as-unsigned to be very helpful snickerbockers

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=m2effqgzef.fsf@gmail.com \
    --to=eller.helmut@gmail.com \
    --cc=32252@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    /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).