(original-number value)

that, given a number, will retrieve the original hex number?

(defun |#x| (in sub-char num-arg)
  (declare (ignore sub-char num-arg))
  (let* ((*read-base* 16)
         (integer (read in t nil t))
         (symbol (intern (write-to-string integer))))
    (setf (get symbol :input-type) :hex)
    (set symbol integer)))

(set-dispatch-macro-character #\# #\x #'|#x|)

(defun number-type (value)
  (let ((string-name (write-to-string value)))
    (if (find-symbol string-name)
        (prog1
            (get (intern string-name) :input-type)
          (unintern (intern string-name)))
        :integer)))

(number-type 255)  => :integer
(number-type #xff) => :hex
(number-type 255)  => :integer

Your question while humorous exposes a limitation of the Common Lisp type
system. To be able to operate upon source code at the list level requires
the ability to reconstruct the types of objects to a much greater level of
detail than the type system provides. If there was a way to enforce types
to be kept at say safety 4 then the type system itself could be used for
this purpose, e.g. a new type could be defined as HEX which was a subtype
of INTEGER and TYPEP could be used to check whether an INTEGER was subtype
HEX. But as (a) type information can be thrown away by an implementation
at any level of safety; and (b) custom types are translated to
implementation types, the type system cannot be portably used for this
purpose [this is a challenge: Someone please prove me wrong].

Common Lisp isn't the best language I can imagine. It's simply the best
one available.

  Nonsense.

| To be able to operate upon source code at the list level requires the
| ability to reconstruct the types of objects to a much greater level of
| detail than the type system provides.

  Common Lisp is not defined on the character strings that make up the
  source code.  If you want to manipulate the character sequence that
  makes up the source code, you MUST NOT give it to the Common Lisp
  reader to convert it into Common Lisp objects.

  We had this discussion endlessly and without resolution in the SGML
  community a decade ago.  People worried ceaselessly about how they
  would parse SGML documents such that they could re-create the exact
  character sequence that made up the document.  This obsession with the
  source form halted all work on tools to manipulate SGML documents
  intelligently, because it is in fact completely irrelevant what the
  character sequence of the source is as long as multiple forms have
  exactly the same semantics.  Comments in particular caused a lot of
  grief, but you MUST realize that if comments are important to you, you
  MUST NOT give them to the Common Lisp reader or any other parser for
  which they are not only unimportant, but completely irrelevant.

  Common Lisp offers its programmers the tools they need to manipulate
  the source at a level where the character sequences does not matter,
  and this tradition in the Lisp family is quite possibly the single
  most intelligent property of the whole Lisp tradition.  (And I have
  not mentioned Scheme, OK?)

| Common Lisp isn't the best language I can imagine. It's simply the
| best one available.

  Why involve the whole world in your imagination in a negative way like
  this?  We already know that your imagination includes thinking about
  the wasted cons cell of the QUOTE operator, so it is hard not to think
  it is somewhat lacking in working within the world just the way it is,
  but an «imagination» of the impossible is not useful unless you aspire
  to publish your fantasy writings or perhaps special effects software.
  Whatever you imagine, it must be realizable at some level, and you
  have to keep track of which parts of your imagination are going to be
  realizable and which are going to involve the imagination of other
  people.  I maintain that programming /languages/ is not a good arena
  for unrealizable, speculative imagination.

--
Erik Naggum | Oslo, Norway

Base 10 is convienent for humans so it makes a reasonable default, but
you are in no way required to keep it set that way.  You might try
experimenting with *read-base* and *print-base*.

(in-package capture-source)
(car (load-source "/home/adam/t/feed-the-troll.lisp")) =>

(defun utility (necessities luxuries dpr-value work-hours leisure-hours)
  "UTILITY is composed of:
1. Ability to satify necessities of life.
2. Amount of luxuries consumed.
3. Value/utils from fulfiling digital processing requirements.
4. Hours available for leisure/non-digital processing requirements."
  (|#.| . +optimize+)
  (declare
   (type (double-float 0.0) necessities luxuries dpr-value work-hours
    leisure-hours))
  (with-violation-support
   (* (if (>= necessities 1.0) 1.0 (sqrt (- 1.0 (square (- 1.0 necessities)))))
      (collect-violations (effectiveness work-hours leisure-hours))
      (+ (diminishing-utility (|#.| . +base-utils-from-luxuries+) luxuries)
         dpr-value
         (|;|
          . ";;dpr-fulfilment->dpr-value already incorporates diminishing utility")
         (diminishing-utility (|#.| . +base-utils-from-leisure-hours+)
          leisure-hours)))))

All done by the Lisp reader. Notice the unevaluated #. and the capture of
comments. This could be translated back to source text. Partly a proof of
concept. I can even handle the (non-)interning of symbols with a
(non-keyword) package prefix. The only place comments cannot appear is
within a dotted list, but I could handle this as well by further rewrites
of the list reader. The code is entirely portable and coexists with
standard reader definitions.

(read-list (make-string-input-stream "unknown-package:symbol)") #\( :custom t)
=> ((|:| . "unknown-package:symbol"))

(read-list (make-string-input-stream "unknown-package:symbol)") #\( :custom nil)
=> Reader error at 22 on #<String-Input Stream>:
Package "UNKNOWN-PACKAGE" not found.
   [Condition of type lisp::reader-package-error]

One explanation that forms like the above cannot in general be evaluated
as Lisp code is the insistence of Common Lisp to turn forms that return
zero values into nil. I will continue to use my imagination to consider
changes to Common Lisp and I will continue to work upon ideas you dismiss
as unrealisable.

It's unusual for me to choose to reply to you Erik. I don't make the
mistake often.

(vectorp (make-hex :value 33)) => NIL

It's well known  that numbers are actually represented  by little imps
inside the computers.   There are three kind of  imps: the mosig imps,
the lesig imps  and the midsig imps, (each coming  in three sexes: the
littlends,  the bigends, and  the mixends,  but strangely  enough, you
generally find  only imps of one  sex in a given  computer).  Some say
that  there are  also one  kind of  unsig imps,  but  they're probably
normal imps  hidding out of the  light. So all these  little imps hold
their  hands in  round, in  groups of  32, or  more often  nowadays in
groups of 64, but we still find  some small groups of 16 or 8, or even
of 9 and 36.  And depending on whether they've been struck on the head
by the BSD daemon,  they may have a bump on the  head and be crying or
not.   The more  they cry,  the higher  the value  of the  number they
represent.  (That ought to be the  same with politicians but it is not
unfortunately).

  I'm not sure what the smiley faces were about, but Lisp does not
"turn" a number into anything but that number. Numeric bases are
properties of of the representation of a number, not a property of a
number.

  Lisp reads in a series of characters (a representation), interprets
them according to the value of *read-base*, in order to produce an
integer number (actually, a representation of that number as a pattern
of bits in memory, but that's as close as a computer can get to a
number).

  Because humans have a difficult time seeing the memory bits inside
the machine, it is conventional to print out things in a
representation that a human can parse. In the case of Common Lisp, it
prints out numerals that denote the number in the base determined by
the value of *print-base*.

  #xFF is a representation of the same number represented by
#b11111111, which is the same number that is represented by 255 with
*read-base* bound to the number represented by #xA.

  Confusing the representation of a thing with the thing itself is one
of the commonest errors in thought. Common Lisp generally avoids these
errors pretty well.

http://www.google.com/groups?selm=87y8vuyrgi.fsf%40thalassa.informati...

what in what base should these numbers be considered to be?

[53]> (+s "nine" "five")
"fourteen"
[54]> (-s "eleven" "three")
"eight"
[55]> (*s
  "eight hundred and seventy-three thousand, five hundred and seventy-one"
  "seven hundred and sixty-six")
 "six hundred and sixty-nine million, one hundred and fifty-five thousand, three hundred and eighty-six"

(and check  the implementation, it really uses  COMMON-LISP numbers to
compute the values).

(deftype hex () 'integer)
(the hex 33) => 33

But the "presentation" type information is lost (the custom type is
translated to the implementation type).

If we replace 33 with the structure #S(hex :value 33) then a program no
longer evaluates the same, i.e. implementations have no understanding of
how to process (numeric) objects that are wrapped up with presentation
data.

I'm defining a presentation type as a piece of information attached to an
object that has no effect upon standard program evaluation and semantics.

This could be implemented using structures. Many of the Common Lisp
functions would have to be rewritten to discard the presentation
information.

Here's a partial implementation of Kaz's question:

(defpackage kaz
  (:use)
  (:import-from #:cl #:t #:nil #:&rest #:&optional))

(in-package kaz)

(cl:defstruct num
  hex value)

(cl:defun |read-!x| (in sub-char num-arg)
  (cl:declare (cl:ignore sub-char num-arg))
  (cl:let* ((cl:*read-base* 16)
            (value (cl:read in t nil t)))
    (make-num :hex t :value value)))

(cl:make-dispatch-macro-character #\!)
(cl:set-dispatch-macro-character #\! #\x #'|read-!x|)

(cl:defun orig-num (value)
  (cl:cond ((num-p value)
            (cl:when (num-hex value)
              (cl:format nil "#x~X" (num-value value))))
           (t (cl:format nil "~S" value))))

(cl:defun + (&rest args)
  (cl:if (cl:member-if #'num-p args)
         (cl:apply #'cl:+ (cl:mapcar #'(cl:lambda (obj)
                                         (cl:if (num-p obj)
                                                (num-value obj)
                                                obj)) args))
         (cl:apply #'cl:+ args)))

(cl:defun print (obj &optional out-stream)
  (cl:if (num-p obj)
         (cl:print (num-value obj) out-stream)
         (cl:print obj out-stream)))

! is used in place of # as the dispatching macro character to avoid
upsetting the standard reader. I would also store the actual text
composing the number rather than just a flag for hexadecimal in a better
implementation (e.g. #x00ff contains presentational information that
cannot be captured by converting 255 back to hexadecimal).

Thus I can now write:

(in-package kaz)
(+ !xff 1) => 256
(print !xff) => prints and returns 255.
(orig-num 255) => "255"
(orig-num !xff) => "#xFF"
(orig-num (+ !xff 1)) => "256"

[The last form demonstrates that the presentation information is discarded
once an object is modified or created]

Supporting ORIG-NUM has severe performance implications. The least impact
would probably come from a few type bits reserved for presentation
information, and this would probably only be viable upon 64-bit platforms.
Another method would be all objects attached to a presentation "pointer"
(that may also provide standard type information. Under particular
circumstances (low safety, good type declarations, non-use of TYPEP) these
pointers could be eliminated all together. Highly declared code could even
avoid type bit manipulation for integer arithmetic).

If we limit Kaz's requirements to reproducing the presentation information
at the source code level then the functionality can implemented with no
compiled-code performance impact:

(defstruct num
  hex value)

(defun |read-!x| (in sub-char num-arg)
  (declare (ignore sub-char num-arg))
  (let* ((*read-base* 16)
            (value (read in t nil t)))
    `(a-number ,(make-num :hex t :value value))))

(make-dispatch-macro-character #\!)
(set-dispatch-macro-character #\! #\x #'|read-!x|)

(defmacro a-number (num)
  (num-value num))

Now !xff evaluates and compiles to 255. But when quoted to inhibit the
evaluation it's (a-number #S(num :hex t :value 255)). So the above line of
source code (+ !xff 1) would be read as (+ (a-number #S(num :hex t :value
255)) 1) and when walking the list form of the code one would know when a
hexadecimal number is supposed to be printed instead of a decimal one.

But a (quote #xff) does not equal (quote !xff) the !x dispatching macro
can not replace #x.

(deftype hex () 'integer)
(the hex 33) => 33

But the "presentation" type information is lost (the custom type is
translated to the implementation type).

If we replace 33 with the structure #S(hex :value 33) then a program no
longer evaluates the same, i.e. implementations have no understanding of
how to process (numeric) objects that are wrapped up with presentation
data.

I'm defining a presentation type as a piece of information attached to an
object that has no effect upon standard program evaluation and semantics.

This could be implemented using structures. Many of the Common Lisp
functions would have to be rewritten to discard the presentation
information.

Here's a partial implementation of Kaz's question:

(defpackage kaz
  (:use)
  (:import-from #:cl #:t #:nil #:&rest #:&optional))

(in-package kaz)

(cl:defstruct num
  hex value)

(cl:defun |read-!x| (in sub-char num-arg)
  (cl:declare (cl:ignore sub-char num-arg))
  (cl:let* ((cl:*read-base* 16)
            (value (cl:read in t nil t)))
    (make-num :hex t :value value)))

(cl:make-dispatch-macro-character #\!)
(cl:set-dispatch-macro-character #\! #\x #'|read-!x|)

(cl:defun orig-num (value)
  (cl:cond ((num-p value)
            (cl:when (num-hex value)
              (cl:format nil "#x~X" (num-value value))))
           (t (cl:format nil "~S" value))))

(cl:defun + (&rest args)
  (cl:if (cl:member-if #'num-p args)
         (cl:apply #'cl:+ (cl:mapcar #'(cl:lambda (obj)
                                         (cl:if (num-p obj)
                                                (num-value obj)
                                                obj)) args))
         (cl:apply #'cl:+ args)))

(cl:defun print (obj &optional out-stream)
  (cl:if (num-p obj)
         (cl:print (num-value obj) out-stream)
         (cl:print obj out-stream)))

! is used in place of # as the dispatching macro character to avoid
upsetting the standard reader. I would also store the actual text
composing the number rather than just a flag for hexadecimal in a better
implementation (e.g. #x00ff contains presentational information that
cannot be captured by converting 255 back to hexadecimal).

Thus I can now write:

(in-package kaz)
(+ !xff 1) => 256
(print !xff) => prints and returns 255.
(orig-num 255) => "255"
(orig-num !xff) => "#xFF"
(orig-num (+ !xff 1)) => "256"

[The last form illustrates that the presentation information may (and
should) be discarded within numeric computations]

Supporting ORIG-NUM has severe performance implications. The least impact
would probably come from a few type bits reserved for presentation
information, and this would probably only be viable upon 64-bit platforms.
Another method would be all objects attached to a presentation "pointer"
(that may also provide standard type information. Under particular
circumstances (low safety, good type declarations, non-use of TYPEP) these
pointers could be eliminated all together. Highly declared code could even
avoid type bit manipulation for integer arithmetic).

If we limit Kaz's requirements to reproducing the presentation information
at the source code level then the functionality can implemented with no
compiled-code performance impact:

(defstruct num
  hex value)

(defun |read-!x| (in sub-char num-arg)
  (declare (ignore sub-char num-arg))
  (let* ((*read-base* 16)
            (value (read in t nil t)))
    `(a-number ,(make-num :hex t :value value))))

(make-dispatch-macro-character #\!)
(set-dispatch-macro-character #\! #\x #'|read-!x|)

(defmacro a-number (num)
  (num-value num))

Now !xff evaluates and compiles to 255. But when quoted to inhibit the
evaluation it's (a-number #S(num :hex t :value 255)). So the above line of
source code (+ !xff 1) would be read as (+ (a-number #S(num :hex t :value
255)) 1) and when walking the list form of the code one would know when a
hexadecimal number is supposed to be printed instead of a decimal one.

But as (quote #xff) does not equal (quote !xff) the !x dispatching macro
cannot replace #x.

  You seem to hurt because of something I said.  Had you responded less
  aggressively, I might have considered your pain.  Now I do not.

| I will continue to use my imagination to consider changes to Common
| Lisp and I will continue to work upon ideas you dismiss as
| unrealisable.

  It is not I who determine the realizability of your ideas.  If you
  fight with insufficient understanding, you will not accomplish much.
  This ought to have concerned you if the effectiveness of your ideas is
  relevant to you.  Considering your hostile response to my criticism
  and suggestions for more effective ideas and means of realizing them,
  it is unlikely that many people will tell you when you do something
  stupid, and thus you are doomed to learn only from your own mistakes.
  This is not a position anyone should be in unless they have worked
  very hard to deserve it.

| It's unusual for me to choose to reply to you Erik.  I don't make the
| mistake often.

  Once a year seems like a good first approximation to your reply rate.

--
Erik Naggum | Oslo, Norway

The myth that any given programming language is machine independent is
easily exploded by computing the sum of powers of 2.

 - If the result loops with period = 1 with sign +, you are on a
   sign-magnitude machine.  

 - If the result loops with period = 1 at -1, you are on a
   twos-complement machine.  

 - If the result loops with period > 1, including the beginning, you
   are on a ones-complement machine.  

 - If the result loops with period > 1, not including the beginning,
   your machine isn't binary -- the pattern should tell you the base.

 - If you run out of memory, you are on a string or Bignum system.

 - If arithmetic overflow is a fatal error, some fascist pig with a
   read-only mind is trying to enforce machine independence. But the
   very ability to trap overflow is machine dependent.  

By this strategy, consider the universe, or, more precisely, algebra:
let X = the sum of many powers of two = ...111111
now add X to itself; X + X = ...111110
thus, 2X = X - 1 so X = -1

That meant, for example, that

  (= 10 10.)  => NIL
  (= 10 8.)   => T

:D

  The English-speaking part of the world have enormous problem counting
  any higher than 20, which explains their Fred Flintstone Units and
  their irrational resistance to units that tends to yield measurements
  with values having more than 1 significant digits and their hostility
  towards the French for having invented smarter units, but strangely,
  they adopted the old French way to count large numbers, using the
  number of thousand groups: A million is a thousand thousand, a billion
  is a thousand million, a trillion is a thousand billion, etc, while
  the French changed their ways in 1948 to count the number of millions,
  so a million is a thousand thousand, a billion is a million million,
  and a trillion is a million billion.  You may note that new trillion
  has three million groups, and that this pattern is a lot more sensible
  than the the old trillion which has /four/ thousand groups.

  So when the U.S. federal deficit is two trillion dollars, is appears
  to Europeans to be a million times larger than it really is, which is
  probably the only good thing you could say about it.

--
Erik Naggum | Oslo, Norway