Beginner question: performance problems with a simple program
Janosch Zwerensky
I've just started learning Common Lisp and as a simple exercise of what I've
learned so far I thought I might write a program that allows one to play around
a bit with Collatz sequences.
I thus produced the following program:
(defun coll-step (n)
(if (= (mod n 2) 0) (/ n 2) (+ 1 (* 3 n))))
(defun coll-max (n)
"Computes the maximum of the collatz sequence starting with its argument"
(coll-max-iter n n n))
(defun coll-max-iter (n a b)
(if (< n a) b (coll-max-iter (coll-step n) a (max b n))))
(defun max-lst (n)
"prints out all n up to its argument which have the property that
coll-max(m)>=coll-max(n) ==> m >= n"
(max-lst-iter 3 n (coll-max 3)))
(defun max-lst-iter (n range mx)
(if (> n range) mx
(max-lst-iter (+ n 4) range (next n (coll-max n) mx))))
(defun next (n am mx)
(if (> am mx) (toscreen n am) mx))
(defun toscreen (n am)
(write (list n am))
am)
The program works fine, except for the fact that I am not feeling well about
its performance speed-wise. Does anyone on this group have any tips to offer
regarding improvements in this respect? (I am working with Allegro Common
Lisp).
Regards,
Janosch.
Barry Margolin
Janosch Zwerensky <zwer...@nahoo.de> wrote:
>Hi all,
>
>I've just started learning Common Lisp and as a simple exercise of what I've
>learned so far I thought I might write a program that allows one to play around
>a bit with Collatz sequences.
>I thus produced the following program:
>
>(defun coll-step (n)
> (if (= (mod n 2) 0) (/ n 2) (+ 1 (* 3 n))))
Why not use EVENP here?
>The program works fine, except for the fact that I am not feeling well about
>its performance speed-wise. Does anyone on this group have any tips to offer
>regarding improvements in this respect? (I am working with Allegro Common
>Lisp).
Did you remember to compile it?
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Janosch Zwerensky
>>(defun coll-step (n)
>> (if (= (mod n 2) 0) (/ n 2) (+ 1 (* 3 n))))
>
>Why not use EVENP here?
Using evenp here doesn't hurt nor help, performancewise, here. I agree though
that evenp looks more natural.
>Did you remember to compile it?
Of course I did. I might have little experience with lisp so far, but I am not
stupid. Still, the program seems to be around 10 times slower than an
algorithmically equivalent C program, which is a larger speed loss than what I
would have expected just from Lisp doing BigInteger arithmetics vs. the long
long int calculations one does in C.
Regards,
Janosch.
Barry Margolin
Janosch Zwerensky <zwer...@nahoo.de> wrote:
>Hi,
>
>>>(defun coll-step (n)
>>> (if (= (mod n 2) 0) (/ n 2) (+ 1 (* 3 n))))
>>
>>Why not use EVENP here?
>
>Using evenp here doesn't hurt nor help, performancewise, here. I agree though
>that evenp looks more natural.
I didn't think it would, it was just a style comment.
>>Did you remember to compile it?
>
>Of course I did. I might have little experience with lisp so far, but I am not
>stupid.
I never said you were. There have been plenty of times when people posted
questions about performance and it turned out that they weren't compiling,
so most of the problem was in the interpreter's overhead. It's not
stupidity, just inexperience.
> Still, the program seems to be around 10 times slower than an
>algorithmically equivalent C program, which is a larger speed loss than what I
>would have expected just from Lisp doing BigInteger arithmetics vs. the long
>long int calculations one does in C.
Declarations can often help with heavily numeric code. Without them, lots
of runtime type dispatching has to take place. Although if you can't limit
your numbers to fixnums, it may still have to do type checks to switch
between fixnum and bignum versions of functions.
Try using the TIME macro to see if you're consing alot. If your Lisp
implementation has a profiling feature, try using that to see where the
bottleneck is.
Will Fitzgerald
to post respectfully & irenically. Thanks, Barry for your fine example.
Will Fitzgerald
"Barry Margolin" <bar...@genuity.net> wrote in message
news:36sW7.19$Mv6.41773@burlma1-snr2...
David Sletten
> What's the opposite of a flame? Barry Margolin once again demonstrates how
> to post respectfully & irenically. Thanks, Barry for your fine example.
>
> Will Fitzgerald
>
Would that be a 'douse'? Or is it 'Preparation H' to prevent a
hemorrhoid from flaring up?
David Sletten
Janosch Zwerensky
>(...) There have been plenty of times when people posted
>questions about performance and it turned out that they weren't compiling,
>so most of the problem was in the interpreter's overhead.
Ok, I didn't know that.
Call it, uhm, inexperience regarding this newsgroup ;).
>
>> Still, the program seems to be around 10 times slower than an
>>algorithmically equivalent C program, which is a larger speed loss than what
I
>>would have expected just from Lisp doing BigInteger arithmetics vs. the long
>>long int calculations one does in C.
>
>Declarations can often help with heavily numeric code.
I know this, since I have done programming in Scheme before.
I assume, then, that I can't do much about the performance of my program if
Lisp doesn't have a number type that suits my problem better than general
bignums (it is my understanding that this was the case in MIT-Scheme)?
>(...) Although if you can't limit
>your numbers to fixnums,
Exactly my problem :(.
> it may still have to do type checks to switch
>between fixnum and bignum versions of functions.
>
>Try using the TIME macro to see if you're consing alot. If your Lisp
>implementation has a profiling feature, try using that to see where the
>bottleneck is.
I think I know where the bottleneck is anyway, but I'll nonetheless follow that
advice.
Regards,
Janosch.
cbbr...@acm.org
> >>(defun coll-step (n)
> >> (if (= (mod n 2) 0) (/ n 2) (+ 1 (* 3 n))))
> >
> >Why not use EVENP here?
>
> Using evenp here doesn't hurt nor help, performancewise, here. I agree though
> that evenp looks more natural.
>
> >Did you remember to compile it?
> Of course I did. I might have little experience with lisp so far,
> but I am not stupid.
Can you tell a bit more about what you did to accomplish this? I'm
not usually considered stupid, either, but have made the mistake of
_believing_ I was running a compiled copy, when reality was that I
wasn't...
Some mistakes are regrettably easy to make, and if you think I'm
calling you "stupid," the moniker would have to apply just as much to
myself...
> Still, the program seems to be around 10 times slower than an
> algorithmically equivalent C program, which is a larger speed loss
> than what I would have expected just from Lisp doing BigInteger
> arithmetics vs. the long long int calculations one does in C.
I'd hope for a smaller factor than 10 for this, though I'd not expect
1...
--
(concatenate 'string "cbbrowne" "@acm.org")
http://www.ntlug.org/~cbbrowne/x.html
"It's a pretty rare beginner who isn't clueless. If beginners weren't
clueless, the infamous Unix learning cliff wouldn't be a problem."
-- david parsons
Erik Naggum
| The program works fine, except for the fact that I am not feeling well
| about its performance speed-wise. Does anyone on this group have any
| tips to offer regarding improvements in this respect? (I am working with
| Allegro Common Lisp).
Evaluate (excl::explain-compiler-settings) and turn on the various
:explain options. The amount of output even exceeds CMUCL at its worst,
but it can be very helpful in realizing when and how to declare stuff.
What were the types of variables in the C version? How much time does a
function call usually take? Do you have an example?
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
Janosch Zwerensky
>Can you tell a bit more about what you did to accomplish this? I'm
>not usually considered stupid, either, but have made the mistake of
>_believing_ I was running a compiled copy, when reality was that I
>wasn't.
If you're saying here that ACL doesn't necessarily compile a lisp program
when one tells it to do just that, I *might* be guilty of having done such a
mistake. I wouldn't be sad if that were the case, since I'd probably get a
good performance boost then by finally doing a compilation ;).
Still, my lisp read-eval-print-loop says the functions I'm loading are
compiled functions indeed.
..
>
>Some mistakes are regrettably easy to make, and if you think I'm
>calling you "stupid," the moniker would have to apply just as much to
>myself...
I agree it was stupid of me to use the word "stupid" in that context.
>I'd hope for a smaller factor than 10 for this, though I'd not expect
>1...
The really bad thing is that this factor of ten seems to go up when you
increase the values given to max-lst. Probably I'm doing something badly
wrong thus.. :(
Regards,
Janosch.
Janosch Zwerensky
> (...)
> What were the types of variables in the C version? How much time does a
> function call usually take? Do you have an example?
First, here's the C program I used:
#include <stdio.h>
int main(void)
{ long int nmax=0;
int new_max = 0;
long long a, amax = 0;
scanf("%d",&nmax);
for (int n = 3; n <= nmax; n=n+4)
{
a = n;
while (a >= n)
{
if (a&1)
{
a = 3*a + 1;
if (a > amax)
{
amax = a;
if (!new_max) new_max = 1;
}
}
else
{
a = a >> 1;
}
}
if (new_max)
{
new_max = 0;
printf("%d : %e\n", n, (double) amax);
}
}
return 0;
}
On my machine and compiled with lcc-win32, this takes around 0.6 seconds to do
the equivalent of evaluating max-lst(1000000), which in turn takes just under 6
seconds on my machine under allegro common lisp. The number type I'm using in C
is long long, which happens to go just high enough for this application and
reasonable input values.
Regards,
Janosch.
Barry Margolin
Janosch Zwerensky <zwer...@nahoo.de> wrote:
>Hi,
>
>> (...)
>> What were the types of variables in the C version? How much time does a
>> function call usually take? Do you have an example?
>
>First, here's the C program I used:
What happens if you do a more straight-forward translation into Lisp,
i.e. use iteration rather than recursion? Or what happens if you recode
the C program to use lots of separate functions and recursion, rather than
a single function with iteration?
If the recursion gets very deep, you could be taking more page faults on
the stack. Iterative solutions don't have this problem. Are you assuming
tail-recursion elimination in the Lisp version? Lisp isn't Scheme, and
many Lisp implementations don't do tail-call optimization, or they only do
them with specific optimization settings enabled.
>On my machine and compiled with lcc-win32, this takes around 0.6 seconds to do
>the equivalent of evaluating max-lst(1000000), which in turn takes just under 6
>seconds on my machine under allegro common lisp. The number type I'm using in C
>is long long, which happens to go just high enough for this application and
>reasonable input values.
There's a big difference between C's long-long arithmetic and Lisp's bignum
arithmetic. Lisp has to be prepared for the values to get arbitrarily
large, so it has to use more general algorithms that can handle any
length. C can generate much simpler code because it knows exactly how many
bytes the long-long values take up. It's hard to avoid some extra overhead
from this generality, although a factor of 10 seems unlikely.
What happens if you change both programs to use double-precision floating
point?
Maybe it's a combination of the bignum arithmetic and the recursion
vs. iteration difference.
Thomas F. Burdick
> Hi,
>
> >(...) There have been plenty of times when people posted
> >questions about performance and it turned out that they weren't compiling,
> >so most of the problem was in the interpreter's overhead.
>
> Ok, I didn't know that.
> Call it, uhm, inexperience regarding this newsgroup ;).
>
> >
> >> Still, the program seems to be around 10 times slower than
> >>an algorithmically equivalent C program, which is a larger speed
> >>loss than what I would have expected just from Lisp doing
> >>BigInteger arithmetics vs. the long long int calculations one does
> >>in C.
> >
> >Declarations can often help with heavily numeric code.
>
> I know this, since I have done programming in Scheme before.
I don't remember Scheme having declarations.
> I assume, then, that I can't do much about the performance of my program if
> Lisp doesn't have a number type that suits my problem better than general
> bignums (it is my understanding that this was the case in MIT-Scheme)?
>
> >(...) Although if you can't limit
> >your numbers to fixnums,
>
> Exactly my problem :(.
If your calculation can be done without using a bignum-like facility
in your machine's assembly language, your Lisp implementation may be
able to do it without bignums. This is very implementation-dependant,
but then optimizing numerics is in any language. long long ints are
64-bit integers, right? Using block compilation, you should be able
to do what you want using CMUCL, I think. It might need some messing
with the compiler, but I think you should be able to do what you want
without bignums.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Janosch Zwerensky
>If the recursion gets very deep, you could be taking more page faults on
>the stack. Iterative solutions don't have this problem. Are you assuming
>tail-recursion elimination in the Lisp version?
Yes, I did assume that. If lisp doesn't do this here, I indeed ought to have a
problem. I will build a more iterative version of my lisp program and see if
and what happens :).
Thanks anyway for bringing up this point!
>There's a big difference between C's long-long arithmetic and Lisp's bignum
>arithmetic.
I'm aware of that and for that reason alone I wouldn't be surprised if Lisp
would be significantly slower for this problem than C. Still, a factor of ten
seemed (possibly) excessive to me if nothing else went wrong.
>
>What happens if you change both programs to use double-precision floating
>point?
I already tried it for the Lisp program, and it didn't help much,
performance-wise. Could it be the case that Lisp is converting those doubles to
bignums when doing the evenp test? If so, I could imagine that this might be
time-consuming.
Anyway, I will try to see what happens to the C program if I have it compute
with doubles.
Thanks again for all that input,
Janosch.
Thomas F. Burdick
> Hi,
>
> >If the recursion gets very deep, you could be taking more page faults on
> >the stack. Iterative solutions don't have this problem. Are you assuming
> >tail-recursion elimination in the Lisp version?
>
> Yes, I did assume that. If lisp doesn't do this here, I indeed ought
> to have a problem. I will build a more iterative version of my lisp
> program and see if and what happens :). Thanks anyway for bringing
> up this point!
>
> >There's a big difference between C's long-long arithmetic and Lisp's bignum
> >arithmetic.
>
> I'm aware of that and for that reason alone I wouldn't be surprised
> if Lisp would be significantly slower for this problem than
> C. Still, a factor of ten seemed (possibly) excessive to me if
> nothing else went wrong.
I'd expect a Lisp version to run very close to C, so, yes, this is
excessive.
> >What happens if you change both programs to use double-precision floating
> >point?
>
> I already tried it for the Lisp program, and it didn't help much,
> performance-wise. Could it be the case that Lisp is converting those
> doubles to bignums when doing the evenp test? If so, I could imagine
> that this might be time-consuming. Anyway, I will try to see what
> happens to the C program if I have it compute with doubles. Thanks
> again for all that input,
CL's evenp is only defined for integers, for obvious reasons (is
5.999999999 even?).
Anyway, I rewrote your program using LOOP and type declarations:
(defun iterative-max-list (range)
(declare (type (unsigned-byte 64) range))
(flet ((coll-max (a)
(loop for n of-type (unsigned-byte 64) = a
then (if (evenp n) (floor n 2) (1+ (* 3 n)))
for b of-type (unsigned-byte 64) = n then (max b n)
until (< n a)
finally (return (max b n)))))
(loop with max of-type (unsigned-byte 64) = (coll-max 3)
for n of-type (unsigned-byte 64) from 3 to range by 4
for am of-type (unsigned-byte 64) = max then (coll-max n)
when (> am max)
do (princ (list n am))
(setf max am)
finally (return max))))
I compiled both versions in CMUCL with
(optimize (speed 3) (safety 1) (compilation-speed 0) (space 0))
and your C version with gcc.
On my Celeron 500 under linux:
"echo 1000000 | ./max_list", compiled with gcc -O
Min: 0.273s
Max: 0.721s
Mean: 0.48250000000000004s
"echo 1000000 | ./max_list", compiled with gcc -O3
Min: 0.45s
Max: 0.628s
Mean: 0.5326s
(iterative-max-list 1000000)
Min: 0.84s
Max: 0.85s
Mean: 0.85s
(max-lst 1000000)
Min: 2.14s
Max: 2.17s
Mean: 2.17s
Each test was run 11 times, and only counted the last 10 runs. So,
counting only the best versions in C and Lisp:
Min: 311.11% of C
Max: 118.06% of C
Mean: 177.08% of C
It could be better, but it's not too bad. And certainly better than
1000% :-). Also, changing that type declaration to integer instead of
(unsigned-byte 64) runs at 150% of the long-long-equivalent version,
which is an option you don't have in C :-). Also, be sure to bind
*print-pretty* to nil when you run the Lisp version or it might spend
a lot of time formatting its output.
Janosch Zwerensky
>I don't remember Scheme having declarations.
MIT-Scheme allows one to declare a few things, although it isn't comparable to
CL in that respect. It does have, however, specialized operations for fixnums,
the use of which of course leads to big speedups when possible.
Regards,
Janosch
Janosch Zwerensky
I've written my own iterative version of my program in the meantime. It's not
nearly as fast as yours, because I didn't put in the appropriate declarations,
but it is significantly faster than my first try nonetheless.
On my machine and under Allegro Common Lisp, your code seems to be around 3.5
times slower than the C program. I guess the difference to your measurements
can be attributed to me having used another compiler than you; I probably ought
to finally get me Linux and CMUCL ;)...
Greetings,
Janosch Zwerensky.
Kaz Kylheku
>
>>I don't remember Scheme having declarations.
>
>MIT-Scheme allows one to declare a few things, although it isn't comparable to
>CL in that respect. It does have, however, specialized operations for fixnums,
MIT Scheme is not comparable to CL because it is an *implementation*,
whereas CL is an internationally standardized programming *language*.
Janosch Zwerensky
I've done a few minor changes on your program now, which seem to give a speedup
of an additional ten percent on my system :)... :
(defun iterative-max-list (range)
(declare (type (unsigned-byte 64) range))
(flet ((coll-max (a)
(let* ((b a))
(loop for n of-type (unsigned-byte 64) = a
then (if (evenp n) (floor n 2) (progn
(setf x (1+ (* 3
n)))
(setf b (max x b))
(floor x 2)))
for x of-type (unsigned-byte 64) = a
until (< n a)
finally (return (max b n))))))
(loop with max of-type (unsigned-byte 64) = (coll-max 3)
for n of-type (unsigned-byte 64) from 3 to range by 4
for am of-type (unsigned-byte 64) = max then (coll-max n)
when (> am max)
do (princ (list n am))
(setf max am)
finally (return max))))
I don't think that what I did here looks very elegant. If someone has something
better to offer, I'd be glad to see it.
Regards,
Janosch.
Dr. Edmund Weitz
I think the (FLOOR X 2) part isn't necessary (or even wrong), so it should be:
(defun iterative-max-list (range)
(declare (type (unsigned-byte 64) range))
(flet ((coll-max (a)
(let* ((b a))
(loop for n of-type (unsigned-byte 64) = a
then (if (evenp n)
(floor n 2)
(prog1
(setf x (1+ (* 3 n)))
(setf b (max x b))))
for x of-type (unsigned-byte 64) = a
until (< n a)
finally (return (max b n))))))
(loop with max of-type (unsigned-byte 64) = (coll-max 3)
for n of-type (unsigned-byte 64) from 3 to range by 4
for am of-type (unsigned-byte 64) = max then (coll-max n)
when (> am max)
do (princ (list n am))
(setf max am)
finally (return max))))
Edi.
Dr. Edmund Weitz
> I think the (FLOOR X 2) part isn't necessary (or even wrong), so it
> should be:
>
> (defun iterative-max-list (range)
> (declare (type (unsigned-byte 64) range))
> (flet ((coll-max (a)
> (let* ((b a))
> (loop for n of-type (unsigned-byte 64) = a
> then (if (evenp n)
> (floor n 2)
> (prog1
> (setf x (1+ (* 3 n)))
> (setf b (max x b))))
> for x of-type (unsigned-byte 64) = a
> until (< n a)
> finally (return (max b n))))))
> (loop with max of-type (unsigned-byte 64) = (coll-max 3)
> for n of-type (unsigned-byte 64) from 3 to range by 4
> for am of-type (unsigned-byte 64) = max then (coll-max n)
> when (> am max)
> do (princ (list n am))
> (setf max am)
> finally (return max))))
Or maybe
(defun iterative-max-list (range)
(declare (type (unsigned-byte 64) range))
(loop with max of-type (unsigned-byte 64) = 0
for a of-type (unsigned-byte 64) from 3 to range by 4
for am of-type (unsigned-byte 64) = max
then (let ((n a))
(declare (type (unsigned-byte 64) n))
(loop if (evenp n)
do (setq n (floor n 2))
else
maximize (setq n (1+ (* 3 n)))
until (< n a)))
when (> am max)
do (princ (list a
(setf max am)))
finally (return max)))
or, if you're only interested in the maximum value,
(defun iterative-max-list (range)
(declare (type (unsigned-byte 64) range))
(loop for a of-type (unsigned-byte 64) from 3 to range by 4
for am of-type (unsigned-byte 64) = 0
then (let ((n a))
(declare (type (unsigned-byte 64) n))
(loop if (evenp n)
do (setq n (floor n 2))
else
maximize (setq n (1+ (* 3 n)))
until (< n a)))
maximize am))
I have to add that I wasn't able to get ratios as good as Thomas
F. Burdick's on my machine (CMUCL 18c, P3 850, 256 MB RAM, Linux
2.4.10) - even with the same compilation options and with
*PRINT-PRETTY* set to NIL. The C program - compiled with -O3 - was
about 3 times as fast. If I compared the last version with a modified
C program that also only prints the final result it got even worse:
The C program was about 5 to 6 times as fast as CMUCL.
On the other hand, CMUCL was significantly faster than AllegroCL, ECL,
or LispWorks - which didn't surprise me very much...
Edi.
Thomas F. Burdick
BTW, when reading this, I just noticed that range and a are both
fixnums. Of course, that will probably only make a couple percent
difference.
> I have to add that I wasn't able to get ratios as good as Thomas
> F. Burdick's on my machine (CMUCL 18c, P3 850, 256 MB RAM, Linux
> 2.4.10) - even with the same compilation options and with
> *PRINT-PRETTY* set to NIL. The C program - compiled with -O3 - was
> about 3 times as fast. If I compared the last version with a modified
> C program that also only prints the final result it got even worse:
> The C program was about 5 to 6 times as fast as CMUCL.
For whatever reason, CMUCL seems to emit really good code (relative to
gcc) for my Celeron. I have no idea if CMUCL's code is for whatever
reason especially well optimized for Celerons or if gcc is especially
bad with them.
> On the other hand, CMUCL was significantly faster than AllegroCL, ECL,
> or LispWorks - which didn't surprise me very much...
Yeah, Python really shines when it goes to work on numeric code. If
it new how to open code a few operations on 64-bit words (say as a
pair of 32-bit words), it could probably do a lot better here.
Janosch Zwerensky
>I think the (FLOOR X 2) part isn't necessary (or even wrong), so it should be:
>
If n isn't even, x:=3n+1 must be an even number. Therefore, in this case I know
that I'm going to divide that number by two in the next step anyway and thus
doing it right away saves me an unnecessary evenp test.
Why do you think that I might have done something wrong here?
Regards,
Janosch.
Janosch Zwerensky
>I have to add that I wasn't able to get ratios as good as Thomas
>F. Burdick's on my machine (CMUCL 18c, P3 850, 256 MB RAM, Linux
>2.4.10) - even with the same compilation options and with
>*PRINT-PRETTY* set to NIL. The C program - compiled with -O3 - was
>about 3 times as fast.
with this version of the C program:
#include <stdio.h>
int main(void)
{ long int nmax=0;
int new_max = 0;
long long a, amax = 0;
nmax=1000000;
// scanf("%d",&nmax);
for (int n = 3; n <= nmax; n=n+4)
{
a = n;
while (a >= n)
{
if (a&1)
{
a = 3*a + 1;
if (a > amax)
{
amax = a;
if (!new_max) new_max = 1;
}
a=a >> 1; }
else
{
a = a >> 1;
}
}
if (new_max)
{
new_max = 0;
printf("%d : %e\n", n, (double) amax);
}
}
return 0;
}
compiled with lcc-win32, I get a ratio of just under five versus the version of
the lisp program I posted recently (I get a runtime of 0.5 seconds on my
machine for C vs. 2.35 seconds for Lisp).
What do you get here with CMUCL?
Regards,
Janosch.
Janosch Zwerensky
I just compared the two programs again, doing the equivalent of evaluating
(iterative-max-list 100000000) in both Lisp and C. I get runtimes of 746
seconds for Lisp versus 33.5 seconds for C, which is a 22:1 disadvantage for
Lisp :(...
Regards,
Janosch.
Dr. Edmund Weitz
Nothing wrong there. I just didn't think enough... :)
Edi.
Dr. Edmund Weitz
> with this version of the C program:
>
> [snip]
>
> compiled with lcc-win32, I get a ratio of just under five versus the
> version of the lisp program I posted recently (I get a runtime of
> 0.5 seconds on my machine for C vs. 2.35 seconds for Lisp). What do
> you get here with CMUCL?
All results are on a PIII 850, 256 MB RAM, Linux 2.4.10 with CMUCL
18c[1], gcc 2.95.3[2].
If I compare your C program above[3] vs. your earlier posted CMUCL
program I get
with an arg of 1,000,000: 0.12 (C) vs. 0.56 (CMUCL) secs
with an arg of 10,000,000: 0.9 (C) vs. 6.7 (CMUCL) secs
But enough Lisp bashing: It seems rather obvious to me that C wins
because it supports the 'long long' type while Lisp doesn't. This is a
nice feature and long longs can indeed get quite big, but there's
still a rather arbitrary upper limit. I think Collatz sequences are a
typical example where you really want unlimited precision arithmetic
and you want to keep your machine running for a couple of days.
I wrote a small C program[4] that uses the gmp library and changed my
earlier Lisp program by just removing the declarations[5]. The
results:
with an arg of 1,000,000: 1.6 (C) vs. 0.7 (CMUCL) secs
with an arg of 10,000,000: 12.3 (C) vs. 8.7 (CMUCL) secs
No I can sleep better... :)
DISCLAIMER: This was my first encounter with the gmp library. I hope I
haven't done anything completely inefficient and/or dumb.
Edi.
[1] with *PRETTY-PRINT* set to NIL and (OPTIMIZE (SPEED 3) (SAFETY 0)
(SPACE 0) (DEBUG 0) (COMPILATION-SPEED 0))
[2] with -O3 optimization
[3] I had to slightly change the program because gcc didn't like the
'(for int n = ...' statement.
[4] See below for the code.
[5] You decide which program looks nicer... :)
++++++++++++
(defun iterative-max-list (range)
(loop with max = 0
for a from 3 to range by 4
for am = 16
then (let ((n a))
(loop if (evenp n)
do (setq n (floor n 2))
else
maximize (setq n (1+ (* 3 n)))
until (< n a)))
when (> am max)
do (princ (list a
(setf max am)))
finally (return max)))
+++++++++++++
#include <stdio.h>
#include "gmp.h"
main (int argc, char **argv) {
mpz_t a, amax, n, nmax;
int new_max = 0;
char str[255], str2[255];
scanf("%s", str);
mpz_init_set_str(nmax, str, 10);
mpz_init(a);
mpz_init(amax);
mpz_set_ui(amax, 0);
mpz_init(n);
mpz_set_ui(n, 3);
while (mpz_cmp(n, nmax) <= 0) {
mpz_set(a, n);
while (mpz_cmp(a, n) >= 0) {
if (mpz_tstbit(a, 0)) {
mpz_mul_ui(a, a, 3);
mpz_add_ui(a, a, 1);
if (mpz_cmp(a, amax) > 0) {
mpz_set(amax, a);
new_max = 1;
}
} else {
mpz_tdiv_q_ui(a, a, 2);
}
}
if (new_max) {
new_max = 0;
printf("%s: %s\n", mpz_get_str(str, 10, n),
mpz_get_str(str2, 10, amax));
}
mpz_add_ui(n, n, 4);
}
}
Erik Naggum
Do they return the same results? It may sound like a stupid question,
but you would probably be surprised to learn hown often a C solution is
_much_ faster than a Common Lisp solution, but also very, very wrong. If
I want wrong results, I can get that far faster than 33.5 seconds. :)
I think you have run into the bignum cost in Common Lisp. Although
arbitrarily-sized integers is a major feature of the language, some
implementations have not made a particular point of making bignums very
efficient, despite the availability of very high-performance libraries.
I find this sufficiently annoying that I have complained about it several
times, but there is apparently no commercial value in fast bignums, and
since I do not want to pay for reimplementing mp libraries, nor anybody
else, it seems, nothing happens.
You could try CLISP to see if it can give you a significant performance
improvement, but I doubt that you can beat a 64-bit integer if you have
the hardware support for it. Most bignum libraries use 16- or 32-bit
"bigits" and it is hard to make that as fast as a known size.
It would have been so great if Common Lisp implementations could use
machine integers if bindings/slots, etc, were so declared, but it would
probably make garbage collection slightly harder and more expensive.
Raymond Toy
Erik> It would have been so great if Common Lisp implementations could use
Erik> machine integers if bindings/slots, etc, were so declared, but it would
Erik> probably make garbage collection slightly harder and more expensive.
But they do don't they? CMUCL certainly will use (signed-byte 32) and
(unsigned-byte 32) if so declared (or can be determined by the
compiler). Even gcl uses unboxed double-floats when so declared. I
assume ACL and Lispworks can too.
Ray
Thomas F. Burdick
> Hi,
>
> >I have to add that I wasn't able to get ratios as good as Thomas
> >F. Burdick's on my machine (CMUCL 18c, P3 850, 256 MB RAM, Linux
> >2.4.10) - even with the same compilation options and with
> >*PRINT-PRETTY* set to NIL. The C program - compiled with -O3 - was
> >about 3 times as fast.
>
> with this version of the C program:
{ int n;
> for (/* int */ n = 3; n <= nmax; n=n+4)
}
> compiled with lcc-win32, I get a ratio of just under five versus the
> version of the lisp program I posted recently (I get a runtime of
> 0.5 seconds on my machine for C vs. 2.35 seconds for Lisp). What do
> you get here with CMUCL?
On my machine with gcc -O3 (faster than -O this time), I compared that to:
(defun iterative-max-list (range)
(declare (fixnum range)
(optimize (speed 3) (safety 1) (compilation-speed 0) (space 0)))
(loop with max of-type (unsigned-byte 64) = 16
for i of-type fixnum = 3 then (truly-the fixnum (+ i 4))
for i^ of-type (unsigned-byte 64) = max
then (loop for j of-type (unsigned-byte 64) = i
then (if (evenp j) (floor j 2) (1+ (* 3 j)))
for jmax of-type (unsigned-byte 64) = j then (max j jmax)
until (< j i)
finally (return jmax))
until (> i range)
when (> i^ max)
do (princ (list i i^))
(setf max i^)
finally (return max)))
The Lisp runs at about 210% of the C (0.82s : 0.39s).
Okay, I'm officially tired of this game :-). Actually I was before,
but I went one more round, partially because you asked, and partially
because I hit (for the 3rd time in 2 days!) M-C-Backspace, which
really *should* kill the previous sexp, but instead force-quits
Xfree86. The worst part is that it doesn't save the Emacs desktop, so
it's a pain in the butt to get back to where I was. I really wish I
knew how to change that setting in Xfree86. I've been meaning to
investigate, but I'm worried I'll find that it's hard-coded and I'll
need to rebuild it from source. If I had my way, it would be bound to
M-A-C-S-Pause, so I couldn't possibly hit it on accident. Why on
earth do people make force-quit so easy to hit? Command-. on the Mac
also happens to be find-tag in Emacs. </vent>
Martin Thornquist
> because I hit (for the 3rd time in 2 days!) M-C-Backspace, which
> really *should* kill the previous sexp, but instead force-quits
> Xfree86. The worst part is that it doesn't save the Emacs desktop, so
> it's a pain in the butt to get back to where I was. I really wish I
> knew how to change that setting in Xfree86. I've been meaning to
In section "ServerFlags"
Option "DontZap"
for XFree 4, or just
DontZap
for XFree 3.
Martin
--
"An ideal world is left as an exercise to the reader."
-Paul Graham, On Lisp
Raymond Toy
>
> For whatever reason, CMUCL seems to emit really good code (relative to
> gcc) for my Celeron. I have no idea if CMUCL's code is for whatever
> reason especially well optimized for Celerons or if gcc is especially
> bad with them.
CMUCL doesn't know anything about the different flavors of x86
processors. The generated code is the same for all them. The only
difference would be in the C part of CMUCL, which probably isn't really
exercised by the code above (except for GC).
Ray
Thomas F. Burdick
> [ Thomas F. Burdick ]
>
> > because I hit (for the 3rd time in 2 days!) M-C-Backspace, which
> > really *should* kill the previous sexp, but instead force-quits
> > Xfree86. The worst part is that it doesn't save the Emacs desktop, so
> > it's a pain in the butt to get back to where I was. I really wish I
> > knew how to change that setting in Xfree86. I've been meaning to
>
> In section "ServerFlags"
>
> Option "DontZap"
Thanks. I actually looked at the manual right after posting that.
I'm so much less nervous typing now :)
Daniel Barlow
> Okay, I'm officially tired of this game :-). Actually I was before,
> but I went one more round, partially because you asked, and partially
> because I hit (for the 3rd time in 2 days!) M-C-Backspace, which
> really *should* kill the previous sexp, but instead force-quits
> Xfree86. The worst part is that it doesn't save the Emacs desktop, so
By some bizarre twist of (probably IRC-assisted) coincidence, you're
the third person in as many days to mention that.
Option "DontZap" "boolean"
This disallows the use of the Ctrl+Alt+Backspace
sequence. That sequence is normally used to termi
nate the X server. When this option is enabled,
that key sequence has no special meaning and is
passed to clients. Default: off.
From XF86Config-4(5x) on my Debian system. HTH
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Alain Picard
> t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Okay, I'm officially tired of this game :-). Actually I was before,
> > but I went one more round, partially because you asked, and partially
> > because I hit (for the 3rd time in 2 days!) M-C-Backspace, which
> > really *should* kill the previous sexp, but instead force-quits
> > Xfree86. The worst part is that it doesn't save the Emacs desktop, so
>
> By some bizarre twist of (probably IRC-assisted) coincidence, you're
> the third person in as many days to mention that.
>
> Option "DontZap" "boolean"
Yes, this is a _major_ annoyance. Is the use of emacs declining?
It seems I see more and more software blithely capturing what are
valid emacs keystrokes for their own uses. [e.g. the K desktop's
window manager, and others I've given up on and no longer remember]
Philosophically, do emacs users have a "right" to not have their
keystrokes stolen thusly, since, after all, emacs predates pretty
much all of this offending software? Hmmmm.
I've started using Xmodmap games to get a Hyper and a Super bit,
at least _those_ may be safe for a while. :-)
--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>
Jochen Schmidt
Yes thats nice - I have bound all lisp oriented keystrokes (That begin with
C-M- ) to "super-" which I remapped to the left windows key - this also
solves the C-M-Backspace problem :-)
ciao,
Jochen
hrum...@cc.hut.fi
> MIT Scheme is not comparable to CL because it is an *implementation*,
> whereas CL is an internationally standardized programming *language*.
Is CL actually standardized internationally, or only in the USA?
Hannu
Janosch Zwerensky
>(...)
>But enough Lisp bashing: It seems rather obvious to me that C wins
>because it supports the 'long long' type while Lisp doesn't.
That's true, of course. The question left was merely by what margin C would win
here.
> This is a
>nice feature and long longs can indeed get quite big, but there's
>still a rather arbitrary upper limit. I think Collatz sequences are a
>typical example where you really want unlimited precision arithmetic
>and you want to keep your machine running for a couple of days.
Except for the part about actively *wanting* to keep the machine running for
days, no argument here ;).
>I wrote a small C program[4] that uses the gmp library and changed my
>earlier Lisp program by just removing the declarations[5].
Out of curiosity, I also removed all declarations from the so far fastest Lisp
program I had for this problem. Here is the program I got thereby:
(defun iterative-max-list (range)
(flet ((coll-max (a)
(let* ((b a))
(loop for n = a
then (if (evenp n) (floor n 2) (progn
(setf x (1+ (* 3
n)))
(setf b (max x b))
(floor x 2)))
for x = a
until (< n a)
finally (return (max b n))))))
(loop with max = (coll-max 3)
for n from 3 to range by 4
for am = max then (coll-max n)
when (> am max)
do (princ (list n am))
(setf max am)
finally (return max))))
It surprised me a lot that this program doesn't seem to be any slower than the
corresponding program with declarations. Does anybody on this group have an
explanation to offer for this?
Regards,
Janosch.
Janosch Zwerensky
> Do they return the same results?
Yes, they do.
At least if you disregard the fact that the output format of the C version
doesn't show you all digits of the results.
C's long longs seem to reach just high enough for the results to be
uncompromised.
>(...)
Regards,
Janosch.
Kent M Pitman
It is an American National Standard. There is an international Lisp
standard, which is ISO ISLISP, but it's not code-compatible and its
deployment is comparatively tiny. ANSI CL is _sold_ world-wide,
though. Is there a reason that isn't enough?
Lieven Marchand
Common Lisp is an ANSI standard. There is an ISO standard for another
language in the lisp family, ISLISP.
--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Thomas F. Burdick
> Hi,
>
[ Edmund Weitz: ]
> >(...)
> >But enough Lisp bashing: It seems rather obvious to me that C wins
> >because it supports the 'long long' type while Lisp doesn't.
You meant to say "while no current Lisp implementation does", of
course, right? :-)
That's easy, ACL isn't doing anything with the (unsigned-byte 64)
declarations. I'd imagine the fixnum declarations would make a tiny
bit of difference, but they don't matter in the inner loop, so, like I
said, tiny. CMUCL produces about 150% slower code with integer
declarations, and only slightly different code with no declarations at
all.
By the way, I'm not surprised that ACL doesn't do anything (or
anything much) useful with the type declarations. Their customers
benefit tremendously more from, say, simple-streams, than they would
from an equivalent effort put into super-optimizing numeric code.
After all, if you really need this as blazingly tight inner loop, you
probably want to write it in assembler, anyhow.
Kaz Kylheku
Really, if your local member body of ISO doesn't have its own version
of a ANSI standard, that ANSI standard is effectively international.
What usually happens is that the other member bodies accept an ANSI
standard with little or no change. E.g. when the ANSI C standard was
approved by ISO, they just renumbered the sections.
In my limited understanding, the work is done, and the rest is largely
just rubber stamping, so in principle we could have an ISO Common Lisp.
Dr. Edmund Weitz
> > >But enough Lisp bashing: It seems rather obvious to me that C
> > >wins because it supports the 'long long' type while Lisp doesn't.
>
> You meant to say "while no current Lisp implementation does", of
> course, right? :-)
Sure... :)
Dr. Edmund Weitz
> At least if you disregard the fact that the output format of the C
> version doesn't show you all digits of the results.
On my machine (glibc 2.2.4) you can use the "%lld" format with printf
and thus get all digits.
Aleksandr Skobelev
"Most of the work is done" might be more correctly to speak. IMHO ANSI CL
standard is lacking in support for locales/charsets. So any non-Latin-1
user might encounter with some problems/inconviniences ever with
commercial realisations (such as Allegro 6.?, Lispwork 4.1.20). And when I
think about some funny features in the language like YES-OR-NO-P or ~R in
FORMAT, I understand that they were designed with English taken in
consideration only.
Kent M Pitman
> Kaz Kylheku <k...@ashi.footprints.net> wrote:
>
> > Really, if your local member body of ISO doesn't have its own version
> > of a ANSI standard, that ANSI standard is effectively international.
Well, maybe not as a matter of country-level diplomacy, but probably as
a matter of informal, de facto commercial practice, yes.
> > What usually happens is that the other member bodies accept an ANSI
> > standard with little or no change. E.g. when the ANSI C standard was
> > approved by ISO, they just renumbered the sections.
But IMO one doesn't do this analysis on the basis of how things have
run in the past. One does this on the basis of what people are
clamoring for and what the reason is for going into the standards
process. We asked around a while back when considering pushing this
to ISO and the wisdom was, "unless you want a specific change, do not
open the option for change". With respect to global acceptance of
ANSI CL, there is nothing broken. If there is a push for an ISO CL,
it will come from abroad. But I would hope that, if possible, people
push instead for layered standards, either at the national lavel (ANSI,
BSI, AFNOR, etc.) or the international level (ISO).
> > In my limited understanding, the work is done, and the rest is largely
> > just rubber stamping, so in principle we could have an ISO Common Lisp.
What you say would e true if everyone worldwide took the same position as you,
but any committee takes on a life of its own when these things start, and
it's just not wise to assume the latter. I think instead I would stick to
how you summarized it above: ANSI CL operates similarly an ISO CL already,
and it is best not to divert large resources to solving non-problems.
> IMHO ANSI CL
> standard is lacking in support for locales/charsets. So any non-Latin-1
> user might encounter with some problems/inconviniences ever with
> commercial realisations (such as Allegro 6.?, Lispwork 4.1.20). And when I
> think about some funny features in the language like YES-OR-NO-P or ~R in
> FORMAT, I understand that they were designed with English taken in
> consideration only.
Certainly you are right if you mean that it is lacking service
functions for locales and charsets, but we made the design pretty
general in a way that I think doesn't fight an implementation that
wants to pursue these issues. If you find that's not so, it would be
an interesting topic of discussion to hear what specific
representational requirements are keeping you from having what you
want.
Individual implementations may indeed fall short, but before blaming
the spec for this, you should try to find the place in the spec that
REQUIRES such implementations to fall short. It's possible to happen,
in principle, but I think it's not there in most cases...
As to the issue of English bias, I think this: Because English is the
international interchange language (we're speaking it now, after all),
there is some reason to indulge some accomodations to it. If I were
to propose fixing things, it would mostly be to remove the offending
features, not to internationalize them. The problem is that those
features are mostly weak even for their support of English, and are
probably just bad ideas. They were in there as accomodations to
history, since old code used them. And the cost of ignoring them is
small.
IMO, proper support of these things for international purposes (to
include proper support for English) would be better to proceed as a
layered library standard, and I don't see any representational nor
protocol barrier to doing such things in an implementation that
commercially favors an international market.
The Japanese national body presented a report to the US just prior to
our putting out the standard, asking for a small number of detailed
changes to accomodate their internationalization needs. The US rushed
to fully accomodate their list of minimal necessary changes. I have
never heard a subsequent complaints that the changes we made were
insufficient. CLEARLY, there was work left to implementations and to
other layered standards, but IMO it's important to understand that
that will always happen.
So I'm not trying to assert that there are no bugs in CL that would be
a problem to internationalization. I'm trying to say that I try to
listen when people raise this issue because I USED TO think that CL
was enough deficient in this are that we would be forced to fix it at
some point. But over time I have come to the belief that the core
design is good enough that it can probably stand, at least for now.
And I'm asking you to do two things, Aleksandr, in order to be most
helpful here:
* Make your criticisms more precise so that those of us who don't
experience the day-to-day issues that you do can better understand
what you are up against. Many of us suffer from lack of day-to-day
familiarity with the problems at all and have to stretch our brains
to know what you're up against. Although I can imagine a problem with
YES-OR-NO-P in Russian, it's not obvious to me what that is. I imagine
(yes-or-no-p "Exit?") or (yes-or-no-p "Salir?") or ... to work in
just about any language; I don't see any internationalization issue
here that is different than (format t "~&Exit?~%") vs
(format t "~&Salir?~%"). [Pardon my use of Spanish as an example,
I don't speak Russian.] THe only problem I can even imagine is that
a pop-up dialog might need to know whether to put clickboxes that said
[Yes]/[No] or [Si']/[No] and in order to know this, it would need to
intuit the language that the query was presented in, so as not to have
the question asked in one language but the answer offered in another.
This is a problem, but again I can't see how it's much different than the
overall problem that CL uses inline strings in code rather than
references to resource vectors of translatable strings. I don't see that
problem as YES-OR-NO-P specific. So maybe you could help us by working
an example for each such thing you complain about. Thanks...
* Distinguish in your criticisms between omission and bad foundation.
A feature which is merely omitted (and there are many) can be added
compatibly. If our design is a bad foundation, then something about
an existing requirement must be fixed first to move on, correcting a
hill-climbing problem.
Thanks for your help in keeping the discussion focused.
Duane Rettig
> Aleksandr Skobelev <holy...@mail.ru> writes:
>
> > IMHO ANSI CL
> > standard is lacking in support for locales/charsets. So any non-Latin-1
> > user might encounter with some problems/inconviniences ever with
> > commercial realisations (such as Allegro 6.?, Lispwork 4.1.20). And when I
> > think about some funny features in the language like YES-OR-NO-P or ~R in
> > FORMAT, I understand that they were designed with English taken in
> > consideration only.
[ ... ]
> ... But over time I have come to the belief that the core
> design is good enough that it can probably stand, at least for now.
> And I'm asking you to do two things, Aleksandr, in order to be most
> helpful here:
>
> * Make your criticisms more precise so that those of us who don't
> experience the day-to-day issues that you do can better understand
> what you are up against. ...
>
> * Distinguish in your criticisms between omission and bad foundation.
> ...
I second Kent's request and agree with his assessment of the generality
of the ANSI CL spec. Furthermore, I offer Allegro CL 6.0 as an
example of how the spec has in fact been used without change to
incorporate international character sets and most international
external-formats, and Allegro CL 6.1 as an example of extending
the spec seamlessly to implement some of the important locale
categories of the POSIX locale specification. See
http://www.franz.com/support/documentation/6.1/doc/iacl.htm#localization-1
As for yes-or-no-p et al, it is true that we have not implemented the
LC_MESSAGES category, but it is entirely possible. And I may be wrong,
but my reading of the definition of yes-or-no-p in the spec doesn't
preclude an implementor from basing either the message string or the
actual "yes"/"no" responses on the locale.
As for the ~R format directive, I do agree that it is awkward to extend
individual pieces of format; we decided to make our locale extentions
general, using ~/ as our extension mechanism. The fact that ~/ was
available is to CL's credit re its extensibility.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Kent M Pitman
> As for yes-or-no-p et al, it is true that we have not implemented the
> LC_MESSAGES category, but it is entirely possible. And I may be wrong,
> but my reading of the definition of yes-or-no-p in the spec doesn't
> preclude an implementor from basing either the message string or the
> actual "yes"/"no" responses on the locale.
I don't think the spec requires it, though how it would know what
language it was in is slightly problematic. You have to know what
language the question is being asked in OR you have to accept
responses in multiple languages. If you're taking one-letter
responses, it's not hard to imagine how a letter might have
conflicting meanings depending on the language, though I don't know if
that happens in practice.
> As for the ~R format directive, I do agree that it is awkward to extend
> individual pieces of format; we decided to make our locale extentions
> general, using ~/ as our extension mechanism. The fact that ~/ was
> available is to CL's credit re its extensibility.
Part of the problem isn't just the desire to extend but the fact that
what some people mean by "extend" is "redefine". Even if you knew a program
was being run in a certain country by a certain user who needed certain
interfaces localized, you don't know if ~R is being called for reasons
relevant to where the program is run or independent of that. One should
not confuse the notion of "providing a function that is known to vary in
effect with localization" with the notion of "providing a function that
someone WISHES had varied with localization but that programmers have
already used in the full knowledge that it is not going to do that".
"Upgrading" a program of the latter kind is really just "breaking" it.
You're right that ~/ is the right answer; ~R is not only hard to extend
but I think it would be improper to extend it. Better to just ignore it
if you don't like it just as it's spec'd now.
Thomas F. Burdick
> Although I can imagine a problem with YES-OR-NO-P in Russian,
> it's not obvious to me what that is. I imagine
> (yes-or-no-p "Exit?") or (yes-or-no-p "Salir?") or ... to work in
> just about any language; I don't see any internationalization
> issue here that is different than (format t "~&Exit?~%") vs
> (format t "~&Salir?~%"). [Pardon my use of Spanish as an
> example, I don't speak Russian.] THe only problem I can even
> imagine is that a pop-up dialog might need to know whether to put
> clickboxes that said [Yes]/[No] or [Si']/[No] and in order to
> know this, it would need to intuit the language that the query
> was presented in, so as not to have the question asked in one
> language but the answer offered in another. This is a problem,
> but again I can't see how it's much different than the overall
> problem that CL uses inline strings in code rather than
> references to resource vectors of translatable strings. I don't
> see that problem as YES-OR-NO-P specific. So maybe you could
> help us by working an example for each such thing you complain
> about. Thanks...
Actually, your sí/no example made me think of one where yes-or-no-p
won't work in French. Of course, it's confusing in English, but in
French, the implementation would need to be able to understand the
language to do the right thing. Say the user has told the application
to quit without finishing some task:
[I'm imagining here that this program uses something akin to GNU
gettext for its internationalization, with a dynamic variable bound to
the current locale, and a read macro defined for _ to translate the
upcoming string]
(let ((finishp (yes-or-no-p _"Finish?")))
(unless finishp
;; Make sure they really mean it!
(setf finishp (yes-or-no-p _"You do not want to finish?")))
...)
I'd expect that to do:
English:
Finish? (yes/no) no
You don't want to finish? (yes/no)
French:
Finir? (oui/non) non
Vous ne voulez pas finir? (si/non)
French has the oppositional adverb "si", which must be used in this
case. "Si, I *do* want to finish!" or "Non, I do not want to finish".
We might avoid this situation like the plague in English because it's
confusing (though not actually ambiguous), but other languages don't
necessarily have that problem. The work around is to just not ask
negated questions with yes-or-no-p, or to define it as only ever
asking "oui" or "non", but that says to me that it shouldn't be in the
language (or should be removed from a hypothetical ISO CL).
I would expect there to be other languages with more words in this
area, since, although there's technically no ambiguity in English
here, we avoid this situation like the plague in actual usage because
it feels ambiguous.
On the other hand, French isn't exactly a secret code known by only a
few initiates, so I wonder if this came up during the design of CL. I
was curious if Le-Lisp had anything like yes-or-no-p, but there
doesn't seem to be anything much about it on the web (that I can find,
anyhow). All I know about it is that it was from INRIA and apparently
was CL-like. I'm guessing from the fact they don't have it for
download that it wasn't free. Was it the only French-designed lisp?
Erik Naggum
| "Most of the work is done" might be more correctly to speak. IMHO ANSI
| CL standard is lacking in support for locales/charsets.
ANSI CL is also lacking in support for printing the new Euro notes on
ordinary office laser printers, another would-be useful thing that is
outside the scope of the standard.
If you have actually tried using locales to achieve localizability and
still think they serve a useful purpose beyond marketing rhetoric, I
would like to see your code.
| So any non-Latin-1 user [...]
ANSI Common Lisp is not even defined for ISO Latin 1, but for a character
set that closely matches ASCII or ISO 646 IRV. However, that is only a
minimum requirement -- the implementation is obliged to document what it
actually supports. Several Common Lisp implementations support a 16-bit
Unicode. Note that there is no standard way to add case information to
the supported character set, so if you want to depend on the language
support for case conversion, you are SOOL if what you want it is not
supported, especially if the char-up/downcase functions are inlined as
tests for a-z so you cannot even redefine them. (E.g., this is still a
problem in Allegro CL's 8-bit-character version despite excellent support
for character sets in the 16-bit-character version.)
| And when I think about some funny features in the language like
| YES-OR-NO-P or ~R in FORMAT, I understand that they were designed with
| English taken in consideration only.
This is a good thing. If it were designed by the usual "international"
tactics, it would lack a lot of useful features because some rinkydink
language with a few hundred speakers could not support it, like plurals.
The fact that you react to these things with some hosility is a good sign
that Common Lisp would have suffered had it been intended to placate all
the sourpusses in the world who envy the United States is position and
who loathe the role that English has acquired -- instead of French or
German, both or either which "deserve" it much more than English does, if
you poll several large segments of the European population.
Fortunately, I can say all these things because I am _not_ American, but
happen to come from and live in a rinkydink country with three official
languages for less than 5 million people, one of which is a pathetic
rural rebellion against national standards set by the cities and which
today differ much less than British and American English. Just how hard
do you have to lose to think such a stunt is a good idea for the _same_
people? Right! So pardon me while I think "locales" and supporting
loser dialects is a Bad Idea.
///
--
Jochen Schmidt
> The fact that you react to these things with some hosility is a good
> sign that Common Lisp would have suffered had it been intended to
> placate all the sourpusses in the world who envy the United States is
> position and who loathe the role that English has acquired -- instead of
> French or German, both or either which "deserve" it much more than
> English does, if you poll several large segments of the European
> population.
>
> Fortunately, I can say all these things because I am _not_ American, but
> happen to come from and live in a rinkydink country with three official
> languages for less than 5 million people, one of which is a pathetic
> rural rebellion against national standards set by the cities and which
> today differ much less than British and American English. Just how hard
> do you have to lose to think such a stunt is a good idea for the _same_
> people? Right! So pardon me while I think "locales" and supporting
> loser dialects is a Bad Idea.
My English is far from being good, but I finally came to the opinion that I
don't see German the language as very important. I read all CS literature in
English even if German translations are available because if I want to
discuss this topics I will have to do it in English and will have to know
the English terms and not the German translations. I even tend to read
romans in English because I think it will help me to improve my language
skills and because I really like the language. More and more often I catch
me that I at least partially think in English or that I only know a term in
English but do not have a direct German translation at hand.
Compared to German, English seems to be a very "fuzzy" language with many
ambiguities that get resolved through context. Some English authors make
use of this fact to express multiple things in the same part of sentence
depending on how you look at it. German makes those things much more
explicit which makes it a rather boring language.
So I think _I_ could certainly live with computer programs that only
support English as language...
Thomas F. Burdick
> * Aleksandr Skobelev <holy...@mail.ru>
> | "Most of the work is done" might be more correctly to speak. IMHO ANSI
> | And when I think about some funny features in the language like
> | YES-OR-NO-P or ~R in FORMAT, I understand that they were designed with
> | English taken in consideration only.
>
> This is a good thing. If it were designed by the usual "international"
> tactics, it would lack a lot of useful features because some rinkydink
> language with a few hundred speakers could not support it, like plurals.
Hmm, I'd hardly call Japanese a rinkydink language.
> The fact that you react to these things with some hosility is a good sign
> that Common Lisp would have suffered had it been intended to placate all
> the sourpusses in the world who envy the United States is position and
> who loathe the role that English has acquired -- instead of French or
> German, both or either which "deserve" it much more than English does, if
> you poll several large segments of the European population.
>
> Fortunately, I can say all these things because I am _not_ American, but
> happen to come from and live in a rinkydink country with three official
> languages for less than 5 million people, one of which is a pathetic
> rural rebellion against national standards set by the cities and which
> today differ much less than British and American English. Just how hard
> do you have to lose to think such a stunt is a good idea for the _same_
> people? Right! So pardon me while I think "locales" and supporting
> loser dialects is a Bad Idea.
Certainly the idea of locales can be (and is) taken to a silly
extreme. However, there are a few languages that are really
important, and being able to deliver applications in them is
important. English, Spanish, maybe French, Arabic, Chinese, and
Japanese, should all be usable. We should be able to assume that all
programmers have at least basic English skills, but the same is not
true of users.
Erik Naggum
| As for yes-or-no-p et al, it is true that we have not implemented the
| LC_MESSAGES category, but it is entirely possible. And I may be wrong,
| but my reading of the definition of yes-or-no-p in the spec doesn't
| preclude an implementor from basing either the message string or the
| actual "yes"/"no" responses on the locale.
Fixing yes-or-no-p in the locale is the wrong place to do it. This is
clearly a user-interface function that depends on a particular mode of
user interaction with specific programmer and user expectations. Making
it more general is a mistake. A more elaborate user interface would need
more than just yes-or-no-p and y-or-n-p. _If_ these functions match the
user interface needs, they will be used, and then all parties involved
expect them to be exactly as they were when they got into the language.
If they are not satisfactory for user interaction, some other functions
will be written and used in their place. Please do not bother making
"localized" versions of these functions.
I work in two languages all the time -- have been since I were a kid, and
I consider myself fluent in both. I am constantly deeply annoyed by the
incompetence of the fools who think they can translate movies and books,
and can only imagine what kind of mistakes are made in translations of
languages I cannot read in the original. Not many years ago, fluency in
several European languages were common among academics and the lingua
franca (!) was Latin _long_ after that language had ceased to be spoken.
It is somewhat unfortunate that computer science uses a living language
for its lingua franca, in contrast to law and medicine, which are both
firmly based in much older languages and cultures, because that makes a
lot of people who fail to grasp the function of a common language think
it is a natural language and can be replaced by another, particularly
those who speak it naturally and are overcome with political correctness
and think they should be guilty of the fact that historic accidents
favored their language. The common language is, however, _not_ a natural
language except by accident, and it cannot be replaced by another natural
language without replacing the whole culture with it. Those who think
_their_ natural language should be the common language should just get
over their egoistic provincialism and learn to deal with reality.
And speaking as a user of Norwegian software, I do not accept some
two-bit "translation". If I have to translate the incompetent Norwegian
back to what I think the natural English would have been in order to
understand what the Norwegian probably means, all parties involved would
have been better off with the original. Like the other day, I saw "IP
header compression" translated on a cell phone to what best translates
back to "reduced headlines". I think translation between English and
Norwegian is important enough that I contribute to dictionaries and try
to help companies who pay their translators basically nothing to write
the local version of text that somebody else paid a large sum of money to
get just right in English. Thankfully, however, original-language
paperbacks in British and American English are now outselling translated
versions, and several major film releases are available in original
versions, so there is hope for this undersized country. English is now
taught from the first grade.
The more I have worked with software in these two different languages,
the more I am convinced that message catalogs is one of the worst
non-solutions. It works OK only if you have a primary language and
subordinate languages that you do not care if suffer from stilted
expression and phony flow of logic. We have to realize that the logic
flow of the primary language is deeply engrained in the program itself
and that "translating" what appears to be a step-by-step procedure in one
language may require fewer or more steps and with a different order in
another language, like in which order you provide the components of your
name and postal address, etc. The whole user interface/experience needs
to be tailored to each culture and language. "Translation" must be done
by programming.
This naturally leads to the conclusion that software should not speak
natural languages to users, but formalized protocols to user interface
engines. In other words, yes-or-no-p would be a protocol element, not a
_specific_ user interaction in my view.
///
--
Erik Naggum
| Certainly the idea of locales can be (and is) taken to a silly extreme.
| However, there are a few languages that are really important, and being
| able to deliver applications in them is important. English, Spanish,
| maybe French, Arabic, Chinese, and Japanese, should all be usable. We
| should be able to assume that all programmers have at least basic English
| skills, but the same is not true of users.
Well, you cannot write a program that works in English, Spanish, French,
Arabic, Chinese and Japanese unless you know _all_ these languages and
_prepare_ for the translation.
The only way to make a program work in more than one language is to make
it work in _none_: formalize a protocol and write user-interface front-
ends to it. Let those who understand the application _and_ the target
language write that user-interface front-end.
English happens to be the _common_ language of the field of computer
science. It no longer has the role of a natural language in computer
science. That this leaves a large number of people "handicapped" by
being misled to believe that _their_ language is the common language, is
nothing but unfortunate.
Forget the whole locale business and write software that speaks about
objects and units and internal stuff, and let several user-interface guys
handle the user-interface portion that talks to people in various
cultures. This is not hard at all, once you get past the misguided
notion that all computer programs should talk directly to users.
///
--
Duane Rettig
> * Duane Rettig <du...@franz.com>
> | As for yes-or-no-p et al, it is true that we have not implemented the
> | LC_MESSAGES category, but it is entirely possible. And I may be wrong,
> | but my reading of the definition of yes-or-no-p in the spec doesn't
> | preclude an implementor from basing either the message string or the
> | actual "yes"/"no" responses on the locale.
>
> Fixing yes-or-no-p in the locale is the wrong place to do it. This is
> clearly a user-interface function that depends on a particular mode of
> user interaction with specific programmer and user expectations. Making
> it more general is a mistake. A more elaborate user interface would need
> more than just yes-or-no-p and y-or-n-p. _If_ these functions match the
> user interface needs, they will be used, and then all parties involved
> expect them to be exactly as they were when they got into the language.
> If they are not satisfactory for user interaction, some other functions
> will be written and used in their place. Please do not bother making
> "localized" versions of these functions.
Right. As I said, we have not implemented them. My argument is purely
one for possibility, and not for practicality or desirability. I agree
that a programmer who wants a specific si/no or ja/nein or oui/non
interface can write their own functionality to do just that. I am only
saying that the CL spec doesn't preclude such responses from an
implementation.
> I work in two languages all the time -- have been since I were a kid, and
> I consider myself fluent in both. I am constantly deeply annoyed by the
> incompetence of the fools who think they can translate movies and books,
> and can only imagine what kind of mistakes are made in translations of
> languages I cannot read in the original.
A gripe I used to have as an English speaker was when I would buy a
Japanese (or other nationality) bicycle and get instructions purportedly
in English, and which indeed used only English words, but in such a way
as to be unintelligible. I still buy products from other countries, and
still receive instructions in English, but fortunately they are much better
written nowadays, since companies have learned that their products sell
better when proper translations of instructions are done.
> Not many years ago, fluency in
> several European languages were common among academics and the lingua
> franca (!) was Latin _long_ after that language had ceased to be spoken.
> It is somewhat unfortunate that computer science uses a living language
> for its lingua franca, in contrast to law and medicine, which are both
> firmly based in much older languages and cultures, because that makes a
> lot of people who fail to grasp the function of a common language think
> it is a natural language and can be replaced by another, particularly
> those who speak it naturally and are overcome with political correctness
> and think they should be guilty of the fact that historic accidents
> favored their language. The common language is, however, _not_ a natural
> language except by accident, and it cannot be replaced by another natural
> language without replacing the whole culture with it.
A good example of this is music; as a musician, I do know a few words
of Italian (including Allegro! :-) Translation of these musical terms
into English are usually not done; when they are attempted, the music
is usually rejected as not authentic.
> Those who think
> _their_ natural language should be the common language should just get
> over their egoistic provincialism and learn to deal with reality.
Well, as a native English speaker, I understand that English is an
important language used in computer science, but for the very reason you
cite I do not want to assume too much. Whether non-native-English speakers
(or more importantly, whether non-English speakers) accept English-only
interfaces is going to be up to you/them. And the acceptability of such
English-only interfaces are likely to vary according to the audience;
whether to the programmer or to the end-user. To use my music analogy,
it takes some understanding of Italian terms (piano, forte, pizzicato,
cresendo, etc) to play written music, but it takes no such knowledge
to listen nd enjoy the same music.
Jean-François Brouillet
# So pardon me while I think "locales" and supporting loser dialects
# is a Bad Idea.
Only an arrogant moron, living in a loser country could utter such loser
sentences. If that half brain that this lower life has rented were still
half working [we're talking 25% of full regime here, if you can't do the
math yourself] we would be spared such loser posts which don't bring any
value _at all_ to that thread.
Jochen Schmidt
# My English is far from being good, but I finally came to the opinion
# that I don't see German the language as very important.
I would agree too...if my native language were German that is ;-)
It turns out that my English is far better, and that my French is near
perfection. If I had more time, I would certainly learn more winner
languages (Russian and Arabic spring to mind).
# More and more often I catch me that I at least partially think
# in English
No you don't. Only mono-linguists can argue they do, until proven wrong.
When you utter some sentence (in any language) you know, ahead of the
words coming out of your mouth, what the sentence is going to affirm.
(that is, unless you are a politician of course ;-). Yet those words
that will appear in the near future, are not _verbalized_ yet, and are
only _translated_ to your utterance language as your tongue makes some
progress.
While, according to Bergson, the language is the support of the thought,
it is _not_ the thought itself, even though a given language _shapes_ the
way you think.
Multiplying the languages you know can only give you more perspectives,
and ways of thinking. Reducing their number can only lead you to an
impoverished mental landscape, where entire areas of human thought will
simply never flourish.
Finally, this idea that a given language has "won" is utter non-sense.
French had "won" two centuries ago. Where is it today? Give me a break
and go by some more brain cells. At any point in time, there is a dominant
language. Latin two thousand years ago, Chinese in the next decade. And
so what?
So what?
The issue is that way too often, this kind of decision (whether and how
to support non dominant languages) is left to computer specialists, the
vast majority of whom are _anything else_ illiterate. This includes art,
poetry, literature, and most forms of human expressions that do not appeal
to those "computer morons".
If a shoe helps you walk, a computer is meant to help you think. No matter
what uneducated, university degrees loaded psychopaths would love you to
believe.
"Ouf! Depuis le temps que j'attendais ça, je me suis payé le Naggum!"
--
Jean François Brouillet
^
+--- this letter is called "Fuck You! Loser"
Thomas F. Burdick
> "Ouf! Depuis le temps que j'attendais ça, je me suis payé le Naggum!"
Yow, until I got here, I was quite confused by the inexplicably
violent response in this article. Well, good explanation or not, it's
no longer inexplicable. Ouf, indeed.
Erik Naggum
| Well, as a native English speaker, I understand that English is an
| important language used in computer science, but for the very reason you
| cite I do not want to assume too much.
Each field has only one common language. Any attempt to add more will
split the field. It is already a problem that research published in
French and German are unavailable to the rest of the computer science
community.
| Whether non-native-English speakers (or more importantly, whether
| non-English speakers) accept English-only interfaces is going to be up to
| you/them.
Fluency in English is a sine qua non in computer science. Programmers
who want translated software tools and programming languages in their
native tongue will forever remain incompetent tinkerers. Only one
company on the planet thinks this is a good idea.
| And the acceptability of such English-only interfaces are likely to vary
| according to the audience; whether to the programmer or to the end-user.
End-users should _obviously_ be served with natural language interfaces.
I do not see how what I have said could be construed to have been arguing
against natural-language end-user interfaces. Quite the contrary, I have
made several points about how software that needs to talk to real users
must be tailor-made in each language. How could this possibly be taken
to mean that we should _not_ make natural-language interfaces for users?
///
--
Erik Naggum
| Only an arrogant moron, living in a loser country could utter such loser
| sentences. If that half brain that this lower life has rented were still
| half working [we're talking 25% of full regime here, if you can't do the
| math yourself] we would be spared such loser posts which don't bring any
| value _at all_ to that thread.
| --
| Jean François Brouillet
| ^
| +--- this letter is called "Fuck You! Loser"
What an _interesting_ display of personality problems. Get help, OK?
///
--
Aleksandr Skobelev
> Aleksandr Skobelev <holy...@mail.ru> writes:
> ...
Well, I don't think that there is need to intuit the language of the query
to interpret replies properly in YES-OR-NO-P. Probably, it is enough just
to allow to set strings for yes/no replies (for example through some
specail variables called *yes-reply*, *no-reply*...) and leave the problem
of language synchronization in query/reply for programmer.
So, I think, YES-OR-NO-P in its current state is not very useful in any
program which intended for non-English user, who works with non-English
keyboard mainly. IMHO it is not convinient, at least, because such user
need to switch the keyboard to English and back every time he/she need
reply on YES-OR-NO-P query. It is, of course, is not a problem, because
such functionality can be implemented very easy. It is just a little
inconvenience.
If we spoke about an implementation of "international" functionality of ~R
directive, I would try to offer a some leverage with ability to pass a
list of user arguments to ~R that then could be passed to some callback
function (that could be set by a programmer) to get a proper form for ordinal
number.
Again, I don't speak that this functionality is needed. I think this
is just some convenient tools in the language. If they were absent, nobody
told about them. But, on the other hand, if they were added, why didn't they
have done more extendable?
The more important thing is, of course from my point of view, ability to
set a proper charset. Without that functions for manipulating strings and
characters don't work properly. So STRING-UPCASE for example doesn't not
work with Russian in Lispwork 4.1.20 Personal Edition, CMUCL. There is
SET-LOCALE function in Lispwork but only "C", "POSIX" and "*.ISO-8859-1"
locales exist. If my memory serves me, there are same situation in Allegro
6.x (i.e. SETLOCALE exists but number of localies is limited by
C/POSIX/*.ISO-8859-1)? But because I don't have Allegro on my computer
now, I can make a mistake here.
Again, It might be not a problem but just a little inconvenience.
Because, I suspect that correspondent localies can be added to both
Lispwork and Allegro. And it is not a very hard ever for such a beginner
as me to implement a basic SETLOCALE functionality in CMUCL using existing
Alien interface.
I don't blame anybody or anything. I think that a great job was done with
the standard. I can understand vendors who probably have had most of their
customers in English-spoken countries. So there were not value reasons for
them to harry up with implementation of functionality that was not part of
the standard.
Thank you and all others senders who reply on my message. I have been
reading this newsgroup regulary enough and I have never seen before a
discussion of that topic. But these little problems with locales were the
one of the first thing which I had encountered at the very begining of my
CL voyage. :) I sent my message driven by intention just to attract
community's attention to this topic, but didn't blame anybody.
And excuse me, please, for my ... not very good English. :(
Jochen Schmidt
> Jochen Schmidt
>
> # My English is far from being good, but I finally came to the opinion
> # that I don't see German the language as very important.
>
> I would agree too...if my native language were German that is ;-)
> It turns out that my English is far better, and that my French is near
> perfection. If I had more time, I would certainly learn more winner
> languages (Russian and Arabic spring to mind).
It is nice for you if you think that your English is far better (than
what?). I don't choose languages I want to learn because they are
understood as "winner languages" - if that would be the case I would never
have a chance to learn french...
But seriously - I don't think there are any "winner languages" at all - I
really hope that your attitude is not very common anymore in your country.
(And I'm glad to know some people from french who support my hopes)
Languages and the corresponding cultures are tightly coupled - therefore I
choose languages of cultures that I find interesting. Until now my plans
for the next language I want to learn as soon as I find the time are either
Chinese (Mandarin) or Japanese.
I furthermore think that it is common to learn the language of the country
were you live - regardless if the country is a "winner" or if the people
speak a "winner language".
There is only one country in Europe that demands from other countries to
learn their native language at the european parliament (and it is not
Germany).
I'm quite happy that those ugly nationalistic attitudes widely disappeared
in Germany many years ago...
> # More and more often I catch me that I at least partially think
> # in English
>
> No you don't. Only mono-linguists can argue they do, until proven wrong.
To bad for you that you never experienced it before...
> When you utter some sentence (in any language) you know, ahead of the
> words coming out of your mouth, what the sentence is going to affirm.
> (that is, unless you are a politician of course ;-). Yet those words
> that will appear in the near future, are not _verbalized_ yet, and are
> only _translated_ to your utterance language as your tongue makes some
> progress.
This may be true - but it is a difference if it is translated directly to
English or if it is translated to German and after that translated from
that to English...
> While, according to Bergson, the language is the support of the thought,
> it is _not_ the thought itself, even though a given language _shapes_ the
> way you think.
Yes _your_ thoughts are not well materialized in a specific language - not
in your mind and not much more if they are spoken out - but probably you
will somedays realize that it is not because of a language problem...
> Multiplying the languages you know can only give you more perspectives,
> and ways of thinking. Reducing their number can only lead you to an
> impoverished mental landscape, where entire areas of human thought will
> simply never flourish.
>
> Finally, this idea that a given language has "won" is utter non-sense.
> French had "won" two centuries ago. Where is it today? Give me a break
> and go by some more brain cells. At any point in time, there is a dominant
> language. Latin two thousand years ago, Chinese in the next decade. And
> so what?
Your nearly perfect English skills may have led you on the wrong road if
you think that I said that I have the idea that any language has "won" or
that it is not worth to learn more languages. I said that I by myself
actuallyprefer to read English literature (instead of German translations
of them!) out of practical reasons and because I like the language. I
prefer to not generalize from me about others - I can only speak for myself.
> So what?
>
> The issue is that way too often, this kind of decision (whether and how
> to support non dominant languages) is left to computer specialists, the
> vast majority of whom are _anything else_ illiterate. This includes art,
> poetry, literature, and most forms of human expressions that do not appeal
> to those "computer morons".
As I already said - _I_ do not generalize from me about others...
> If a shoe helps you walk, a computer is meant to help you think. No matter
> what uneducated, university degrees loaded psychopaths would love you to
> believe.
>
> "Ouf! Depuis le temps que j'attendais ça, je me suis payé le Naggum!"
And I finally realize that it was probably not worth the time for an
answer...
> Jean François Brouillet
> ^
> +--- this letter is called "Fuck You! Loser"
The "ç" wow - and you speak about people being illiterate...
Grow up...
ciao,
Jochen Schmidt
Kent M Pitman
> Well, I don't think that there is need to intuit the language of the query
> to interpret replies properly in YES-OR-NO-P. Probably, it is enough just
> to allow to set strings for yes/no replies (for example through some
> specail variables called *yes-reply*, *no-reply*...) and leave the problem
> of language synchronization in query/reply for programmer.
I don't agree that this would make the language stronger.
First, you are failing to distinguish, as I asked you do, things that the
language keeps from happening from things the language merely does not
force to happen. The language definition does not say an implementation
should not do this. HOWEVER, if the language definition *did* do this,
it would be a weaker language. You appear to be assuming (in both cases
incorrectly) BOTH that (1) YES-OR-NO-P cannot accept such responses now
and (2) YES-OR-NO-P works by textual typein. As to point 1, a conforming,
correctly localized implementation of Lisp, is already permitted to do what
you say. That is, what stands between you and success is not the language
definition but your vendor's choice of how to render the language spec into
a language implementation. But as to point 2, some vendors work by asking
a textual query in which "yes" or "da" might be 'yes' answers *already*
and "no" or "nyet" might be 'no' answers *already*. Now, if the language
required so simple an interface as you provide, *yes-reply* could only
contain one value, not many, and so you'd be eliminating valid replies.
At minimum, you'd want a list of yes replies. But then in that case, the
implementations where it was a dialog would not know what to do. In that
case, how would you distinguish between whether (yes-or-no-p "Exit?")
and (yes-or-no-p "Salir?") producing:
Exit? Salir?
vs
[Yes] [No] [Si'] [No]
(english) (spanish)
The heuristic guessing of language (especially based on a small number of
letters) would be impossible to do reliably. Certainly it would not be
able to tell whether to do even something like:
Comer? Comer?
vs
[Si'] [No] [Sim] [Na~o]
(spanish) (portuguese)
much less someting like this :) ...
42? 42?
vs
[Yes] [No] [HIja'] [ghobe']
(federation standard) (klingon)
The thing to understand is that these are *interface* issues and that such
issues are explicitly not something that Common Lisp seeks to address in the
base level of its standard. These were left to vendors and were
intended to be the subject of separated (perhaps layered) standards. They
are INAPPROPRIATE to standardize in a context where the space of interface
concerns cannot be known because each such interface concern creates a nuance
that cannot, a priori, be known.
In the future, there will also be voice and visual gesture interfaces,
and CL does not address those either. If you have Star Trek movies
over there, think of YES-OR-NO-P as an antique interface, like Scotty
uses in Star Trek IV, to talk to the bootstrap version of a system, in
order to get it into application mode where other interfaces, not
defined by the base layer, are available. It is IMPORTANT that Common Lisp
does not pretend to address those other layers because it will SURELY FAIL
to do them right and may trick implementors into thinking it has an answer
that works, when it does not... just as you have already been tricked into
thinking that YES-OR-NO-P is ever going to be the answer to the kinds of
issues you are raising.
I say again: The correct solution to this problem is simply to IGNORE the
presence of YES-OR-NO-P except for simple applications written in "federation
standard" (i.e., English), the like-it-or-not interchange language of the
modern world.
> So, I think, YES-OR-NO-P in its current state is not very useful in any
> program which intended for non-English user, who works with non-English
> keyboard mainly.
Yes, certainly. But that does not call for it to be fixed. It calls for it
to be deprecated. The space of tools required to really address the
non-English user is a space probably as large as the present language in its
entirety.
> IMHO it is not convinient, at least, because such user
> need to switch the keyboard to English and back every time he/she need
> reply on YES-OR-NO-P query.
This is just a bug in your implementation, brought on by your specific vendor
not caring about your locale. The language does NOT require this. PLEASE
distinguish LANGUAGE from IMPLEMENTATION. These are utterly different things.
> It is, of course, is not a problem, because
> such functionality can be implemented very easy. It is just a little
> inconvenience.
Yes, but once we start to address that, it only opens the question: what if
I want yes, no, or maybe? What if I want to answer "boy" or "girl" instead
of "yes" or "no"? What if I want to have option1/option2/Cancel? What if
I need voice input? What if I need it to handle 7bit ascii Russian? (I was
going to paste in some Russian but my newsreader doesn't have the characters
to do it... I might want to write Espa~nol or Fran,cais ... should we clutter
the language with support for these? It's very helpful to accept them.)
There are a LOT of issues one must address in order to have good LANGUAGE
support for Russian or even a much more English-like language such as German
or Spanish. It is fine for an application writer to shrug and say "well, I
don't really need all that extra" but it is not fine for a language writer
to do that. Probably that means we should have just left these things out of
CL, but it's been a "learning experience" for all of us, and we didn't do
everything personally. You and I just presently disagree on what the right
way to fix that is.
> If we spoke about an implementation of "international" functionality of ~R
> directive, I would try to offer a some leverage with ability to pass a
> list of user arguments to ~R that then could be passed to some callback
> function (that could be set by a programmer) to get a proper form for ordinal
> number.
This would get very messy, to the point that just using ~A or ~/ and
giving the right information would be better. Those capabilities
are already there.
And before considering Russian, consider even the simple mess that the
British and the Americans don't entirely agree on the meaning of the "English"
word "billion" so that detecting whether an error has occurred is
extraordinarily hard if you ever even hint that ~R's purpose might be
to satisfy localization constraints.
> Again, I don't speak that this functionality is needed. I think this
> is just some convenient tools in the language. If they were absent, nobody
> told about them. But, on the other hand, if they were added, why didn't they
> have done more extendable?
Because it was understood from the outset that (a) the language was not
seeking to be a translation tool and (b) doing it Right is very hard.
Doing translation is an art or a heuristic, but is not a deterministic
activity. CL is a language, and so seeks to be deterministic. These goals
come into conflict if the meaning of the linguistic terms is not simple.
There may even have been some US-bias in the design. For that I
apologize. But in fairness, the US *did* design the language and our
culture is, I think, due some small historical accomodation to keeping
its programs running while stretching to embrace the new global
market. It's not like the present definition of ~R really breaks existing
programs when compiled in Russian. Existing programs were ALREADY broken
because they do things like: (write-string "Hello World") instead of
_ _
(write-string "| |p|/|BeT M|/|pOBo| O"), even without worrying about what
the world is going to say in response. [Sorry about the character set
problem there. And I hope I didn't say anything offensive--I was just
working from online phrasebooks. :-]
> The more important thing is, of course from my point of view, ability to
> set a proper charset.
Again, an implementation issue. The standard cannot require this. Even in
a properly internationalized implementation, there are some very complex
issues about how to trade off true generality for efficiency. If we required
Unicode (or better), we might be keeping some implementations that don't
seek that market from being efficient. Even the input we saw from the
Japanese standards groups seemed to me to indicate that they were not going
to rush to make every implementation take their full pictogram character
set in every circumstance. I don't think we yet have the global agreement
to know what the right way to handle this is. In my opinion, and I'll even
say it stronger here because I do believe this strongly, in my considered
professional opinion, one must FIRST see some successful vendor-specific
attempts at this AND one must observe that all the vendors agree on a common
way of doing this before we go saying "this is the right way" and "this is
the wrong way" by putting something like this in the standard. At this
stage of our global-community-shared-cultural-understanding of this complex
situation, I believe we do not have the wisdom to lock in a single way to do
this and it would be VERY BAD to do so. This is NOT to say that I don't
understand your need. I'm just saying you are criticizing the wrong people
and so working against your own need. Talk to your VENDOR (by which I mean
either whoever sold you your lisp or whoever made the lisp, if it was "free").
It is their responsibility to help you at this point. The responsibility of
the language at this point is merely to not do things that would make a vendor
implementation non-conforming merely for wanting to help you.
> Without that functions for manipulating strings and
> characters don't work properly. So STRING-UPCASE for example doesn't not
> work with Russian in Lispwork 4.1.20 Personal Edition, CMUCL. There is
> SET-LOCALE function in Lispwork but only "C", "POSIX" and "*.ISO-8859-1"
> locales exist.
Tedious as it is, these are problems to report to individual vendors.
If this went to a language standards committee right now, you might get a
common definition, but it might be wrong. And that might mean everyone
diverged from the standard. And that would hurt the standard's credibility.
The process of consensus making is NOT fast. It is frustratingly slow
sometimes. But if you want it to go fast, make a layered standard that can
be discarded (if it's found to be wrong) without perturbing the underlying
CL standard. There is no motivation for the entire language to take on the
risk of someone calling the base language "bankrupt" just because someone gets
overly aggressive about addressing this complex issue and then later finds
they've made a mistake. But that doesn't mean no standard can arise. It
just means you shouldn't try to put everything under one label. No more so
than you should try to store all the data in your file system in a single file.
The file system is there so you can separate one program's data from another's.
Multiple layerable language standards are possible just so you can separate
one set of concerns from another.
> If my memory serves me, there are same situation in Allegro
> 6.x (i.e. SETLOCALE exists but number of localies is limited by
> C/POSIX/*.ISO-8859-1)? But because I don't have Allegro on my computer
> now, I can make a mistake here.
Again, vendor issues. And then once resolved, the community has to go get
the vendors to agree. But if you make them agree prematurely, some vendor
will be mad that it didn't get to pursue how it thought things should work.
As a consequence, it may feel commercially discriminated against. As a
further consequence, it may decide CL is no longer worth caring about as a
spec. And that result would be very very bad--worse even than the very
real problem you are having now.
> Again, It might be not a problem but just a little inconvenience.
> Because, I suspect that correspondent localies can be added to both
> Lispwork and Allegro. And it is not a very hard ever for such a beginner
> as me to implement a basic SETLOCALE functionality in CMUCL using existing
> Alien interface.
>
> I don't blame anybody or anything. I think that a great job was done with
> the standard. I can understand vendors who probably have had most of their
> customers in English-spoken countries. So there were not value reasons for
> them to harry up with implementation of functionality that was not part of
> the standard.
>
> Thank you and all others senders who reply on my message. I have been
> reading this newsgroup regulary enough and I have never seen before a
> discussion of that topic. But these little problems with locales were the
> one of the first thing which I had encountered at the very begining of my
> CL voyage. :) I sent my message driven by intention just to attract
> community's attention to this topic, but didn't blame anybody.
I think you've done an excellent job of doing this. I don't want you
to feel that I don't think you have a valid concern. I just want you to
direct your energies toward the place where they should go so that it does
the most good. Contacting each vendor and making sure they are on track to
do the right thing is a good idea. Creating a discussion group among users
and vendors about this issue might be good. There are many ways you could
proceed constructively. Don't assume people are not listening or caring.
But do be tactical about how to force this very slow process forward the
right way, rather than wishing the process were different.
> And excuse me, please, for my ... not very good English. :(
Your English is quite understandable and has not been a problem for me.
Even English speakers sometimes complain that my English is too verbose,
so I'll also apologize for MY not very good English in case it's a problem
for you to translate back. The problem may not be at your end. ;)
Thanks again for raising this issue, and I hope you'll feel free to cite
more examples for discussion. Even just knowing which functions and
functionalities are broken in Lisp by language issues (even if we don't
plan to fix them) is a service to the community...
Disclaimer: Of course, none of what I say should or should not be
fixed is the official statement of any committee. I used to be on the
(X3)J13 committee but no longer am. Even when I was on the committee,
I was not its spokesperson, and I most definitely am not now its
spokesperson. These are just my personal views throughout, and not the
official position of anyone but me... maybe not even always that.
Erik Naggum
| So, I think, YES-OR-NO-P in its current state is not very useful in any
| program which intended for non-English user, who works with non-English
| keyboard mainly.
Why, then, did you write the call to that function in the first place?
I see another case of blaming the language for failing to be convenient
_enough_ and trying to blame some cultural artifact that the _programmer_
has not been able to figure out is not going to do what he wants.
It is great that Common Lisp is usable by us "furriners", but when I was
faced with the inability of Allegro CL 4.3 to deal with case issues in
ISO 8859-1, I spent some time fixing this problem locally, and repeated
this for Allegro CL 5.0 so it would work in my application, which used
and required ISO 8859-1 to work properly. It was not particularly hard.
However, I did not attempt to make format control ~P work for Norwegian.
I did not use yes-or-no-p in the Norwegian user interface. I did not
expect a language I have learned and studied suddenly to become plastic
and turn into something it is not just because I wished for it.
I actually find it completely incredulous that otherwise seemingly smart
programmers suddenly get a case of "wishful thinking syndrome" and fail
to understand that a programming language is what it is. If the language
does not fulfull your childhood dreams, at least try to figure out if it
is actually blocking you from realizing them _with_ it. If so, drop it
and find another language that does not block your dreams. If, however,
the language just falls short of some egoistic "ideal" that you think you
have right to complain that the world does not fulfull for you, you have
a _much_ bigger problem than the failure of yes-or-no-p to speak Russian.
Programming is about making new things possible, about realizing dreams,
about _creating_ dreams. I get so fucking _tired_ of the whining losers
who expect languages and environments and computers in general to relieve
them of having to exert any effort at all to get what they want, and who
get _sore_ when the languages refuse to do their bidding. Sore losers
who fail to grasp that they world does not owe them a thing come out as
exceptionally demanding assholes who cannot tolerate that they have to do
some of the work themselves.
Common Lisp is one of the languages in the world that offer programmers
_so_ much for free already, but what happens? Again and again, whining
losers gang up on it for not offering them enough. Even thinking about
making something useful on their own instead of whining is beyond these
people, so it is all fault-finding instead of doing something new and
useful. This is probably the biggest difference between the Common Lisp
community and the Perl community: Give people a shitty language and they
expect nothing, so create what they need, but give people a great
language and they expect everything, so only pine for what they miss.
Internationalization and _real_ localization is very hard work. It is
not something you tack on as an afterthought, any more than security and
qualit is. If some standard function named yes-or-no-p does not satisfy
a Russian user, the only surprise should be that someone could even come
up with the idea that it should have.
If you have a problem with missing functionality in a programming
environment, there is actually a name for the solution to your problem:
It is called _programming_.
///
--
Duane Rettig
> Duane Rettig <du...@franz.com> writes:
>
> > As for yes-or-no-p et al, it is true that we have not implemented the
> > LC_MESSAGES category, but it is entirely possible. And I may be wrong,
> > but my reading of the definition of yes-or-no-p in the spec doesn't
> > preclude an implementor from basing either the message string or the
> > actual "yes"/"no" responses on the locale.
>
> I don't think the spec requires it, though how it would know what
> language it was in is slightly problematic. You have to know what
> language the question is being asked in OR you have to accept
> responses in multiple languages. If you're taking one-letter
> responses, it's not hard to imagine how a letter might have
> conflicting meanings depending on the language, though I don't know if
> that happens in practice.
My guess is that it does not. I'd be interested in knowing whether there
is any language out there whose "one-character representation" for "yes"
and "no" are the same letter. So _if_ y-or-n-p were set up to obey
localities, there would be no conflict.
However, are you saying that a "y" in one language is the same as the
equivalent "n" of another language? This would be consistent with your
statement that multiple-languages would need to be acceptible as
input. (I happen to disagree with this; it violates rules of least
surprise - if I accidentally hit the "s" key and that got accepted as
"yes" (via "si") then I would become pretty angry at such suprising
behavior).
> > As for the ~R format directive, I do agree that it is awkward to extend
> > individual pieces of format; we decided to make our locale extentions
> > general, using ~/ as our extension mechanism. The fact that ~/ was
> > available is to CL's credit re its extensibility.
>
> Part of the problem isn't just the desire to extend but the fact that
> what some people mean by "extend" is "redefine". Even if you knew a program
> was being run in a certain country by a certain user who needed certain
> interfaces localized, you don't know if ~R is being called for reasons
> relevant to where the program is run or independent of that. One should
> not confuse the notion of "providing a function that is known to vary in
> effect with localization" with the notion of "providing a function that
> someone WISHES had varied with localization but that programmers have
> already used in the full knowledge that it is not going to do that".
> "Upgrading" a program of the latter kind is really just "breaking" it.
> You're right that ~/ is the right answer; ~R is not only hard to extend
> but I think it would be improper to extend it. Better to just ignore it
> if you don't like it just as it's spec'd now.
We had these same conversations at Franz, and our conclusions were the
same. And as for CL functions that might be candidates for
locale-sensitivity (STRING<, for example), we added new functionality
rather than try to extend the CL functions (thus, for example, our version
of STRING< remains ASCII centric).
Duane Rettig
> * Duane Rettig <du...@franz.com>
> | Well, as a native English speaker, I understand that English is an
> | important language used in computer science, but for the very reason you
> | cite I do not want to assume too much.
>
> Each field has only one common language. Any attempt to add more will
> split the field. It is already a problem that research published in
> French and German are unavailable to the rest of the computer science
> community.
Unless they are translated. My view about language commonality is that
if there is a field developing in more than one language, either they will
develop separately in parallel (with possible diversity) or they will
converge with cooperative efforts. And if specific research in one group
is important enough for the other group, it will eventually get translated
to the other group's language. Perhaps one group will become stronger than
the other, thus apparently "winning" and shutting out the other group (an
unfortunate consequence). An example of such a successful effort is the
US and Russian space programs, which have after all developed largely in
parallel, with only limited cooperation, and with different emphases, and
yes, of course, with much redundant effort, but also with no clear winner,
because the emphases have been different.
> | Whether non-native-English speakers (or more importantly, whether
> | non-English speakers) accept English-only interfaces is going to be up to
> | you/them.
>
> Fluency in English is a sine qua non in computer science. Programmers
> who want translated software tools and programming languages in their
> native tongue will forever remain incompetent tinkerers. Only one
> company on the planet thinks this is a good idea.
I won't make this assumption, again due to my own English-centeredness.
However, for as long as my Company has existed we have had requests,
especially in Japanese and French communities, to provide the kinds of
things we're discussing here. The requests vary widely, from simple
character-set capabilities to message translation tools. I don't remember
anyone ever having asked for actual CL name translations, but most of the
example problem descriptions we receive which were developed in a non-English
country are written with objects and predicates matching that country's
native language. And several of our developers have had to learn Japanese
in order to make any in-roads into the Japanese markets. We even have a
salesperson who is Japanese who also serves as a translator between our
Japanese customers and us.
The above paragraph is not intended to refute or question a claim of _use_
of English in computer science, but only a need for _fluency_ in it.
All of our customers use "cdr" and "cons" just like the rest of us (are those
English words? :-), and the real problem is in communicating the programming
concepts within the communities within which these programmers are
operating. If a Japanese programmer decides to name a function with Kanji
characters, do we force him to translate the name to English in order to
help him solve a bug? The question is not rhetorical; every vendor has to
answer it for themselves. If the answer is "yes", then some of that market
is shut out. If the answer is "no", then the vendor must learn at least
the characterset of the customer's language. We chose the "no" answer.
> | And the acceptability of such English-only interfaces are likely to vary
> | according to the audience; whether to the programmer or to the end-user.
>
> End-users should _obviously_ be served with natural language interfaces.
> I do not see how what I have said could be construed to have been arguing
> against natural-language end-user interfaces. Quite the contrary, I have
> made several points about how software that needs to talk to real users
> must be tailor-made in each language. How could this possibly be taken
> to mean that we should _not_ make natural-language interfaces for users?
I am agreeing with your points. What I think we may disagree on is whether
a programmer can be an end-user as well. Contrary to what I have heard
others say on this newsgroup about CL being a programming language which
requires an elite group of programming skills, I have seen a wide
spectrum of users within our customer base, with widely varying degrees
of fluency in English as well. So I view the spectrum of programmer to
end-user not as a dichotomy, but as a continuum, with a small number of the
"elite" programmers who know the CL spec intimately, a larger group of
users who might look at a screen-saver or play a game without even knowing
that they were using CL, and a larger still group of programmer/user types
who fall somewhere in the middle.
So the real point of issue is within this center of the spectrum, where
we might ask the question "How much do we require the average programmer
to know English in order to program in Common Lisp?" I think that the
current answer is "They must know English", but I think also that it
_should_ be the case that "They need not know English, only Common Lisp".
Kent M Pitman
> Kent M Pitman <pit...@world.std.com> writes:
>
> > Duane Rettig <du...@franz.com> writes:
> >
> > > As for yes-or-no-p et al, it is true that we have not implemented the
> > > LC_MESSAGES category, but it is entirely possible. And I may be wrong,
> > > but my reading of the definition of yes-or-no-p in the spec doesn't
> > > preclude an implementor from basing either the message string or the
> > > actual "yes"/"no" responses on the locale.
> >
> > I don't think the spec requires it, though how it would know what
> > language it was in is slightly problematic. You have to know what
> > language the question is being asked in OR you have to accept
> > responses in multiple languages. If you're taking one-letter
> > responses, it's not hard to imagine how a letter might have
> > conflicting meanings depending on the language, though I don't know if
> > that happens in practice.
>
> My guess is that it does not. I'd be interested in knowing whether there
> is any language out there whose "one-character representation" for "yes"
> and "no" are the same letter. So _if_ y-or-n-p were set up to obey
> localities, there would be no conflict.
>
> However, are you saying that a "y" in one language is the same as the
> equivalent "n" of another language?
Yes, this was the case I worried about.
> This would be consistent with your
> statement that multiple-languages would need to be acceptible as
> input. (I happen to disagree with this; it violates rules of least
> surprise - if I accidentally hit the "s" key and that got accepted as
> "yes" (via "si") then I would become pretty angry at such suprising
> behavior).
Well, perhaps. But it's already common for Space to be accepted as a
'y' substitute, and Rubout/Delete for 'n'. I certainly agree with your
concern, but I also thiuk the issue is orthogonal and that implementations
might reasonably have separate degrees and mechanisms for controlling
such safeguarding.
Jean-François Brouillet
<er...@naggum.net> wrote:
Why Naggum thinks that my renaming of the "c" with "cedilla" letter
as an attack against Naggum himself is any _interesting_ at all is pure
mystery to me.
Why would attacking Naggum be _interesting_ ? To whom ?
If attacking Naggum only came from the "bile-overflow" department, then
people may sympathise, but then simply move on. Is Naggum such an important
<plug-some-emphatic-title> that the whole 21st century has to be grateful
forever for having been blessed by the smallest Naggum thought?
| Naggun standard canned reply to this is going to be along the
| lines that _I_ need medical treatment because _I_'m exposing
| personality disorders. And saying <whatever, your-call> about
| him is simply a sign of me being <brain-under-powered> or whatever
| he fancies those days.
|
| Isn't this entire Naggum-thing pathetic?
Naggum, of all your posts, about 10% have real value. And I mean _real_.
Unfortunatenly, the other 90% is utter non-sense, bullshitting arrogance
of the clever among the cleverest who deigns blessing the poor crowd
with his infinite wisdom.
Naggum, enough is too much. There are real contributors to c.l.l, and
your signal/noise ratio is way too low. Nobody _cares_ about how you
feel, and whether such sub-population deserves to live/die/flourish/perish
according to St Naggum.
Make us a favor: give us a break: stop posting 10 times a day to c.l.l
(as if you had no other useful work to do). By restraining yourself to
core issues, and avoiding raw, unwarranted, blunt, uncalled-for opinions
you will contribute to making c.l.l a better place.
I, for one, would have happily carried on lurking c.l.l for quite a while
if it werent' for this and the previous message.
> Get help, OK?
How much do I owe you, Doctor, for such an amazing diagnostic?
Do you accept Euros ?
> ///
--
Jean-François Brouillet
irt
<ve...@mac.com> wrote:
>Naggum, enough is too much. There are real contributors to c.l.l, and
>your signal/noise ratio is way too low. Nobody _cares_ about how you
>feel, and whether such sub-population deserves to live/die/flourish/perish
>according to St Naggum.
There are two effective ways to deal with St Naggum
1. Ignore all his messages or kill file him
2. Annoy him enough that he kill files you.
I have chosen the latter option since some of St Naggum's posts are
deliciously funny.
For example, the post in which he accused you of belligerence ( and
misspelled the word to boot ! ) was wonderful. That is like the blast
furnace calling the cigar smoky !
Kaz Kylheku
>"Ouf! Depuis le temps que j'attendais ça, je me suis payé le Naggum!"
>
>--
>Jean François Brouillet
> ^
> +--- this letter is called "Fuck You! Loser"
That's what you *think* it says, but to me, it spells: ``I'm an idiot
who doesn't understand that one must use only ASCII when posting to
English-language Usenet newsgroups, both in the body and headers''.
You might think that the glyph produced by this character is the
letter c with a diacritical mark under it known as a cedilla.
But on my terminal, it produces a little picture of a donkey.
If I were reading a French newsgroup, I would, of course, rectify that.
Aleksandr Skobelev
>
>> Well, I don't think that there is need to intuit the language of
>> the query to interpret replies properly in YES-OR-NO-P. Probably,
>> it is enough just to allow to set strings for yes/no replies (for
>> example through some specail variables called *yes-reply*,
>> *no-reply*...) and leave the problem of language synchronization in
>> query/reply for programmer.
>
> I don't agree that this would make the language stronger.
I'm not sure that I understand well what it means "to make language
stronger". But if there is possibility for seting a query string in
YES-OR-NO-P why don't add possibility for setting a reply string? At
least, it looks more regular and consistent for me. It is a far too
much simpler than to leave for vendor to guess how will "yes"/"no"
replies look like. And it is give to programmer a more freedom.
So, I must admit here that I don't understand your adherence to the
"vendor's generated replies" variant.
> First, you are failing to distinguish, as I asked you do, things that the
> language keeps from happening from things the language merely does not
> force to happen. The language definition does not say an implementation
> should not do this. HOWEVER, if the language definition *did* do this,
> it would be a weaker language.
It might be. I'm not sure that I understood your query in your
previous message and I'm not sure that I understand it now. If return
back ang use "omission"/"bad foundation" terminology then I don't see
any "bad foundations" in ANSI CL standard which concerned localisation
problem. But I think that there are some "omissions" in the standard
(that could be done intentionally). (I don't tell about YES-OR-NO-P or
~R here. They both can be left just for historical reasons and there
is ~/ directive also as you wrote below.) IMHO the current version of
the standard just leave to a vendor the decision to support
international languages or not. Below is just a quote from
http://www.xanalys.com/software_tools/reference/HyperSpec/Body/13_aa.htm:
"Common Lisp ALLOWS an implementation to provide support for
international language characters as well as characters used in
specialized arenas (e.g., mathematics)."
I would think that international standard should REQUIRE such
behaviour, because any vendor now has right don't support
international languages and still claims that his implementation is
conformed with ANSI CL standard. Am I wrong?
Isn't the follow simpler?
(setf *yes-reply* '("Si'" "si'" "s"))
(setf *no-reply* '("No"))
...
(when (yes-or-no-p "Salir?") (exit))
* Salir? (Si'/No) No
...
(setf *yes-reply* '("Yes" "yes" "yep"))
...
(when (yes-or-no-p "Exit?") (exit))
* Exit? (Yes/No) Yes
No need in any heuristics here. Well, only one is needed: which word
from yes/no-replies list do we print in our query. I offer to print
first. :)
> The thing to understand is that these are *interface* issues and
> that such issues are explicitly not something that Common Lisp seeks
> to address in the base level of its standard. These were left to
> vendors and were intended to be the subject of separated (perhaps
> layered) standards. They are INAPPROPRIATE to standardize in a
> context where the space of interface concerns cannot be known
> because each such interface concern creates a nuance that cannot, a
> priori, be known.
>
> In the future, there will also be voice and visual gesture
> interfaces, and CL does not address those either. If you have Star
> Trek movies over there, think of YES-OR-NO-P as an antique
> interface, like Scotty uses in Star Trek IV, to talk to the
> bootstrap version of a system, in order to get it into application
> mode where other interfaces, not defined by the base layer, are
> available. It is IMPORTANT that Common Lisp does not pretend to
> address those other layers because it will SURELY FAIL to do them
> right and may trick implementors into thinking it has an answer that
> works, when it does not... just as you have already been tricked
> into thinking that YES-OR-NO-P is ever going to be the answer to the
> kinds of issues you are raising.
>
You want too much from such a simple function as YES-OR-NO-P. :)
> I say again: The correct solution to this problem is simply to
> IGNORE the presence of YES-OR-NO-P except for simple applications
> written in "federation standard" (i.e., English), the like-it-or-not
> interchange language of the modern world.
>
>> So, I think, YES-OR-NO-P in its current state is not very useful in
>> any program which intended for non-English user, who works with
>> non-English keyboard mainly.
>
> Yes, certainly. But that does not call for it to be fixed. It
> calls for it to be deprecated. The space of tools required to
> really address the non-English user is a space probably as large as
> the present language in its entirety.
>
>> IMHO it is not convinient, at least, because such user need to
>> switch the keyboard to English and back every time he/she need
>> reply on YES-OR-NO-P query.
>
> This is just a bug in your implementation, brought on by your
> specific vendor not caring about your locale. The language does NOT
> require this. PLEASE distinguish LANGUAGE from IMPLEMENTATION.
> These are utterly different things.
Is it a bug or just behaviour allowed by the standard? I'm not sure.
> ...
>> If we spoke about an implementation of "international"
>> functionality of ~R directive, I would try to offer a some leverage
>> with ability to pass a list of user arguments to ~R that then could
>> be passed to some callback function (that could be set by a
>> programmer) to get a proper form for ordinal number.
>
> This would get very messy, to the point that just using ~A or ~/ and
> giving the right information would be better. Those capabilities
> are already there.
Aga! I have missed the ~/!
>
> And before considering Russian, consider even the simple mess that
> the British and the Americans don't entirely agree on the meaning of
> the "English" word "billion" so that detecting whether an error has
> occurred is extraordinarily hard if you ever even hint that ~R's
> purpose might be to satisfy localization constraints.
>
>> Again, I don't speak that this functionality is needed. I think
>> this is just some convenient tools in the language. If they were
>> absent, nobody told about them. But, on the other hand, if they
>> were added, why didn't they have done more extendable?
>
> Because it was understood from the outset that (a) the language was
> not seeking to be a translation tool and (b) doing it Right is very
> hard. Doing translation is an art or a heuristic, but is not a
> deterministic activity. CL is a language, and so seeks to be
> deterministic. These goals come into conflict if the meaning of the
> linguistic terms is not simple.
>
> There may even have been some US-bias in the design. For that I
> apologize.
No need in any apologize here. It is very explainable and naturally.
> But in fairness, the US *did* design the language and
> our culture is, I think, due some small historical accomodation to
> keeping its programs running while stretching to embrace the new
> global market. It's not like the present definition of ~R really
> breaks existing programs when compiled in Russian. Existing
> programs were ALREADY broken because they do things like:
> (write-string "Hello World") instead of
> _ _
> (write-string "| |p|/|BeT M|/|pOBo| O"), even without worrying about
> what the world is going to say in response. [Sorry about the
> character set problem there. And I hope I didn't say anything
> offensive--I was just working from online phrasebooks. :-]
Nothing offensive. I must admit that I didn't understand at the first
glance. Only when I looked at it more carefully. :) It should be
_
(write-string "| |p|/|BeT, M|/|p!")
or with transliterating with 7-bit ASCII ('i' as in "keep")
(write-string "Privet, Mir!") :)
I don't think that standard can't require from implementations an
existence of leverage for manipulating with charsets and other
locales' settings. There is setlocale() API in POSIX.1 standard. IMO
it works well enough. If we talk about efficiency then I think that the
COMPLEX and BIGNUM types are not very efficient ones but they are in
standard because, as I understand, it is convinient and a "right
thing".
I'm not criticizing anybody. A great job has been done with the
standard. But there are some "omissions" in the one, which (from my
point of view) don't allow to call it "a true international standard"
just because it give vendors a right to ignore needs of
"international" users. But because this standard doesn't prevent
vendors to provide a support for international languages, I would
offer to call it "A SOFT INTERNATIONAL STANDARD". :)
After all the language is really wonderful (ever it is not an
ideal). :) So, lets talk with vendors...
> ...
Aleksandr Skobelev
>
> ...
>
> We had these same conversations at Franz, and our conclusions were the
> same. And as for CL functions that might be candidates for
> locale-sensitivity (STRING<, for example), we added new functionality
> rather than try to extend the CL functions (thus, for example, our version
> of STRING< remains ASCII centric).
>
So, any non-English string won't be compared correctly?
Duane Rettig
Actually, the 8-bit Allegro CL images coallate via latin-1 (a superset of
ASCII) and the 16-bit images coallate via Unicode. Essentially STRING<
and STRING> compare the char-codes of each character. But since ASCII or
Unicode ordering may not be precisely what you want, we provide
functionality to aid in user-customizable orderings. See
http://www.franz.com/support/documentation/6.1/doc/iacl.htm#collation-1
Kent M Pitman
> Duane Rettig <du...@franz.com> wrote:
> >
> > ...
> >
> > We had these same conversations at Franz, and our conclusions were the
> > same. And as for CL functions that might be candidates for
> > locale-sensitivity (STRING<, for example), we added new functionality
> > rather than try to extend the CL functions (thus, for example, our version
> > of STRING< remains ASCII centric).
> >
>
> So, any non-English string won't be compared correctly?
Heh. Is there a requirement that a string contain valid language?
What's an example of a "non-English string"?
I thought locales were an abstraction about the context in which a given
set of characters were to be interpreted, not a representational issue.
Failing to do it thus would, I think, leave you in a serious quandary
about how to deal with a string containing multiple languages in the
same string, such as the hyphenated last name of a person whose parents
are from different (linguistically incompatible) countries.
STRING< and friends are intended to compare strings in a
natural-language-independent way, according to an arbitrary sort order
that is constrained only by the A-Z/0-9 constraints enumerated the
spec. From an internationalization point of view, this is all
subprimitive and to be ignored.
Proper internationalization would, IN ANOTHER PACKAGE, offer the right
meaning.
My understanding is that a properly localized string ordering function
for a number of locales would require multi-char strings like
"MacDonald" to sort ahead of "Maas" because "Mac" has some special
priority in some locales. The definition of STRING< in the ANSI CL
spec does not permit this because it requires the comparisons to go
character-wise, not in groups.
Will Deakin
> My understanding is that a properly localized string ordering function
> for a number of locales would require multi-char strings like
> "MacDonald" to sort ahead of "Maas" because "Mac" has some special
> priority in some locales. The definition of STRING< in the ANSI CL
> spec does not permit this because it requires the comparisons to go
> character-wise, not in groups.
(sigh). Speaking from personal experience -- this is an absolute
nightmare if you try and compile things like telephone books.
:)w
Kent M Pitman
> "Common Lisp ALLOWS an implementation to provide support for
> international language characters as well as characters used in
> specialized arenas (e.g., mathematics)."
>
> I would think that international standard should REQUIRE such
> behaviour, because any vendor now has right don't support
> international languages and still claims that his implementation is
> conformed with ANSI CL standard. Am I wrong?
People will differ on how to answer this, but I think the most light will
be shed on this complex issue if I take the most extreme point of view, so
I will just boldly and for purposes of a friendly argument say:
Yes.
I don't know if it will help or hurt to allude to the cultural divide
between the capitalist/libertarian state and the socialist/communist state,
but I'm going to try to allude to this just in case. It MAY actually be
that because of the historical difference between your country and ours,
you see this issue differently than we do. I'm not going to try to assert
rightness or wrongness of either system here, but rather use the differences
in point of view to show how, in context (i.e., in a situation where you take
the rightness of one or the other world model as an axiomatic given),
the answer to your question above might come out different.
I sometimes refer to the language design community as the "benevolent state"
making all kinds of rules for how people should behave. But rules are not
implementations. Making a rule that says "everyone will be fed" does not
make them fed. What makes them fed is feeding them. Rules do get broken.
And when you make a rule that all CL implementations must provide feature X,
SOMETIMES you get a lot of implementations with feature X, and other times you
get SOME conforming implementations with feature X and some non-conforming
(i.e., would-be conforming) implementations without feature X.
Certainly we tried in the design of the language to require a LOT of vendors.
We though this would stretch the set of things vendors would do. But we
could not, through our votes, make vendors have infinite money/patience,
and so there is a limit to what we can do.
For what it's worth, I call this model of language design, where the people
expect all implementations to implement the standard, and the standard is
dictated by philosophically inclined people without regard to to cost, the
"socialist" design principle. I think it has traditionally worked, but mostly
because it used to be that vendors had large amounts of money and the bulk
of programmer resources. Over time, the wealth and programmer talent has
moved a lot to the market. Increasingly, over time, I have felt that users
should look not to governmental bodies but to the entreprenuerial marketplace
for solutions. I call this a "capitalist" design principle.
The good thing about the socialist model is that everyone doing CL has
certain properties. The bad thing is you ahve created a bar so high
that not everyone can do a CL. The good thing about the capitalist model
is that more people are offering CL, but the bad thing is that there are
more differences in what that means.
I like the capitalist model better these days, though I'm glad we went
through the other model getting to where we are because it gives us a large
base to build upon. I think the capitalist model acknowledges that some
parts of the market don't NEED all that might be required, and so it allows
partial implementations to compete in places where they match features offered
with features requiresd.
Suppose we *did* require every CL implementation to have international
char set support and suppose I had an application that didn't need it.
I might *still* buy the same lisp to do it, the only thing that would
be changed is that it wouldn't be marketed as a conforming CL under
your proposed standard because it had no support for the feature I
didn't need. By contrast, if I need international char set support
now and some implementations don't have it, I don't just buy the
deficient implementation EVEN IF it satisfies the spec. An
implementation, to get bought by me, needs to satsify not only
standards but MY requirements.
So when the dust all settles, I think the only question which materially
remains is this: to what extent are vendors encouraged by the withholding
of the word "conforming" if you increase the set of requirements vs. to what
extent is the community fragmented by denying the word "conforming" in cases
where it will not be met.
For example, we do not require a compiler right now in CL. Most
implementations provide one but it's left to the market. We could
require one. But what would that serve but to tie the hands of
vendors? A vendor who has enough customers without a compiler might
as well continue in that market if they're happy. It steals nothing
from anyone else, and the sense of community size is enlarged by our
embracing that activity. To make an ivory tower that no one can climb
might raise our level of respect among some, but it might exclude
others. I just don't see doing it. But I can understand how another
might think differently. In the end, I think it has to come down to
differences of political theories about how to motivate people. Just
as in business the Theory X/Theory Y debate rages about whether
carrots held in front of employees or sticks waved behind them are
better ways to motivate good work. The fact is that there is no clear
answer. At least with employees, you can come up with solutions on a
case-by-case basis. With standards, the complication is that you
either do or don't conform...
- - - -
Moving on, my words are the double-indented ones here:
> > In that case, how would you distinguish between whether
> > (yes-or-no-p "Exit?") and (yes-or-no-p "Salir?") producing:
> >
> > Exit? Salir?
> > vs
> > [Yes] [No] [Si'] [No]
> >
> >
> > (english) (spanish)
> >
> > The heuristic guessing of language (especially based on a small number of
> > letters) would be impossible to do reliably. Certainly it would not be
> > able to tell whether to do even something like:
> >
> > Comer? Comer?
> > vs
> > [Si'] [No] [Sim] [Na~o]
> >
> >
> > (spanish) (portuguese)
> >
> > much less someting like this :) ...
> >
> > 42? 42?
> > vs
> > [Yes] [No] [HIja'] [ghobe']
> >
> > (federation standard) (klingon)
> >
>
> Isn't the follow simpler?
>
> (setf *yes-reply* '("Si'" "si'" "s"))
> (setf *no-reply* '("No"))
> ...
> (when (yes-or-no-p "Salir?") (exit))
> * Salir? (Si'/No) No
> ...
> (setf *yes-reply* '("Yes" "yes" "yep"))
> ...
> (when (yes-or-no-p "Exit?") (exit))
> * Exit? (Yes/No) Yes
>
> No need in any heuristics here. Well, only one is needed: which word
> from yes/no-replies list do we print in our query. I offer to print
> first. :)
Actually, the part about what to print is the whole thing I was trying
to get to. It's more complex than that. You're again assuming that the
choices are only "print" / "don't print". What if another interface
shows all the choices? That is, it shows
To reply yes, enter one of: Si', si, s
To reply no, enter one of: No, n
In some cases, people would want to provide a different list if they thought
someone would see it than if they didn't. For example, I might use
(... "si", "si'", "s'i" ...)
if it were not to be presented, but (a) some users would be offended/confused
to see these stupid presentations of accents and I might want to suppress
them (allowing fewer possible responses) if I thought they would be seen
than if I thought not, and (b) some users would be very confused by "si" since
it means "if". A lazy user might write "si" to mean "si'" if prompted for
"si'" or "no", but no user would want to see "si" because it would suggest
that you were saying "reply yes (or if) or no".
So what I'm saying is that your remark about "print" is the only
question to be asked, and I'm assuming it's a more complex space.
That is, that the question of what to print in a dialog is only the
tip of the iceberg. Rather than patch the TITANIC-YES-OR-NO-P
function to ferry passengers another day, I'd rather it sink in the
icy waters of the north atlantic (though, of course I'd send someone
to pick up the people lifeboats) and that a better replacement be
built.
> > In the future, there will also be voice and visual gesture
> > interfaces, and CL does not address those either. If you have Star
> > Trek movies over there, think of YES-OR-NO-P as an antique
> > interface, like Scotty uses in Star Trek IV, to talk to the
> > bootstrap version of a system, in order to get it into application
> > mode where other interfaces, not defined by the base layer, are
> > available. It is IMPORTANT that Common Lisp does not pretend to
> > address those other layers because it will SURELY FAIL to do them
> > right and may trick implementors into thinking it has an answer that
> > works, when it does not... just as you have already been tricked
> > into thinking that YES-OR-NO-P is ever going to be the answer to the
> > kinds of issues you are raising.
> >
>
> You want too much from such a simple function as YES-OR-NO-P. :)
And here I thought the same of you. :)
> >> IMHO it is not convinient, at least, because such user need to
> >> switch the keyboard to English and back every time he/she need
> >> reply on YES-OR-NO-P query.
> >
> > This is just a bug in your implementation, brought on by your
> > specific vendor not caring about your locale. The language does NOT
> > require this. PLEASE distinguish LANGUAGE from IMPLEMENTATION.
> > These are utterly different things.
>
> Is it a bug or just behaviour allowed by the standard? I'm not sure.
It is a conforming behavior.
However, it is still a bug in the vendor implementation.
Not because of the standard, but because of common sense (in the absence
of a standard that requires you not to use common sense).
> Aga! I have missed the ~/!
:-)
> ...
> > But in fairness, the US *did* design the language and
> > our culture is, I think, due some small historical accomodation to
> > keeping its programs running while stretching to embrace the new
> > global market. It's not like the present definition of ~R really
> > breaks existing programs when compiled in Russian. Existing
> > programs were ALREADY broken because they do things like:
> > (write-string "Hello World") instead of
> > _ _
> > (write-string "| |p|/|BeT M|/|pOBo| O"), even without worrying about
> > what the world is going to say in response. [Sorry about the
> > character set problem there. And I hope I didn't say anything
> > offensive--I was just working from online phrasebooks. :-]
>
> Nothing offensive. I must admit that I didn't understand at the first
> glance. Only when I looked at it more carefully. :) It should be
> _
> (write-string "| |p|/|BeT, M|/|p!")
>
> or with transliterating with 7-bit ASCII ('i' as in "keep")
> (write-string "Privet, Mir!") :)
Yes, I figured there was some kind of transliteration one could do but I
couldn't find a dictionary of character mappings. Thanks.
So the name of the space station "Mir" means "World" then?
> I don't think that standard can't require from implementations an
> existence of leverage for manipulating with charsets and other
> locales' settings. There is setlocale() API in POSIX.1 standard. IMO
> it works well enough.
Not that CL requires the use of Posix.
> If we talk about efficiency then I think that the
> COMPLEX and BIGNUM types are not very efficient ones
Are you comparing them to FIXNUMs and FLOATs, which are faster because they
require less, or are you comparing them to other languages that have better
ways of managing complex numbers of arbitrary precision integers. I count
efficiency as meaningful only in the context of "same computational goal".
Saying that it takes longer to add 100000000000000000000000000 and
100000000000000000000000000 than it does to add 1+1 is certainly true.
Saying, though, that such a bignum addition is inefficient doesn't seem fair
unless your offering a way of computing that same value more efficiently.
> but they are in standard because, as I understand, it is convinient
> and a "right thing".
It's provided to allow a flexibility that Lisp was already used to offering
and that it might as well satisfy. I have no real problem with BIGNUM, but
I do think the problem with COMPLEX is that it's cartesian, and that leads
to a few minor glitches becuase it precludes other solutions. Oh well.
> I'm not criticizing anybody. A great job has been done with the
> standard. But there are some "omissions" in the one, which (from my
> point of view) don't allow to call it "a true international standard"
> just because it give vendors a right to ignore needs of
> "international" users. But because this standard doesn't prevent
> vendors to provide a support for international languages, I would
> offer to call it "A SOFT INTERNATIONAL STANDARD". :)
You could look at ISO ISLISP. I don't recall it having any more strong a
requirement and, by the way, it was produced by an international
committee, much more recently. ;)
> After all the language is really wonderful (ever it is not an
> ideal). :) So, lets talk with vendors...
I'm sure when you get done with them, they'll see reason.
Aleksandr Skobelev
> ... Below is just a quote from
> http://www.xanalys.com/software_tools/reference/HyperSpec/Body/13_aa.htm:
Proper link is
http://www.xanalys.com/software_tools/reference/HyperSpec/Body/sec_13-1-1.html
Kent M Pitman
Not to mention if you try to USE such a telephone book.
All that work just to confuse people...
Kent M Pitman
> Aleksandr Skobelev <holy...@mail.ru> wrote:
> > ... Below is just a quote from
> > http://www.xanalys.com/software_tools/reference/HyperSpec/Body/13_aa.htm:
>
The "Body/13_aa.htm" reference is the more compact URL used by
versions 5 and up of the CLHS, all names for which work even in an DOS
file system. (Section numbers never went above 26, so I used a for .1,
b for .2, etc. so 13_aa is 13.1.1 ...)
But you're right, Xanalys has a pre-v5 CLHS on its web site.
Erik Naggum
| Why Naggum thinks that [...]
I did not think that. That you think so based on my response is _very_
interesting. You are not smart enough to understand that you were
deliberately tricked into revealing your real position and purpose with a
response that would feel hostile only if _you_ were a bad person. Thank
you for choosing the kind of response that leaves no doubt about you.
| Why would attacking Naggum be _interesting_ ? To whom ?
Good. You are defending yourself, now. This is very good evidence of
_conscious_ wrong-doing on your part. You are a very bad person, which I
wanted you to come out and tell us yourself, and you did, admirably.
Your insistence on talking about me just because I point out that your
considerable personality disorders are (sarcastically) _interesting_ is
extremely revealing. I can only thank you for relieving me of any need
to demonstrate how you are a very bad person. And you will continue to
provide us with more evidence of your very bad character, if you are the
character I judge you to be. Go ahead, now.
| If attacking Naggum [...]
Get psychiatric help, Jean-François Brouillet. You need it. This is
obvious to me now, and it will be obvious to everyone else in a short
while. Please keep up the self-incrimination for the benefit of those
who might still think that you could be normal, decent human being.
///
--
Erik Naggum
| So, any non-English string won't be compared correctly?
_Please_ try to understand there is no _one_ correct way to compare
strings. Monoculturalism is simply wrong. That is why one chooses
technical specifications that have arbitrary, but very predictable
results. Making string< attempt to do culturally sensitive string
comparisons would _always_ be wrong, because it is not specified to do
that, was never intended to do that, and should never be intended or
specified to do that if language designers do their job. The only
reasonable way to do string< is to do it with repeated char<, which can
only be done as < on char-code of the two characters (in practice, with
machine less-than operations on the internal representation of the
character object). In Common Lisp, that is precisely what it does.
The only _correct_ way to do culturally sensitive sorting is to maintain
a collation information string in addition to the "data" string. If you
are unwilling to do this work, whoever employed you should get a refund,
and if you did not know, whoever you paid for your education should be
prepared to give you a refund, unless he demonstrated that you failed to
do what you were told.
So here is a hint: If you want to compare two strings with culturally
sensitive contents, you need to know: which language both are in, how to
convert strings of that language into collation information strings, and
then compare the result with string<. Do _not_ try to roll this into one
function or make assumptions about the language in use. And _please_
note that string< does not work for English, either. English is _not_
spelled correctly only using ASCII.
Why are you behaving as if you are _envious_ of the fact that Common Lisp
happened to be defined in the United States? Nobody forces you to use
the functions that do not fill your needs. Please quit making it anybody
else's problems -- just go implement what you think is right. (Whether
you share it with others afterwards is not for me to suggest, but if you
are concerned with the proper sorting of your natural language, it would
seem reasonable to expect you to publish it, for pay or not.)
///
--
israel r t
>| Why Naggum thinks that [...]
>
> I did not think that. That you think so based on my response is _very_
> interesting. You are not smart enough to understand that you were
> deliberately tricked into revealing your real position and purpose with a
> response that would feel hostile only if _you_ were a bad person. Thank
> you for choosing the kind of response that leaves no doubt about you.
Try olanzapine 20 mgs daily
http://www.priory.com/focus3.htm
Erik Naggum
| But if there is possibility for seting a query string in YES-OR-NO-P why
| don't add possibility for setting a reply string? At least, it looks
| more regular and consistent for me. It is a far too much simpler than to
| leave for vendor to guess how will "yes"/"no" replies look like. And it
| is give to programmer a more freedom. So, I must admit here that I don't
| understand your adherence to the "vendor's generated replies" variant.
Just define a new function that does what you think it should do. Why is
this so hard for you to accept? Why must you complain that somebody else
has done something that is satisfactory for them?
Just _do_ it! Quit your useless whining and write specifications for the
functions you need, then implement them. That you cannot get it for free
is not anybody else's problem.
If the conclusion is that Common Lisp is unsuitable for international
applications without _additional_ localization support, that would be a
point from which we could progress. If people complain endlessly that
what it does is _wrong_, we have no point from which progress can be
made, because some people are happy with what it does and do _not_ think
it is doing anything wrong, so you would effectively secede in order to
get _your_ natural-language support. This is insane.
Write a white paper on how to write properly localized Common Lisp code
if you are _actually_ concerned about this, not just about hearing
yourself whine in public. Deliver a paper at a conference, get people
who have worked in this field for years to help you if you want to have
the work done. Be prepared to see that your particular culture becomes
"one of many" without privileges, and be prepared to understand that
American English is _not_ privileged today, either. There is nothing
here to whine about, just useful work that needs to be done. Just Do It.
If you do not want to do the work, please let us know. A good way to do
this would be keep whining uselessly about things you do not understand.
///
--
Aleksandr Skobelev
>
> I don't know if it will help or hurt to allude to the cultural divide
> between the capitalist/libertarian state and the socialist/communist state,
> but I'm going to try to allude to this just in case.
...
[
Here were thoughts about socialist/capitalist models of language
development. I removed them after very long thoughts because of their
size.
Definitly, Kent, you should write a short resume after every such a tale
which resume could be used in replies by yours correspondents.
] :)
It was very interesting.
OK. I see your point. I can not tell that I agree with it absolutly (may
be I have to read it again) but I admit that it at least have a right for
a life. :)
...
>>
>> Isn't the follow simpler?
>>
>> (setf *yes-reply* '("Si'" "si'" "s"))
...
>>
>> No need in any heuristics here. Well, only one is needed: which word
>> from yes/no-replies list do we print in our query. I offer to print
>> first. :)
>
> Actually, the part about what to print is the whole thing I was trying
> to get to. It's more complex than that. You're again assuming that the
> choices are only "print" / "don't print". What if another interface
> shows all the choices? That is, it shows
>
...
> So what I'm saying is that your remark about "print" is the only
> question to be asked, and I'm assuming it's a more complex space.
> That is, that the question of what to print in a dialog is only the
> tip of the iceberg. Rather than patch the TITANIC-YES-OR-NO-P
> function to ferry passengers another day, I'd rather it sink in the
> icy waters of the north atlantic (though, of course I'd send someone
> to pick up the people lifeboats) and that a better replacement be
> built.
OK. Let it sink. :)
Definitly, you, Kent, are a Partisan of "The Right Thing". :)
But might be "worse is better"?
>
...
>> You want too much from such a simple function as YES-OR-NO-P. :)
>
> And here I thought the same of you. :)
OK. Draw. :)
>
...
>
> So the name of the space station "Mir" means "World" then?
I think the name means "Peace" which is an other meaning for "Mir".
I wrote "think" because the correct meaning might be given by people only
who named the station.
>
...
>
>> If we talk about efficiency then I think that the
>> COMPLEX and BIGNUM types are not very efficient ones
>
> Are you comparing them to FIXNUMs and FLOATs, which are faster because they
> require less, or are you comparing them to other languages that have better
...
I'm comparing them to FIXNUMs and FLOATs.
...
>
> You could look at ISO ISLISP. I don't recall it having any more strong a
> requirement and, by the way, it was produced by an international
> committee, much more recently. ;)
>
Heh. We are telling here how international is ANSI CL, aren't we?
So, don't deviate from the subject. :)
Duane Rettig
> Aleksandr Skobelev <holy...@mail.ru> writes:
>
> > Duane Rettig <du...@franz.com> wrote:
> > >
> > > ...
> > >
> > > We had these same conversations at Franz, and our conclusions were the
> > > same. And as for CL functions that might be candidates for
> > > locale-sensitivity (STRING<, for example), we added new functionality
> > > rather than try to extend the CL functions (thus, for example, our version
> > > of STRING< remains ASCII centric).
> > >
> >
> > So, any non-English string won't be compared correctly?
>
> Heh. Is there a requirement that a string contain valid language?
> What's an example of a "non-English string"?
Although the english :-) in his statement wasn't quite correct, I
took it to be just a slip and read it as "non-ascii". His slip was
made over the rotten bannana I threw, where I said "ASCII centric"
rather than a more appropriate term (Latin-1 centric for our 8-bit
lisps, and Unicode centric for our 16-bit lisps).
> I thought locales were an abstraction about the context in which a given
> set of characters were to be interpreted, not a representational issue.
One of the categories of the POSIX locale specification is LC_CTYPE,
which does abstract the actual representation of the characters.
Other categories such as LC_MONETARY, LC_NUMERIC, LC_TIME, and
LC_COLLATE abstract the context within which the selected character
set will be used.
> Failing to do it thus would, I think, leave you in a serious quandary
> about how to deal with a string containing multiple languages in the
> same string, such as the hyphenated last name of a person whose parents
> are from different (linguistically incompatible) countries.
We chose not to deal with this - instead we ignore LC_CTYPE and use
the entire Unicode (actually, a subset: UTF-16) character set in our
16-bit lisp, which indeed does allow multiple languages to be represented
at once. This also includes characters that can't be encoded by ASCII,
such as European language characters with extra glyphs on them, as well
as Asian alphabets, Greek, Armenian, Arabic, etc., and even strange
symbols such as traffic signs and other oddities. I thumbed through
the Unicode book our I18n expert has, and it is at least an inch and a
half thick and contains only the character sets...
> STRING< and friends are intended to compare strings in a
> natural-language-independent way, according to an arbitrary sort order
> that is constrained only by the A-Z/0-9 constraints enumerated the
> spec. From an internationalization point of view, this is all
> subprimitive and to be ignored.
>
> Proper internationalization would, IN ANOTHER PACKAGE, offer the right
> meaning.
We chose instead to still use STRING< and STRING> as the basic
comparison tool, and to target it with a collation converter
(obviously, in a different package). The EXCL:STRING-SORT-KEY
function
http://www.franz.com/support/documentation/6.1/doc/pages/operators/excl/string-sort-key.htm
accepts a string and a "ucet" object (for Unicode Collation Element
Table) and returns a string which can be passed to STRING< or STRING>
along with another STRING-SORT-KEY-processed string. A default ucet
object exists which allows for normal Unicode ordering, or the user
can use EXCL:PARSE-UCET to create a new ucet-object:
http://www.franz.com/support/documentation/6.1/doc/pages/operators/excl/parse-ucet.htm
> My understanding is that a properly localized string ordering function
> for a number of locales would require multi-char strings like
> "MacDonald" to sort ahead of "Maas" because "Mac" has some special
> priority in some locales. The definition of STRING< in the ANSI CL
> spec does not permit this because it requires the comparisons to go
> character-wise, not in groups.
This known problem is actually handled by the "Unicode Technical Standard #10"
(sorry, I don't have a url for it). We touch on it briefly in
http://www.franz.com/support/documentation/6.1/doc/iacl.htm#collation-1
Janos Blazi
> split the field. It is already a problem that research published in
> French and German are unavailable to the rest of the computer science
> community.
Regarding the fact that we are giving up German at the moment (and are
substituting it with bad English) I do not believe that are any research
papers in any field written in German.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
Thomas F. Burdick
Well, only if you don't understand the sort order. Honestly, I'd be
annoyed if I had to look through a phone book that was 1/3 "D" entries
because someone had sorted the "de Somthing" family names under D in a
French phone book. Same with Mc, Mac, O'/Ò, di, etc, in the
appropriate countries.
Bookstores are much more of a pain, because they tend to be
inconsistent, which is when you can't find things.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Kent M Pitman
> Kent M Pitman <pit...@world.std.com> wrote:
>
> > You could look at ISO ISLISP. I don't recall it having any more strong a
> > requirement and, by the way, it was produced by an international
> > committee, much more recently. ;)
> >
>
> Heh. We are telling here how international is ANSI CL, aren't we?
> So, don't deviate from the subject. :)
Hey, I wasn't deviating. I was citing "similarity with an ISO
standard" as [weak] "proof" that ANSI CL does what you'd get form an
international standard for Lisp....
Erik Naggum
| For example, the post in which he accused you of belligerence [...]
Oh, so Jean-François Brouillet and "MJ Ray" are the same person. That
explains a lot. Thank you for this information -- I did not know.
///
--
David Hanley
I have a lisp chess program i wrote/am writing. I was refering to it
on the chess programmer board, and one of the other posters really
went after me for being so stupid as to program it in lisp, saying C++
would be much faster, easier to write, simpler, blah blah. In the
process he made it clear he didn't know any lisp at all. You know,
the usual.
I decided to redo a section of my lisp code in C++ to see what kind of
speed sacrifice i was making. I used C++ STL, and compiled with g++
no optimization, the lisp version with CMUCL with no optimizations.
The C++ version used vectors, the lisp version lists.
The lisp version was 30% faster.
I was blown away. I cranked up the optimizations on both versions,
-O4 in the g++ code, and (speed 3)(safety 0) in the LISP version. Now
the lisp code was only about 5% faster.
The C version was also about 50% longer and took several times longer
to write.
This makes my job ( in which i have to use PRO-C ) even more
depressing. :)
dave
Jean-François Brouillet
Oh! You're so disappointing, my clear-sighting Naggum!
Truth be told, I don't know who "MJ Ray" is, and I'm not even sure
I remember any of his posts. But yours...
In fact, I don't even need to remember anything, Naggum, you're
so predictable. Where's the fun with you? You're a way too easy target...
BUT A DEAD BORING ONE
Naggum: open your eyes, and close your mouth. That's the best advice
you'll have for free in years. Leave c.l.l. in peace, and I promise to
step down from my soapbox.
> ///
--
Jean-François Brouillet
Jean-François Brouillet
you skip when quoting?
It seems to me that you don't!
The question is _not_ to decide whether I'm a good or a bad person.
Nobody cares.
My only goal is to get you to
SHUT UP BECAUSE YOU'RE WASTING EVERYONE'S BANDWIDTH
AND JEOPARDIZING OUR READ TIME WHICH IS NOT SO COPIOUS
Go create an alt.naggum.fans but leave us alone! I've got a lot to
learn in Common Lisp, and your sudden irruptions in various threads
prevents people from carrying on with exposing their ideas.
YOU'RE SUCH A GREAT INHIBITOR
We don't _need_ Naggum.
Mais, merde enfin. Il fait vraiment chier ce connard. J'en ai
rien à taper de ce que ducon Naggum pense. Moi? Je veux voire
du Lisp dans comp.lang.lisp.
Et être débarassé de ce psychopathe de Naggum qui vient polluer
toutes les discussions!
C'est trop demander peut-être ?
Naggum: GO HOME! take a vacation! KILL YOURSELF! leave us alone.
I am fed-up! I want to learn. NOT READ ABOUT THE EMPTYNESS OF
NAGGUM SKULL !
GO AWAY
--
Jean-François Brouillet
On 3/1/02 15:55, in article 32190621...@naggum.net, "Erik Naggum"
Erik Naggum
| For example, the post in which he accused you of belligerence [...]
* Erik Naggum
> Oh, so Jean-François Brouillet and "MJ Ray" are the same person. That
> explains a lot. Thank you for this information -- I did not know.
* Jean-François Brouillet <ve...@mac.com>
| Oh! You're so disappointing, my clear-sighting Naggum!
I was sarcastically pointing out that Israel Ray Thomas is unable to keep
track of anything, not even what he enjoys, which is a very useful thing
to know about him. I also enjoy seeing that you are unable to detect
sarcasm, as that is very consistent with your character. And the reason
you think I am so predictable is that you see only what you want to see
and you cannot even _imagine_ anything but one-dimensional personalities,
another very consistent trait for your particular kind. If you believe
that _you_ bring anything new to this forum, try again. Hateful scum
like you have been coming and going for years, having exposed yourself in
ways that will embarrass yourself and your family for years to come, in
full public view. Some of you recover, but you will not get that chance.
| Leave c.l.l. in peace, and I promise to step down from my soapbox.
Within the next 48 hours, you will die in a car accident, so there is no
need for you to make these sorts of silly threats. I shall remember you
as you chose to present yourself to me. Good riddance to you.
///
--
Erik Naggum
| Naggum: GO HOME! take a vacation! KILL YOURSELF! leave us alone.
| I am fed-up! I want to learn. NOT READ ABOUT THE EMPTYNESS OF
| NAGGUM SKULL !
Your pain will soon be over. In the short time you have left among the
living, you could do something you can enjoy, or you can continue to
scream in agony in front of your computer, but then again, you had that
choice all your life, and then you begin posting to comp.lang.lisp.
///
--
Coby Beck
"Jean-François Brouillet" <ve...@mac.com> wrote in message
news:B85A8777.35E0%ve...@mac.com...
> you'll have for free in years. Leave c.l.l. in peace, and I promise to
> step down from my soapbox.
I'd prefer if _you_ would leave c.l.l in peace. Really....
--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
Jean-François Brouillet
You spend your time answering to problems that you invent, and
not addressing the crux of the matter. That's a very skilled side-tracking
technique which I recognize even from a distance.
In case I'm still alive in 48 hours, I will endeavour to do the
following:
Each further day that God still allows me to live ;-), and assuming
Cretin-Naggum didn't grow any further brain cell atom on that day, and
tried by one post or another to either inhibit or ridicule some poster
idea, I will post an empty message to c.l.l reading:
AND YET ANOTHER DAY HAS PASSED AND NAGGUM STILL ANNOYS AN ENTIRE COMMUNITY
(or some variation thereof)
And I thought I knew what "diehard" meant ;-(
You're passé Naggum. There's no hope for you. Do yourself a favour:
shut up. Is it because I'm younger than you and can see things that
your senility prevents you from understanding? Is it because I'm
older than you and your youth hasn't taught you any of the core values
in life?
But even cockroaches seems to be much more decent creatures.
You're an intellectual parasite, Naggum, a Trojan horse using c.l.l
to spread doom and gloom. No one _needs_ you.
Since I'm very prompt to sympathise, I find it very sad to understand
what kind of loneliness you find yourself with, but I'm really sorry for
you, Naggum, there's no cure for that one. Too bad that your genes have
built you in such a way that you'll never understand, but please, for
them, don't raise children, they might otherwise inherit that terrible
disease.
--
Jean-François Brouillet
On 3/1/02 22:42, in article 32190865...@naggum.net, "Erik Naggum"
Jean-François Brouillet
Ah bon? Y sont deux maintenant?
Poor little shitty thing! When you read that a thread title
is "Nagging Naggum", you don't need to stretch your imagination
beyond inhumane limits to kind of guess we're not talking
16th century litterature!
--
Jean-François Brouillet
On 3/1/02 23:08, in article
Zv5Z7.263826$Ga5.47...@typhoon.tampabay.rr.com, "Coby Beck"
Janos Blazi
Erik is an important feature of CL (though some people think he is a bug).
We are all afraid of losing him as nobody knows what happens to CL after
him? Some people are even afraid that in this case CL turns into Scheme
(after the spell is removed).
Jean-François Brouillet
> Please understand the special c.l.l psychology. We have just elaborated that
> Erik is an important feature of CL (though some people think he is a bug).
> We are all afraid of losing him as nobody knows what happens to CL after
> him? Some people are even afraid that in this case CL turns into Scheme
> (after the spell is removed).
This aspect had completely eluded me. Sorry for not seeing the obvious.
But in that case, shouldn't we commoditize Naggum as naggum, as in:
"Today I fixed two f***ing naggums in my code" or
"The marketing department has added two naggums to their bullet list" ?
But then we might as well use him for the posterity, as in:
(defun naggum (x) x) ; identity
(defun naggum () nil) ; tautology
(defun naggum (x) ; non elimination of abusive
(naggum (1+ x))) ; self-recursion
--
Jean-François Brouillet
israel r t
<ve...@mac.com> wrote:
>In case I'm still alive in 48 hours, I will endeavour to do the
>following:
Erik has probably sent out the ninja teams already...
You will recognise them.
They are the ones with the body odour and who keep saying "setf",
"cons" .