Hi, I don't have a clue here. I understand that Lisp is not a
base-sensitive language; it turns everything into base 10. When I
enter an integer as #xFF, later it prints as 255! Is there a function
like:
(original-number value)
that, given a number, will retrieve the original hex number?
:) :) :) :)
···@ashi.footprints.net (Kaz Kylheku) writes:
> Hi, I don't have a clue here. I understand that Lisp is not a
> base-sensitive language; it turns everything into base 10. When I
> enter an integer as #xFF, later it prints as 255! Is there a function
> like:
>
> (original-number value)
>
> that, given a number, will retrieve the original hex number?
>
> :) :) :) :)
Why not use (format nil "~X" value) to get the string representation
of the number's value in hex, which is probably what you're after.
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*.
Gregm
From: Tim Bradshaw
Subject: Re: Integer with base preserved!
Date:
Message-ID: <ey3y8s32c5j.fsf@cley.com>
* Kaz Kylheku wrote:
> Hi, I don't have a clue here. I understand that Lisp is not a
> base-sensitive language; it turns everything into base 10. When I
> enter an integer as #xFF, later it prints as 255! Is there a function
> like:
I'm afraid you are confused. CL is really a MACLISP derivative, and
as such its internal representation is, of course, octal.
Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> * Kaz Kylheku wrote:
> > Hi, I don't have a clue here. I understand that Lisp is not a
> > base-sensitive language; it turns everything into base 10. When I
> > enter an integer as #xFF, later it prints as 255! Is there a function
> > like:
>
> I'm afraid you are confused. CL is really a MACLISP derivative, and
> as such its internal representation is, of course, octal.
No way dude, the Mac was based on the 68000 chip, which uses hex (with
a $ prefix, as in move.l #$FF, (A0) and all dat).
:)
···@ashi.footprints.net (Kaz Kylheku) writes:
> Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> > * Kaz Kylheku wrote:
> > > Hi, I don't have a clue here. I understand that Lisp is not a
> > > base-sensitive language; it turns everything into base 10. When I
> > > enter an integer as #xFF, later it prints as 255! Is there a function
> > > like:
> >
> > I'm afraid you are confused. CL is really a MACLISP derivative, and
> > as such its internal representation is, of course, octal.
>
> No way dude, the Mac was based on the 68000 chip, which uses hex (with
> a $ prefix, as in move.l #$FF, (A0) and all dat).
>
> :)
All of you are plain wrong.
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).
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
From: Joe Marshall
Subject: Re: Integer with base preserved!
Date:
Message-ID: <n08htjqo.fsf@ccs.neu.edu>
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> ···@ashi.footprints.net (Kaz Kylheku) writes:
>
>> Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
>> > * Kaz Kylheku wrote:
>> > > Hi, I don't have a clue here. I understand that Lisp is not a
>> > > base-sensitive language; it turns everything into base 10. When I
>> > > enter an integer as #xFF, later it prints as 255! Is there a function
>> > > like:
>> >
>> > I'm afraid you are confused. CL is really a MACLISP derivative, and
>> > as such its internal representation is, of course, octal.
>>
>> No way dude, the Mac was based on the 68000 chip, which uses hex (with
>> a $ prefix, as in move.l #$FF, (A0) and all dat).
>>
>> :)
>
> All of you are plain wrong.
From HAKMEM, ITEM 154 (Gosper):
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
therefore algebra is run on a machine (the universe) which is
twos-complement.
On 8630 day of my life Joe Marshall wrote:
> 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
^^ Wrong, because X is not an element of
a group.
--
Ivan Boldyrev
Onions have layers. Unix has layers too.
From: Joe Marshall
Subject: Re: Integer with base preserved!
Date:
Message-ID: <hdygml0r.fsf@comcast.net>
Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
> On 8630 day of my life Joe Marshall wrote:
>> 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
> ^^ Wrong, because X is not an element of
> a group.
*You* tell it to Gosper.
--
~jrm
Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
> On 8630 day of my life Joe Marshall wrote:
> > 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
> ^^ Wrong, because X is not an element of
> a group.
Sure is: ...11111 is a p-adic integer. (Oh, and yes, if p=2, we have
even ...111 = -1).
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID #xEEFBA4AF
···@ashi.footprints.net (Kaz Kylheku) writes:
>
> Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> > * Kaz Kylheku wrote:
> > > Hi, I don't have a clue here. I understand that Lisp is not a
> > > base-sensitive language; it turns everything into base 10. When I
> > > enter an integer as #xFF, later it prints as 255! Is there a function
> > > like:
> >
> > I'm afraid you are confused. CL is really a MACLISP derivative, and
> > as such its internal representation is, of course, octal.
>
> No way dude, the Mac was based on the 68000 chip, which uses hex (with
> a $ prefix, as in move.l #$FF, (A0) and all dat).
>
> :)
But MACLISP was based on Project MAC at MIT, not on the Macintosh
computer. And it really was base 8 at heart. That is why you often saw
integers with trailing decimal points. A trailing decimal point (with
no other digits behind it) indicated a base-10 integer constant rather
than a base-8 integer constant.
That meant, for example, that
(= 10 10.) => NIL
(= 10 8.) => T
:D
--
Thomas A. Russ, USC/Information Sciences Institute
Hi Kaz Kylheku,
> Hi, I don't have a clue here. I understand that Lisp is not a
> base-sensitive language; it turns everything into base 10. When I
> enter an integer as #xFF, later it prints as 255! Is there a function
> like:
>
> (original-number value)
>
> that, given a number, will retrieve the original hex number?
>
> :) :) :) :)
[The following code is evil]
(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.
Regards,
Adam
* Adam Warner
| Your question while humorous exposes a limitation of the Common Lisp
| type system.
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
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
From: Tim Bradshaw
Subject: Re: Integer with base preserved!
Date:
Message-ID: <ey3oesz2bxb.fsf@cley.com>
* Erik Naggum wrote:
> 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.
If you insist that you *can* give them to the reader, then you end up
with InterLISP. I remember that the Medley handling of things like #+
and #- was interesting in the sort of really bad way you'd expect.
--tim
Hi Erik Naggum,
> * Adam Warner
> | Your question while humorous exposes a limitation of the Common Lisp
> | type system.
>
> 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.
/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 0d0)
necessities luxuries dpr-value work-hours leisure-hours))
(with-violation-support
(* (if (>= necessities 1d0)
1d0
(sqrt (- 1d0 (square (- 1d0 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)))))
---------------------------------
(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]
> 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.
By using my methods of legitimate inquiry (e.g. asking questions, like
why QUOTE wastes a cons cell) as a weapon to attack me just reinforces the
hypocrisy of your self-presentation as a man of reason.
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.
Regards,
Adam
* Adam Warner
| By using my methods of legitimate inquiry (e.g. asking questions, like
| why QUOTE wastes a cons cell) as a weapon to attack me just reinforces
| the hypocrisy of your self-presentation as a man of reason.
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
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
From: Joe Marshall
Subject: Re: Integer with base preserved!
Date:
Message-ID: <wu7mgzgf.fsf@ccs.neu.edu>
Adam Warner <······@consulting.net.nz> writes:
> (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.
There is nothing wrong with the type system. That it does not conform
to your imagination is not a limitation.
> 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;
Type information is not thrown away. The fact that the garbage
collector works is evidence of this.
> 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].
(defstruct hex
value)
(vectorp (make-hex :value 33)) => NIL
However, most implementations of defstruct allocate a linear region of
memory. Some even allocate a literal vector before re-tagging it to
indicate a struct.
Hi Joe Marshall,
> Adam Warner <······@consulting.net.nz> writes:
>
>> (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.
>
> There is nothing wrong with the type system. That it does not conform
> to your imagination is not a limitation.
>
>> 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;
>
> Type information is not thrown away. The fact that the garbage
> collector works is evidence of this.
>
>> 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].
>
> (defstruct hex
> value)
>
> (vectorp (make-hex :value 33)) => NIL
#S(hex :value 33) doesn't evaluate to 33. Using a defined type does:
(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.
Regards,
Adam
Hi Joe Marshall,
> Adam Warner <······@consulting.net.nz> writes:
>
>> (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.
>
> There is nothing wrong with the type system. That it does not conform
> to your imagination is not a limitation.
>
>> 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;
>
> Type information is not thrown away. The fact that the garbage
> collector works is evidence of this.
>
>> 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].
>
> (defstruct hex
> value)
>
> (vectorp (make-hex :value 33)) => NIL
#S(hex :value 33) doesn't evaluate to 33. Using a defined type does:
(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.
Regards,
Adam
From: Joe Marshall
Subject: Re: Integer with base preserved!
Date:
Message-ID: <r7xttk0u.fsf@ccs.neu.edu>
Adam Warner <······@consulting.net.nz> writes:
> #S(hex :value 33) doesn't evaluate to 33.
Of course not! You wanted a HEX type that was distinguishable from CL
integers.
> 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.
Exactly. The HEX type is different from the integer type, so you will
have to define what it means to process it numerically. For instance,
what does it mean to add two HEXs together? What about if the result
is larger than 255? What does it mean to divide them? What about
adding an integer to a HEX? Can you add OCTals to HEXs? What is the
result type?
> 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.
That is not usually what is meant by a type.
Adam Warner <······@consulting.net.nz> writes:
>
> 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.
If you want presentation types, you know where to find them: CLIM. The
presentation type information is explicit in the program but implicit
on the display.
Tim
Hi Timothy Moore,
> If you want presentation types, you know where to find them: CLIM. The
> presentation type information is explicit in the program but implicit on
> the display.
Thanks for the tip Timothy. I haven't used CLIM and I wasn't consciously
(mis)appropriating the term.
Regards,
Adam
From: Rahul Jain
Subject: Re: Integer with base preserved!
Date:
Message-ID: <87fze4sw4d.fsf@nyct.net>
Adam Warner <······@consulting.net.nz> writes:
> Hi Timothy Moore,
>
>> If you want presentation types, you know where to find them: CLIM. The
>> presentation type information is explicit in the program but implicit on
>> the display.
>
> Thanks for the tip Timothy. I haven't used CLIM and I wasn't consciously
> (mis)appropriating the term.
It's not really a misappropriation at all. You're describing exactly
what presentation types are for. That is, they have no relevance to the
processing of objects, merely to the way in which you'd like to display
it in some part of some user interface. Of course, a presentation is not
the number that it is displaying. You can't add a presentation of an
integer in hex format to another one, but you could define a
presentation-g-f that did something like that and then returned the
result as some sort of presentation, as well. What presentation type
that result would have is not at all a feature of the number system, but
rather, a feature of the user interface the application would like to
provide to the user. Thankfully, the application you choose to write is
not specified in either the CL or CLIM standards.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
> Hi, I don't have a clue here. I understand that Lisp is not a
> base-sensitive language; it turns everything into base 10. When I
> enter an integer as #xFF, later it prints as 255! Is there a function
> like:
>
> (original-number value)
>
> that, given a number, will retrieve the original hex number?
Kaz--
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.
Consider binding *print-base* to get the effect you are looking for.
··············@hotmail.com (Joseph Oswald) writes:
> ···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
> > Hi, I don't have a clue here. I understand that Lisp is not a
> > base-sensitive language; it turns everything into base 10. When I
> > enter an integer as #xFF, later it prints as 255! Is there a function
> > like:
> >
> > (original-number value)
> >
> > that, given a number, will retrieve the original hex number?
>
> Kaz--
>
> 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.
>
> Consider binding *print-base* to get the effect you are looking for.
Or, said otherwise,
http://www.google.com/groups?selm=87y8vuyrgi.fsf%40thalassa.informatimago.com&oe=UTF-8&output=gplain
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).
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <····@thalassa.informatimago.com> wrote:
> "six hundred and sixty-nine million, one hundred and fifty-five thousand,
> three hundred and eighty-six"
FWIW, the above output is wrong - "and" should only be used between the
whole number and fractional parts, e.g.
six hundred sixty-nine million, one hundred fifty-five thousand, three
hundred eighty-six and three tenths
Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
> In article <··············@thalassa.informatimago.com>,
> Pascal Bourguignon <····@thalassa.informatimago.com> wrote:
>
>> "six hundred and sixty-nine million, one hundred and fifty-five thousand,
>> three hundred and eighty-six"
>
> FWIW, the above output is wrong - "and" should only be used between the
> whole number and fractional parts, e.g.
>
> six hundred sixty-nine million, one hundred fifty-five thousand, three
> hundred eighty-six and three tenths
That's true in US English. It's not true in British English.
In the absence of a clear indication of which variety of English
Pascal was intending to write, it's not reasonable to dismiss
what he wrote as "wrong".
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
>
> > In article <··············@thalassa.informatimago.com>,
> > Pascal Bourguignon <····@thalassa.informatimago.com> wrote:
> >
> >> "six hundred and sixty-nine million, one hundred and fifty-five thousand,
> >> three hundred and eighty-six"
> >
> > FWIW, the above output is wrong - "and" should only be used between the
> > whole number and fractional parts, e.g.
It's in the same base as the input, though!
> > six hundred sixty-nine million, one hundred fifty-five thousand, three
> > hundred eighty-six and three tenths
>
> That's true in US English. It's not true in British English.
> In the absence of a clear indication of which variety of English
> Pascal was intending to write, it's not reasonable to dismiss
> what he wrote as "wrong".
I don't know, what are the difference in English and US numbers? But
it does not matter, at least lisp ~R is consistent and it parsed the
numbers and formated the output in the same language.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
* Pascal Bourguignon
| I don't know, what are the difference in English and US numbers?
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
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> writes:
> Fred Flintstone Units
They're actually nice round binary numbers (except for the tsp/Tbls
transition). Eg:
11 tsp = 1 Tbls
100 Tbls = 1 Cup
10 Cups = 1 Pint
100 Cups = 1 Quart
100 Quarts = 1 Gallon
So maybe Robby The Robot Units is more like it
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Joe Marshall
Subject: Re: Integer with base preserved!
Date:
Message-ID: <llnyr3ij.fsf@ccs.neu.edu>
Erik Naggum <····@naggum.no> writes:
> * Pascal Bourguignon
> | I don't know, what are the difference in English and US numbers?
>
> 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
Irrational?! The english standard of measurement is nothing *but*
rational:
1/8 mile per furlong
1/10 furlong per chain
1/4 chain per rod
1/25 rod per link
50/11 links per yard
1/3 yard per foot
1/12 foot per inch
1/3 inch per barleycorn
All sorts of ratios.
I have been informed that the British have taken up bad habits from
American English and use �billion� to refer to both �thousand million�
and �million million� with no other way to distinguish them than to
think about the values and reject one of the two meanings intuitively.
This and the Fred Flintstone Units ought to relegate English to the
garbage dump of history. Just re-elect George W. Bush and be done
with it, OK?
--
Erik Naggum, disillusioned in Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
From: Tim Bradshaw
Subject: Re: Integer with base preserved!
Date:
Message-ID: <ey3hdymd57e.fsf@cley.com>
* Erik Naggum wrote:
> I have been informed that the British have taken up bad habits from
> American English and use �billion� to refer to both �thousand million�
> and �million million� with no other way to distinguish them than to
> think about the values and reject one of the two meanings intuitively.
I don't think we do that. I think we've changed from an old
convention where a billion was a million million to a new one where a
billion is a thousand million. There has probably been (well: has
certainly been) some confusion during the change, and there are no
doubt holdouts who insist on the old usage, but I don't think that
both usages can be used at once.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Erik Naggum wrote:
> > I have been informed that the British have taken up bad habits from
> > American English and use �billion� to refer to both �thousand million�
> > and �million million� with no other way to distinguish them than to
> > think about the values and reject one of the two meanings intuitively.
>
> I don't think we do that. I think we've changed from an old
> convention where a billion was a million million to a new one where a
> billion is a thousand million. There has probably been (well: has
> certainly been) some confusion during the change, and there are no
> doubt holdouts who insist on the old usage, but I don't think that
> both usages can be used at once.
If that's so, perhaps that's the reason why Beagle 2 is not responding!
The S.I.� is the only way to the stars. ;-)
�) Syst�me Internationnal d'Unit�s http://www.bipm.org/en/si/
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Erik Naggum <····@naggum.no> writes:
> I have been informed that the British have taken up bad habits from
> American English and use �billion� to refer to both �thousand million�
> and �million million� with no other way to distinguish them than to
> think about the values and reject one of the two meanings intuitively.
I can't remember the last time I heard "billion" used to mean
"million million", so I don't think this is a serious practical
problem. It's ugly, though.
> This and the Fred Flintstone Units ought to relegate English to the
> garbage dump of history. Just re-elect George W. Bush and be done
> with it, OK?
Re-electing Dubya might consign too many other things to the
garbage dump of history, or for that matter to any convenient
garbage dump, so despite the antiquaronian charmulation of
his peculiatory manner of speakitude I'm not inclined to
accept your suggestion. Anyway, there's not a whole lot I
can do to get him elected or unelected. (If his first "election"
is anything to go by, there may not be much any voter can do.)
Um. I've been involved in one political flamefest in c.l.l
already this month. I'd better stop.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
>
> Re-electing Dubya might consign too many other things to the
> garbage dump of history, or for that matter to any convenient
> garbage dump, so despite the antiquaronian charmulation of
> his peculiatory manner of speakitude I'm not inclined to
> accept your suggestion. Anyway, there's not a whole lot I
> can do to get him elected or unelected. (If his first "election"
> is anything to go by, there may not be much any voter can do.)
>
> Um. I've been involved in one political flamefest in c.l.l
> already this month. I'd better stop.
A little consistency, please! You and Joe with your interminable
discussion of headscarf education have created the illusion that c.l.l.
is a fine place to swap recipes for vegetables and debate American
presidential politics (so you cannot claim it is of interest to anyone
but the candidates, whom I have not seen here lately) and anything else
you spot in the morning paper. Don't stop now, just as you are on the
verge of success. One or two more threads like the one on math education
and the precedent will be firmly in place, and there will be no danger
anyone getting curious about Lisp will find here anything other than a
bunch of self-appointed experts spouting endlessly on everything but
Lisp. They will conclude they were right in the first place, Lisp is
dead, can't even support a proper newsgroup.
Hey, what do you think, is it for real this time, the Ben&Jen breakup
:)?
kenny
ps. Three hundred words on dubbya followed by "I'd better stop" is what
we call a non-stopping stop.
k
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Pascal Bourguignon wrote:
[various other people:]
> > > six hundred sixty-nine million, one hundred fifty-five thousand, three
> > > hundred eighty-six and three tenths
> >
> > That's true in US English. It's not true in British English.
> > In the absence of a clear indication of which variety of English
> > Pascal was intending to write, it's not reasonable to dismiss
> > what he wrote as "wrong".
[Pascal:]
> I don't know, what are the difference in English and US numbers? But
> it does not matter, at least lisp ~R is consistent and it parsed the
> numbers and formated the output in the same language.
British English puts an "and" in the construction "--- hundred and ---"
where US English doesn't. At one time British English defined
1 million = 10^6, 1 billion = 10^12, 1 trillion = 10^18, etc,
but now just about everyone in the UK uses the US convention that
1 thousand = 10^3, 1 million = 10^6, 1 billion = 10^9, 1 trillion = 10^12, etc.
There might be some minor differences in hyphenation or something, but
that's basically it.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Pascal Bourguignon wrote:
>
> [various other people:]
> > > > six hundred sixty-nine million, one hundred fifty-five thousand, three
> > > > hundred eighty-six and three tenths
> > >
> > > That's true in US English. It's not true in British English.
> > > In the absence of a clear indication of which variety of English
> > > Pascal was intending to write, it's not reasonable to dismiss
> > > what he wrote as "wrong".
>
> [Pascal:]
> > I don't know, what are the difference in English and US numbers? But
> > it does not matter, at least lisp ~R is consistent and it parsed the
> > numbers and formated the output in the same language.
>
> British English puts an "and" in the construction "--- hundred and ---"
> where US English doesn't. At one time British English defined
> 1 million = 10^6, 1 billion = 10^12, 1 trillion = 10^18, etc,
> but now just about everyone in the UK uses the US convention that
> 1 thousand = 10^3, 1 million = 10^6, 1 billion = 10^9, 1 trillion =
> 10^12, etc.
> There might be some minor differences in hyphenation or something, but
> that's basically it.
Good. CLHS says:
http://www.lispworks.com/reference/HyperSpec/Body/22_cba.htm
22.3.2.1 Tilde R: Radix
~nR prints arg in radix n. The modifier flags and any remaining
parameters are used as for the ~D directive. ~D is the same as
~10R. The full form is
~radix,mincol,padchar,commachar,comma-intervalR.
If no prefix parameters are given to ~R, then a different
interpretation is given. The argument should be an integer. For
example, if arg is 4:
* ~R prints arg as a cardinal English number: four.
* ~:R prints arg as an ordinal English number: fourth.
* ·@R prints arg as a Roman numeral: IV.
* ··@R prints arg as an old Roman numeral: IIII.
Did it means that any kind of English is good, or should Oxford
English be used or New York English or Canberra English?
Clisp sounds schizophrenic:
[15]> (format t "~R~%" 1000000110)
one billion, one hundred and ten
NIL
or really up to date if really England usage now is to use billion for 1e9.
SBCL, cmucl and openmcl sound American:
* (format t "~R~%" 1000000110)
one billion one hundred ten
NIL
Perhaps of just refering to "English number" it should have specified
explicitely the rules to generate the string from the numbers?
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Gareth McCaughan <················@pobox.com> wrote in message news:<··············@g.mccaughan.ntlworld.com>...
> Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
>
> > In article <··············@thalassa.informatimago.com>,
> > Pascal Bourguignon <····@thalassa.informatimago.com> wrote:
> >
> >> "six hundred and sixty-nine million, one hundred and fifty-five thousand,
> >> three hundred and eighty-six"
> >
> > FWIW, the above output is wrong - "and" should only be used between the
> > whole number and fractional parts, e.g.
> >
> > six hundred sixty-nine million, one hundred fifty-five thousand, three
> > hundred eighty-six and three tenths
>
> That's true in US English. It's not true in British English.
> In the absence of a clear indication of which variety of English
> Pascal was intending to write, it's not reasonable to dismiss
> what he wrote as "wrong".
There is no "absence of a clear indication of which variety of English
Pascal was intending to write." His code uses ~r. See:
<http://www.google.com/groups?selm=87y8vuyrgi.fsf%40thalassa.informatimago.com&oe=UTF-8&output=gplain>
We're talking about ANSI Common Lisp. These US centric conventions are
only to be expected - the "A" in ANSI is for "American" after all, and
ANSI's "mission is to enhance both the global competitiveness of U.S.
business and the U.S. quality of life by promoting and facilitating
voluntary consensus standards and conformity assessment systems, and
safeguarding their integrity."
That quote makes me sound rather jingoistic (FWIW I'm not - I oppose
the Bush manufactured war in Iraq for example) but this is simply a
matter of portability and standard conformance. Pascal's code is
broken under a strictly conforming implementation since the input
string will never be string-equal to that generated by the do loop
when the input string is greater than 99 in US English (as one would
expect with *ANSI* Common Lisp) and the implementation outputs UK
English for ~r directives.
It makes little sense for a format directive in the ANSI standard to
use UK English for formatting integers to words.
So this is not really Pascal's fault- I think his implementation is
non conforming. Under sbcl, or OpenMCL, I get no "and" between whole
number groups. Under clisp, and LispWorks however, I do, so I conclude
that he is using an implementation that is non conforming in this
respect.
Execute this:
(format t "~r" '123456789)
and you'll know whether your implementation gets this right or not.
raf
Raffael Cavallaro wrote:
[I said:]
>> That's true in US English. It's not true in British English.
>> In the absence of a clear indication of which variety of English
>> Pascal was intending to write, it's not reasonable to dismiss
>> what he wrote as "wrong".
>
> There is no "absence of a clear indication of which variety of English
> Pascal was intending to write." His code uses ~r. See:
> <http://www.google.com/groups?selm=87y8vuyrgi.fsf%40thalassa.informatimago.com&oe=UTF-8&output=gplain>
>
> We're talking about ANSI Common Lisp. These US centric conventions are
> only to be expected - the "A" in ANSI is for "American" after all, and
> ANSI's "mission is to enhance both the global competitiveness of U.S.
> business and the U.S. quality of life by promoting and facilitating
> voluntary consensus standards and conformity assessment systems, and
> safeguarding their integrity."
...
> It makes little sense for a format directive in the ANSI standard to
> use UK English for formatting integers to words.
The ANSI standard does not mandate that ~R produce output in
US English rather than British English. You might as well
argue that CLISP is non-conformant because it displays a
menorah at startup and the menorah is a Jewish rather than
an American symbol.
(Note: There was a lengthy thread about whether it's
a Bad Thing that CLISP displays a menorah, earlier this
year; let's not revisit that. I hope you agree that it's
clearly not a violation of conformance.)
The standard is, in fact, very unspecific about just what ~R
should do with large numbers. I can only assume that it's
deliberately so. CLTL2 (of interest as a historical document,
at least) goes into a bit more detail, indicating that its
author did not consider that there is only one right way for
~R to render numbers in "English" and did consider it worth
not ignoring British English when deciding what conventions
to use.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> wrote in message news:<··············@g.mccaughan.ntlworld.com>...
> The ANSI standard does not mandate that ~R produce output in
> US English rather than British English.
<sarcasm>It doesn't specifically exclude 1337 sp34k either, so I guess
that would be conforming as well.</sarcasm>
Again, it is just bizarre to assume that the format conventions in the
ANSI standard should be UK English, and not US English, since ANSI is
a US standards body.
> You might as well
> argue that CLISP is non-conformant because it displays a
> menorah at startup and the menorah is a Jewish rather than
> an American symbol.
So you hope here to associate me with the anti-Semites who posted to
that thread? I avoided that one intentionally, but as far as I'm
concerned, the maintainers of clisp have every right to print whatever
welcome banner they want - they could even print quotations from the
Torah in Hebrew, or access your sound card and start playing havah
nagilah if they like. They have graciously provided an extremely
portable common lisp implementation for free (in both senses), so I am
merely grateful to them, whatever welcome banner they choose to
present.
I do however believe that US English for ~r format directives would be
more conforming than their current use of UK English. Ditto LispWorks.
Raffael Cavallaro wrote:
[I said:]
>> The ANSI standard does not mandate that ~R produce output in
>> US English rather than British English.
>
> <sarcasm>It doesn't specifically exclude 1337 sp34k either, so I guess
> that would be conforming as well.</sarcasm>
Gosh, I'm glad you put that inside <sarcasm /> tags; I'd never
have noticed otherwise. If there's a serious point there, I'm
unable to work out what it is. (Unless you think that the variety
of English spoken and written in, um, England, is as far from
being correctly called "English" simpliciter as 1337 5p34k is.)
> Again, it is just bizarre to assume that the format conventions in the
> ANSI standard should be UK English, and not US English, since ANSI is
> a US standards body.
I didn't say that they *should be* UK English and not US English.
I said that they *may be* if the implementors choose it, at any
point where that is permitted by the standard.
I'll go further out on a limb and mention my shocking opinion
that it is not wrong for localized versions of CL implementations
to be produced, that generate (for instance) error messages in
a language other than English. Nor is it wrong for companies
not based in the US to make money out of selling CL implementations,
despite your astute observation that ANSI exists to further the
interests of US businesses.
Oh, sorry, should I have wrapped that in "<sarcasm>...</sarcasm>"?
>> You might as well
>> argue that CLISP is non-conformant because it displays a
>> menorah at startup and the menorah is a Jewish rather than
>> an American symbol.
>
> So you hope here to associate me with the anti-Semites who posted to
> that thread?
No: I have absolutely no such intention. (Nor, for the record,
do I think that wishing CLISP didn't display a menorah at
startup implies anti-semitism.)
> I avoided that one intentionally, but as far as I'm
> concerned, the maintainers of clisp have every right to print whatever
> welcome banner they want - they could even print quotations from the
> Torah in Hebrew, or access your sound card and start playing havah
> nagilah if they like. They have graciously provided an extremely
> portable common lisp implementation for free (in both senses), so I am
> merely grateful to them, whatever welcome banner they choose to
> present.
Good; we are agreed.
> I do however believe that US English for ~r format directives would be
> more conforming than their current use of UK English. Ditto LispWorks.
I think you are using "conforming" in a very strange sense.
--
Gareth McCaughan
.sig under construc
From: Nils Goesche
Subject: Re: Integer with base preserved!
Date:
Message-ID: <lyfze6iibk.fsf@cartan.de>
Gareth McCaughan <················@pobox.com> writes:
> The ANSI standard does not mandate that ~R produce output in US
> English rather than British English. You might as well argue that
> CLISP is non-conformant because it displays a menorah at startup and
> the menorah is a Jewish rather than an American symbol.
Who knows -- if the ANSI Standard was written by good Christians,
there would be 12 special operators, not 25, of course.
Identifying, excruciating and bonfiring the Satanic Special Operators
is left as an exercise for the Schemers.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
From: Joe Marshall
Subject: Re: Integer with base preserved!
Date:
Message-ID: <zncepe1y.fsf@ccs.neu.edu>
Nils Goesche <······@cartan.de> writes:
> Who knows -- if the ANSI Standard was written by good Christians,
> there would be 12 special operators, not 25, of course.
>
> Identifying, excruciating and bonfiring the Satanic Special Operators
> is left as an exercise for the Schemers.
I wasn't expecting the Spanish Inquisition....
From: Nils Goesche
Subject: Re: Integer with base preserved!
Date:
Message-ID: <lybrouii6g.fsf@cartan.de>
I wrote:
> Who knows -- if the ANSI Standard was written by good Christians,
> there would be 12 special operators, not 25, of course.
>
> Identifying, excruciating and bonfiring the Satanic Special Operators
> is left as an exercise for the Schemers.
I think I have a proof that there are exactly 13 Satanic Special
Operators, but there is not enough room in a single USENET posting to
prove this.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Gareth McCaughan <················@pobox.com> writes:
> > It makes little sense for a format directive in the ANSI standard to
> > use UK English for formatting integers to words.
>
> The ANSI standard does not mandate that ~R produce output in
> US English rather than British English. You might as well
> argue that CLISP is non-conformant because it displays a
> menorah at startup and the menorah is a Jewish rather than
> an American symbol.
>
> (Note: There was a lengthy thread about whether it's
> a Bad Thing that CLISP displays a menorah, earlier this
> year; let's not revisit that. I hope you agree that it's
> clearly not a violation of conformance.)
>
> The standard is, in fact, very unspecific about just what ~R
> should do with large numbers. I can only assume that it's
> deliberately so. CLTL2 (of interest as a historical document,
> at least) goes into a bit more detail, indicating that its
> author did not consider that there is only one right way for
> ~R to render numbers in "English" and did consider it worth
> not ignoring British English when deciding what conventions
> to use.
It would have been neat if conforming lisps would have been allowed to
use as output language for the ~R directive the i18n-specified
language for that platform, eg on Unix it would use language
information from the LC_*/LANG environment variables. Sadly, such an
extension would be non-conforming though, since the standard
explicitly mentions English. :-(
Bj�rn
·······@nada.kth.se (Bj�rn Lindberg) writes:
> Gareth McCaughan <················@pobox.com> writes:
>
> > > It makes little sense for a format directive in the ANSI standard to
> > > use UK English for formatting integers to words.
> >
> > The ANSI standard does not mandate that ~R produce output in
> > US English rather than British English. You might as well
> > argue that CLISP is non-conformant because it displays a
> > menorah at startup and the menorah is a Jewish rather than
> > an American symbol.
> >
> > (Note: There was a lengthy thread about whether it's
> > a Bad Thing that CLISP displays a menorah, earlier this
> > year; let's not revisit that. I hope you agree that it's
> > clearly not a violation of conformance.)
> >
> > The standard is, in fact, very unspecific about just what ~R
> > should do with large numbers. I can only assume that it's
> > deliberately so. CLTL2 (of interest as a historical document,
> > at least) goes into a bit more detail, indicating that its
> > author did not consider that there is only one right way for
> > ~R to render numbers in "English" and did consider it worth
> > not ignoring British English when deciding what conventions
> > to use.
>
> It would have been neat if conforming lisps would have been allowed to
> use as output language for the ~R directive the i18n-specified
> language for that platform, eg on Unix it would use language
> information from the LC_*/LANG environment variables. Sadly, such an
> extension would be non-conforming though, since the standard
> explicitly mentions English. :-(
Ah, there's a loophole--*English* doesn't have a standard!
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Bj�rn Lindberg wrote:
[I said:]
> > The standard is, in fact, very unspecific about just what ~R
> > should do with large numbers. I can only assume that it's
> > deliberately so. CLTL2 (of interest as a historical document,
> > at least) goes into a bit more detail, indicating that its
> > author did not consider that there is only one right way for
> > ~R to render numbers in "English" and did consider it worth
> > not ignoring British English when deciding what conventions
> > to use.
[Bj�rn:]
> It would have been neat if conforming lisps would have been allowed to
> use as output language for the ~R directive the i18n-specified
> language for that platform, eg on Unix it would use language
> information from the LC_*/LANG environment variables. Sadly, such an
> extension would be non-conforming though, since the standard
> explicitly mentions English. :-(
Yep. But I think it might be allowable to have a special
mode in which ~R uses the local language. Just make sure
it's triggered by something whose effects are explicitly
undefined by the standard :-).
--
Gareth McCaughan
.sig under construc
* Bj�rn Lindberg
| It would have been neat if conforming lisps would have been allowed to
| use as output language for the ~R directive the i18n-specified
| language for that platform, eg on Unix it would use language
| information from the LC_*/LANG environment variables.
Focusing only on the ~R is myopic. How about ~P?
I am opposed to the whole localization and internationalization mess,
as it is done at the wrong level. Instead of making programs use some
strings instead of some other strings, the properly language-oriented
approach uses a /protocol/ that results in improved user interaction
when the user interface module communicates with the user. If this
protocol was properly written and published, and I do /not/ mean APIs,
users could write their own user interaction modules and could run the
software and the user agent on different computers if they wanted to.
The WWW could have offered this separation, but the promise of Java
was never realized on the client side and today's user interaction is
still controlled almost entirely by the server. In order to design
protocols that it is possible to interact with, programmers need to
think in very different terms from designing the user interaction as
part of the application, and not having to do this is the lure of the
string-replacing method. It is all very depressing that programming
has never evolved as a discipline that could keep the user interface
out of the application �logic�, for these days, there is almost no
real software development since everybody are working on irrelevant
parts of the application.
--
Erik Naggum | Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
From: Christopher C. Stacy
Subject: Re: Integer with base preserved!
Date:
Message-ID: <ud699wqa4.fsf@news.dtpq.com>
>>>>> On 24 Jan 2004 08:16:40 +0000, Erik Naggum ("Erik") writes:
Erik> Instead of making programs use some strings instead of some
Erik> other strings, the properly language-oriented approach uses a
Erik> /protocol/ that results in improved user interaction when the
Erik> user interface module communicates with the user. If this
Erik> protocol was properly written and published, and I do /not/
Erik> mean APIs, users could write their own user interaction
Erik> modules and could run the software and the user agent on
Erik> different computers if they wanted to.
Erik> It is all very depressing that programming has never evolved
Erik> as a discipline that could keep the user interface out of the
Erik> application �logic�, for these days
This is, in a general sense, the kind of problem that
the presentation system of CLIM is supposed to be about.
Rather than the main application programmer writing
(format t "~&~R lossage~:P" n-lossages)
he would instead define a LOSSAGE presentation type.
Then the GUI programmer would write the PRESENT methods,
multi-dispatched on the LOSSAGE class and a LOCALE.
However, that's not really how most CLIM (or DW) code that I've seen
was written. Graphical based presentations are like that, but things
about text were not abstracted as far.
Gareth McCaughan <················@pobox.com> writes:
> Raffael Cavallaro wrote:
>
> [I said:]
> >> That's true in US English. It's not true in British English.
> >> In the absence of a clear indication of which variety of English
> >> Pascal was intending to write, it's not reasonable to dismiss
> >> what he wrote as "wrong".
> >
> > There is no "absence of a clear indication of which variety of English
> > Pascal was intending to write." His code uses ~r. See:
> > <http://www.google.com/groups?selm=87y8vuyrgi.fsf%40thalassa.informatimago.com&oe=UTF-8&output=gplain>
> >
> > We're talking about ANSI Common Lisp. These US centric conventions are
> > only to be expected - the "A" in ANSI is for "American" after all, and
> > ANSI's "mission is to enhance both the global competitiveness of U.S.
> > business and the U.S. quality of life by promoting and facilitating
> > voluntary consensus standards and conformity assessment systems, and
> > safeguarding their integrity."
No jingoism, that's just what standards are about. :-)
> ...
> > It makes little sense for a format directive in the ANSI standard to
> > use UK English for formatting integers to words.
I understand it so.
> The ANSI standard does not mandate that ~R produce output in
> US English rather than British English. You might as well
> argue that CLISP is non-conformant because it displays a
> menorah at startup and the menorah is a Jewish rather than
> an American symbol.
>
> (Note: There was a lengthy thread about whether it's
> a Bad Thing that CLISP displays a menorah, earlier this
> year; let's not revisit that. I hope you agree that it's
> clearly not a violation of conformance.)
>
> The standard is, in fact, very unspecific about just what ~R
> should do with large numbers. I can only assume that it's
> deliberately so. CLTL2 (of interest as a historical document,
> at least) goes into a bit more detail, indicating that its
> author did not consider that there is only one right way for
> ~R to render numbers in "English" and did consider it worth
> not ignoring British English when deciding what conventions
> to use.
In that case, they should have specified "human language" and
localization, and stuff like that. (I'd be happy to be able to setf
some global variable to get "un billion" for 1e12). Since they did
not, I would interpret it to be requiring strict American English
output. (And indeed clisp, being of European origin uses wrongly a mix
of American and British English here).
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Gareth McCaughan <················@pobox.com> writes:
> Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
>> FWIW, the above output is wrong - "and" should only be used between the
>> whole number and fractional parts, e.g.
> That's true in US English. It's not true in British English.
FWIW, it's not even universally accepted in US English. School
teachers in some areas (at some times) pushed it strongly, others
don't care.
--
Alan Shutko <···@acm.org> - I am the rocks.
Before the Borg, there were the fundies.
Alan Shutko <···@acm.org> writes:
> Gareth McCaughan <················@pobox.com> writes:
>
> > Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
>
> >> FWIW, the above output is wrong - "and" should only be used between the
> >> whole number and fractional parts, e.g.
>
> > That's true in US English. It's not true in British English.
>
> FWIW, it's not even universally accepted in US English. School
> teachers in some areas (at some times) pushed it strongly, others
> don't care.
Why did they not specify French? At least, in France we have
normalizing organizations that edict formal rules to write numbers
unequivocally (and units too), and these rules are official and
published in the Journal Officiel (where all French Laws have to be
published to be appliable).
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Joseph Oswald skribis:
[...]
> I'm not sure what the smiley faces were about, but Lisp does not
[...]
I think that the smiley faces were because "Kaz Kylheku"'s post is a
(humorous) parody of a recent post titled "symbol name with case
preserved".
Kaz Kylheku wrote:
> Hi, I don't have a clue here. I understand that Lisp is not a
> base-sensitive language; it turns everything into base 10. When I
> enter an integer as #xFF, later it prints as 255! Is there a function
> like:
>
> (original-number value)
>
> that, given a number, will retrieve the original hex number?
>
> :) :) :) :)
Is this a trick question, whose answer is "RTFM *PRINT-BASE*"? :)
Cheers
--
Marco