Below is simple usage of dispatch macro character
(eval-when (:compile-toplevel :execute)
(defun |#!-reader| (stream char arg)
(declare (ignore char arg))
(ecase (char-upcase (read-char stream t nil t))
(#\K (* 1024 (read stream t nil t)))
(#\M (* 1024 1024 (read stream t nil t)))
(#\G (* 1024 1024 1024 (read stream t nil t)))))
(set-dispatch-macro-character #\# #\! #'|#!-reader|)
)
(defun |test-#!-reader| ()
(list #!k1 #!m1 #!g1))
I didn't put :load-toplevel in EVAL-WHEN situations' list
because I can't imagine when or where it could be used. When
file is being compiled all used #! will be converted to numbers,
so no work left to be done at load time. Contrary, if file is
being loaded as source all job also should be done, because
:execute specified in EVAL-WHEN situations' list.
Is my assumptions true ?
Someone might call this 'trifle'. 'Put :load-toplevel just in case' he
might say. I have some model of the involved processes in my mind (I'm
suppose that anyone has the 'model' though much more complete than mine).
How can I prove it ? Practising, reading textbooks and asking when
there are nothing to read or no obvious ways of testing it just as in
this case.
--
Vladimir Zolotykh
On Wed, 26 Jun 2002 15:30:28 +0300, Vladimir Zolotykh <······@eurocom.od.ua>
wrote:
>Below is simple usage of dispatch macro character
>
>(eval-when (:compile-toplevel :execute)
>
>(defun |#!-reader| (stream char arg)
> (declare (ignore char arg))
> (ecase (char-upcase (read-char stream t nil t))
> (#\K (* 1024 (read stream t nil t)))
> (#\M (* 1024 1024 (read stream t nil t)))
> (#\G (* 1024 1024 1024 (read stream t nil t)))))
>
>(set-dispatch-macro-character #\# #\! #'|#!-reader|)
>)
>
>(defun |test-#!-reader| ()
> (list #!k1 #!m1 #!g1))
>
>I didn't put :load-toplevel in EVAL-WHEN situations' list
>because I can't imagine when or where it could be used. When
>file is being compiled all used #! will be converted to numbers,
>so no work left to be done at load time. Contrary, if file is
>being loaded as source all job also should be done, because
>:execute specified in EVAL-WHEN situations' list.
>
>Is my assumptions true ?
It's true as far as it goes, but if you later load the compiled file
into a fresh Lisp the reader macro won't be available. You'll care
about this as soon as you try to interactively modify a definition
that uses the reader macro :)
This use of eval-when is a very common pattern: make something
available at compile time that otherwise would not be. In general you
shouldn't leave :load-toplevel out of the eval-when times unless
you're making a very conscious decision to have different compile-time
and load-time behaviors.
>Someone might call this 'trifle'. 'Put :load-toplevel just in case' he
>might say. I have some model of the involved processes in my mind (I'm
>suppose that anyone has the 'model' though much more complete than mine).
>How can I prove it ? Practising, reading textbooks and asking when
>there are nothing to read or no obvious ways of testing it just as in
>this case.
Ask an SBCL developer sometime about source reader syntax that isn't
readable by the default runtime system :)
Tim
* Vladimir Zolotykh
| Below is simple usage of dispatch macro character
:
| (defun |#!-reader| (stream char arg)
| (declare (ignore char arg))
| (ecase (char-upcase (read-char stream t nil t))
| (#\K (* 1024 (read stream t nil t)))
| (#\M (* 1024 1024 (read stream t nil t)))
| (#\G (* 1024 1024 1024 (read stream t nil t)))))
Please take a look at what this "arg" you ignore really is and how the reader
already provides a value that you might find particularly useful.
_Please_ note that this is a bad use of a case-insensitive characters. E.g.,
light travels at approximately 300 Mm/s, which is _way_ faster than 300 mm/s,
which is about the speed at which my randomly waving hand usually hits the
light switch in the morning. On the even lighter side, some broadband
company over here recently advertised 2 mbps residential rate. At last, some
truth in Internet advertising!
At any rate, it would have been better to use ((#\k #\K) ...) than to call
char-upcase.
Please also note that "k" is the ISO prefix for 1000, "K" is not, but has
been used for 1024. "M" is 1,000,000, "G" is 1,000,000,000, "m" is 1/1000.
An enterprising brainslug has suggested that to solve this non-problem, we
should write 1 kiB for 1024 bytes, 2 MiB for the recently released sequel,
and 4 GiB for what was previously just known as 2��. Some Linux freaks have
not seen through this stunt and so the Linux kernel and many GNU utilities
use this silliness. I would much have preferred a notation like 1B3, like
1E3, such that in 1Bn, n equal to 3/10 of base 2 logarithm of the exponent.
Of course, this might be confusing to some people who are unfamiliar with the
common "engineering notation" that underlies the ISO prefix system to begin
with (but such people should be ignored, anyway). In any case, I bet it
looks less unfamiliar than this horrible XiB notation. (Nobody would use it
for anything other than "binary amounts", anyway, and that is just "nerdy"
enough that an engineering-based notation should be acceptable.)
--
Guide to non-spammers: If you want to send me a business proposal, please be
specific and do not put "business proposal" in the Subject header. If it is
urgent, do not use the word "urgent". If you need an immediate answer, give
me a reason, do not shout "for your immediate attention". Thank you.
Erik Naggum wrote:
> An enterprising brainslug has suggested that to solve this
> non-problem, we should write 1 kiB for 1024 bytes, 2 MiB for the
> recently released sequel,
> and 4 GiB for what was previously just known as 2��.
Apparently already an IEC standard, draft IEEE and proposed to ISO...
See
http://grouper.ieee.org/groups/260/1/
http://physics.nist.gov/cuu/Units/binary.html
http://www.cofc.edu/~frysingj/binprefixes.html
--
Don't eat yellow snow.
* David Golden
| Apparently already an IEC standard, draft IEEE and proposed to ISO...
Well, the interesting thing about standards is that if you need to do
something to which they prescribe a solution, you should do it that way
unless you and your partners agree to something else. Standards in a given
area should be considered for applicability before anything else, but if they
turn out to be nuts, like MOTIS, OSI, ODA, etc, people should have no qualms
about leaving them behind to do something better. However, this should not
be the first thing you reach for.
So I think I shall henceforth have to write these things out more explicitly.
--
Guide to non-spammers: If you want to send me a business proposal, please be
specific and do not put "business proposal" in the Subject header. If it is
urgent, do not use the word "urgent". If you need an immediate answer, give
me a reason, do not shout "for your immediate attention". Thank you.
Erik Naggum wrote:
>
> Please take a look at what this "arg" you ignore really is and how the reader
> already provides a value that you might find particularly useful.
You're right. I also had conjectured to use #256!K instead of #!K256 for that.
--
Vladimir Zolotykh