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.
>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 :)
* 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...
* 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.
