I was looking for a Common LISP implementation of MD5, but found none.
So I wrote a silly port of MD5 in CL.
ftp://Samaris.tunes.org/pub/lang/cl/fare/md5.lisp
On CMUCL, the result runs about 5.5 times slower than the equivalent optimized
C code; that said, on CMUCL, it can also call the external md5sum utility
for fast processing of large files or streams.
It purports to abide by (and extend) the MD5 interface defined in ACL6.
Excellent things that helped: CL macros.
Horrible things that get in the way: CL characters,
and lack of builtin modular operators.
The problem is that CL purports to be a high-level language, but actually
provides gratuitously incompatible and subtly unusable access to what is
ought to be low-level constructs. The world has standardized on low-level
byte streams as the universal medium for communication of data, including
text. Yet, CL strings are based on a pseudo-high-level characters that are
not portably interoperable with worldly text, much less efficiently. That
there can be direct support for >8 bit characters and for character
attributes is great, but, particularly when efficient portable text-processing
is meant, the only way is using (unsigned-byte 8), and suddenly, all
builtin support for any text-processing at all vanish.
ACL6's SIMPLE-STREAMs are a definite step in the right direction,
and I hope other vendors will adopt similar interfaces.
CommonLISPers often diss Scheme for being such a small language, which forces
development of incompatible implementation-specific extensions for any
interesting work. Well, we have to face the fact that in today's world,
CL is also a small language by this criterion. Much much smaller than
C, SML, OCAML, Haskell, Mercury, Oz, Perl, Python, or whatever.
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
Racism consists in attributing to genetics what is due to memetics. -- Far�
I experienced similar behavior when I ported a C version of md5 to
Lisp, in my case Lispworks. I tried a variety of declarations and
compiler safety settings, and profiled it as well. I also asked about
the results here, and as I recall, the cause was related to the
relative slowness of CL in bit-twiddling register width integers. The
issue seemed to hinge on dpb returning values rather than affecting
storage cells directly, instead causing a lot of setf activity in the
innermost portions of the algorithm's loop. Fixnum optimizations
might help, but nconc-style variations of dpb would likely be a faster
way to approach the problem.
I found macros to be helpful, but I didn't run into any particular
trouble with CL characters. I used (read-sequence) into a
simple-array and it seemed to work out well enough. Profiling
suggested the vast majority of time was spent in the md5 code.
Bit-twiddling may well be slow in Lisp, but there is the other side of
the question. In a recent project, I would have gladly accepted an
order of magnitude decrease in performance to get Lisp's rational and
bignum support instead of slaving my way around the inadequacy of C's
32 bit ints and double floats. I suspect the algorithm would be
pretty much as fast or faster in Lisp than in C on the given hardware.
It would certainly have been simpler.
Gregm
> So I wrote a silly port of MD5 in CL.
> ftp://Samaris.tunes.org/pub/lang/cl/fare/md5.lisp
> On CMUCL, the result runs about 5.5 times slower than the equivalent optimized
> C code; that said, on CMUCL, it can also call the external md5sum utility
> for fast processing of large files or streams.
> It purports to abide by (and extend) the MD5 interface defined in ACL6.
>
> Excellent things that helped: CL macros.
> Horrible things that get in the way: CL characters,
> and lack of builtin modular operators.
Francois-Rene Rideau <····@tunes.org> writes:
> The problem is that CL purports to be a high-level language, but actually
> provides gratuitously incompatible and subtly unusable access to what is
> ought to be low-level constructs. The world has standardized on low-level
> byte streams as the universal medium for communication of data, including
> text. Yet, CL strings are based on a pseudo-high-level characters that are
> not portably interoperable with worldly text, much less efficiently. That
> there can be direct support for >8 bit characters and for character
> attributes is great, but, particularly when efficient portable text-processing
> is meant, the only way is using (unsigned-byte 8), and suddenly, all
> builtin support for any text-processing at all vanish.
> ACL6's SIMPLE-STREAMs are a definite step in the right direction,
> and I hope other vendors will adopt similar interfaces.
You've done the work on md5 and I haven't so this is guess work, but
my first thought where the problem would lie is that a lot of these
algorithms assume efficient 32 bit operations, which in CL will
cons. Given sufficient declarations the character->(unsigned-byte 8)
conversions with char-code should be negligable.
--
Lieven Marchand <···@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
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3213610074551907@naggum.net>
* Lieven Marchand <···@wyrd.be>
| You've done the work on md5 and I haven't so this is guess work, but my
| first thought where the problem would lie is that a lot of these
| algorithms assume efficient 32 bit operations, which in CL will
| cons. Given sufficient declarations the character->(unsigned-byte 8)
| conversions with char-code should be negligable.
MD5 seems to be designed with hardware implementations in mind. This is
not a bad idea, but it tends to make software implementations weirder.
I have written an MD5 function in Allegro CL, using several low-level
features (which are still at a higher level than C) and decided to split
the 32-bit numbers in two 16-bit parts. Emacs has done the same thing,
but in a slightly different way. I wanted to add support for a bitwise
rotate function that would end up using such instructions if available,
but it is probably easier to write MD5 in assembly on each platform than
to optimize it better. In the application I used this, MD5 hashes were a
serious bottleneck, so it had to be better than using FFI to a C function.
After having worked with the MD5 functions on and off for a month or so,
I came to conclude that it _should_ be written in assembly, and started
to do that, but it turned out to be extremely time-consuming work. The
Intel processors are shy too many registers, so all the fun in trying to
make it superfast was replaced by increasing frustration over the design
of those processors. Still, initial estimates indicated that a hand-
tuned assembly version would be about twice as fast as the code that gcc
produced for the naive implementation found in the RFC, so it would be
worth it at significant cost.
I also think the new streams design from Franz Inc makes for a good way
to deal with the 64-byte buffers. It is wrong to try to work with MD5 at
the character level, and the typical use of MD5 is to ensure that some
data stream is intact. If the application that consumes the stream can
do both MD5 hashing and its real work at the same time, and can roll back
the work if the MD5 hash turns out bad, much will be saved compared to
making two passes, since we must assume that the MD5 hash is usually good.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
Lieven Marchand <···@wyrd.be> writes:
> You've done the work on md5 and I haven't so this is guess work,
> but my first thought where the problem would lie is that a lot of these
> algorithms assume efficient 32 bit operations, which in CL will cons.
Indeed, the *performance* problem is lack of efficient modular integer
operations, with all the consing, unconsing, size-checking, etc.,
that goes with it.
The character issue is much worse: it's a *semantic* problem.
It might not be in the speed bottleneck of this particular code
(still, a typical character-based application doing MD5 in *portable*
Common LISP would have a least 4 or 5 layers of buffers, just in the
LISP side -- which does slow things down). But it's a major PITA to
code around this nasty abstraction inversion.
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
Motto for a society of free individuals: LIBERTY + RESPONSABILITY = PROPERTY
>>>>> "Francois-Rene" == Francois-Rene Rideau <···········@tunes.org> writes:
Francois-Rene> Lieven Marchand <···@wyrd.be> writes:
>> You've done the work on md5 and I haven't so this is guess work,
>> but my first thought where the problem would lie is that a lot of these
>> algorithms assume efficient 32 bit operations, which in CL will cons.
Francois-Rene> Indeed, the *performance* problem is lack of efficient modular integer
Francois-Rene> operations, with all the consing, unconsing, size-checking, etc.,
Francois-Rene> that goes with it.
Well, you can get rid of the consing size-checking, etc., by doing, as
Erik says, 16-bit chunks.
Or lie to the compiler so that your function
(defsubst ub32-add/2 (x y)
"Return 32-bit modular sum of 32-bit integers X and Y."
(declare (type ub32 x y))
(enforce-ub32 (+ x y)))
becomes something like
(defun ub32-add/2 (x y)
(declare (type ub32 x y))
(the ub32 (+ x y)))
With the right speed and safety, this will probably be converted to a
single 32-bit add instruction, which is what you wanted.
For 16-bit chunks, something like the following might work (barely
untested):
(defun ub32-add/2 (x y)
(declare (type (unsigned-byte 32) x y) (optimize speed (safety 0)))
(let* ((lo-x (logand x #xffff))
(hi-x (logand (ash x -16) #xffff))
(lo-y (logand y #xffff))
(hi-y (logand (ash y -16) #xffff))
(lo-sum (+ lo-x lo-y))
(hi-sum (+ hi-x hi-y)))
(declare (type (unsigned-byte 17) lo-sum hi-sum))
(when (> lo-sum #xffff)
(setf lo-sum (logand lo-sum #xffff))
(incf hi-sum 1))
(logior (ash (logand hi-sum #xffff) 16)
lo-sum)))
This shouldn't cons except for the result and probably runs faster
than what you have because it doesn't have to call out to a generic +
routine.
Ray
From: ···@itasoftware.com
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <y9lqb3ds.fsf@itasoftware.com>
Raymond Toy <···@rtp.ericsson.se> writes:
> >>>>> "Francois-Rene" == Francois-Rene Rideau <···········@tunes.org> writes:
>
> Francois-Rene> Lieven Marchand <···@wyrd.be> writes:
> >> You've done the work on md5 and I haven't so this is guess work,
> >> but my first thought where the problem would lie is that a lot of these
> >> algorithms assume efficient 32 bit operations, which in CL will cons.
> Francois-Rene> Indeed, the *performance* problem is lack of efficient modular integer
> Francois-Rene> operations, with all the consing, unconsing, size-checking, etc.,
> Francois-Rene> that goes with it.
>
> Well, you can get rid of the consing size-checking, etc., by doing, as
> Erik says, 16-bit chunks.
>
> Or lie to the compiler so that your function
>
> (defsubst ub32-add/2 (x y)
> "Return 32-bit modular sum of 32-bit integers X and Y."
> (declare (type ub32 x y))
> (enforce-ub32 (+ x y)))
>
> becomes something like
>
> (defun ub32-add/2 (x y)
> (declare (type ub32 x y))
> (the ub32 (+ x y)))
>
> With the right speed and safety, this will probably be converted to a
> single 32-bit add instruction, which is what you wanted.
Probably not. The commercial lisps generally use two or three low
bits as a tag (and set them to zero), so although the compiler may
emit a 32-bit add instruction, it is really performing a 29 bit add.
> For 16-bit chunks, something like the following might work (barely
> untested):
>
> (defun ub32-add/2 (x y)
> (declare (type (unsigned-byte 32) x y) (optimize speed (safety 0)))
> (let* ((lo-x (logand x #xffff))
> (hi-x (logand (ash x -16) #xffff))
> (lo-y (logand y #xffff))
> (hi-y (logand (ash y -16) #xffff))
> (lo-sum (+ lo-x lo-y))
> (hi-sum (+ hi-x hi-y)))
> (declare (type (unsigned-byte 17) lo-sum hi-sum))
> (when (> lo-sum #xffff)
> (setf lo-sum (logand lo-sum #xffff))
> (incf hi-sum 1))
> (logior (ash (logand hi-sum #xffff) 16)
> lo-sum)))
>
> This shouldn't cons except for the result and probably runs faster
> than what you have because it doesn't have to call out to a generic +
> routine.
The problem is that an (unsigned-byte 32) won't fit in a boxed value
on a 32-bit machine. Your ub32-add/2 will cons a bignum when you ash
the high sum by 16 bits.
>>>>> "jrm" == jrm <···@itasoftware.com> writes:
jrm> Raymond Toy <···@rtp.ericsson.se> writes:
>>
>> (defun ub32-add/2 (x y)
>> (declare (type ub32 x y))
>> (the ub32 (+ x y)))
>>
>> With the right speed and safety, this will probably be converted to a
>> single 32-bit add instruction, which is what you wanted.
jrm> Probably not. The commercial lisps generally use two or three low
jrm> bits as a tag (and set them to zero), so although the compiler may
jrm> emit a 32-bit add instruction, it is really performing a 29 bit add.
Yes, this is true in general, but I'm assuming most commercial lisps
also support 32-bit integer types. That might not be true, and then
you are hosed. CMUCL does support 32-bit integer types so for
(defun foo (x y)
(declare (type (unsigned-byte 32) x y)
(optimize (speed 3) (safety 0)))
(the (unsigned-byte 32) (+ x y)))
You get something like
<stuff to get x and y into 32-bit integer form from possibly boxed values>
6B0: L1: MOV %NL1, %NL0
6B4: ADD %NL2, %NL0 ; No-arg-parsing entry point
<stuff to return this 32-bit result as a boxed answer>
>> This shouldn't cons except for the result and probably runs faster
>> than what you have because it doesn't have to call out to a generic +
>> routine.
jrm> The problem is that an (unsigned-byte 32) won't fit in a boxed value
jrm> on a 32-bit machine. Your ub32-add/2 will cons a bignum when you ash
jrm> the high sum by 16 bits.
With CMUCL, I'm pretty sure that the consing happens when it tries to
return the final 32-bit result. No consing happens for the 16-bit
shift of the high sum, because the compiler understands unboxed 32-bit
integers.
Ray
···@itasoftware.com writes:
> Probably not. The commercial lisps generally use two or three low
> bits as a tag (and set them to zero), so although the compiler may
> emit a 32-bit add instruction, it is really performing a 29 bit add.
Doesn't Lucid Common Lisp have some way to pass unboxed 32 bit
integers between functions? I once asked JonL about this, and he said
something about the red and pink registers (which hold untagged and
potentially untagged values, respectively), but I never remembered the
whole story.
From: ···@itasoftware.com
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <g07x88oo.fsf@itasoftware.com>
Carl Shapiro <········@panix.com> writes:
> ···@itasoftware.com writes:
>
> > Probably not. The commercial lisps generally use two or three low
> > bits as a tag (and set them to zero), so although the compiler may
> > emit a 32-bit add instruction, it is really performing a 29 bit add.
>
> Doesn't Lucid Common Lisp have some way to pass unboxed 32 bit
> integers between functions? I once asked JonL about this, and he said
> something about the red and pink registers (which hold untagged and
> potentially untagged values, respectively), but I never remembered the
> whole story.
I dunno if you can use an unboxed register for passing return values.
Lucid Common Lisp doesn't poll for interrupts, so it has to be careful
managing the registers so that a GC can parse the processor state at
any time. Partitioning the registers into boxed and unboxed sets
makes this easier.
Carl Shapiro <········@panix.com> writes:
> ···@itasoftware.com writes:
>
> > Probably not. The commercial lisps generally use two or three low
> > bits as a tag (and set them to zero), so although the compiler may
> > emit a 32-bit add instruction, it is really performing a 29 bit add.
>
> Doesn't Lucid Common Lisp have some way to pass unboxed 32 bit
> integers between functions? I once asked JonL about this, and he said
> something about the red and pink registers (which hold untagged and
> potentially untagged values, respectively), but I never remembered the
> whole story.
I don't know about Lucid/Liquid, but the original non-x86 ports of CMU
CL use the (common) register partitioning strategy, in order not to
confuse the GC when it occurs while unboxed values are being worked
on, which is needed inside functions, too. On x86 this strategy is
suboptimal, since the iA32 architecture is so starved for registers,
that partitioning would leed to constant loading and unloading of
registers. So CMU CL on x86 doesn't partition its register set, and
uses a conservative GC.
The ability to pass unboxed values across function calls OTOH requires
something else: The receiving site needs to know to expect an unboxed
value (either in an unboxed register, or inside the normal registers,
if there is no partitioning), and the function itself must know that
all possible receiving sites can handle that unboxed value. Unless
you can pass the information "value is unboxed" dynamically to a
receiving site, and all receiving sites the implementation produces
are able to deal with this (which will introduce quite a bit of
overhead into function calls everywhere, for little gain), you need
some closed-world assumption, i.e. either all receiving sites must be
known at compile-time, or it must be ensured that all receiving sites,
including future receiving sites are capable of dealing with an
unboxed value return.
There are various ways of achieving that closed world. Inlining is
one obvious candidate. Another possibility is folding all cooperating
functions into one flet/labels form, from which no closures escape.
CMU CL allows a nice syntax for this via its block-compilation
declarations, which allows certain functions in the block to be
declared as external entry points, and all other functions as purely
internal functions. I.e. in the following code, only the return value
of baz needs to be returned re-boxed, all other values can be passed
around in unboxed form:
(declaim (optimize (speed 3) (debug 0) (space 0) (safety 0)))
(declaim (start-block baz))
(declaim (type (function ((unsigned-byte 32)) (unsigned-byte 32)) foo bar))
(defun foo (x)
(declare (type (unsigned-byte 32) x))
(logxor x #xF1F1F1F1))
(defun bar (x)
(declare (type (unsigned-byte 32) x))
(logxor #x7E7E7E7E (foo x)))
(defun baz (x y)
(declare (type fixnum x y))
(bar (+ x y)))
(declaim (end-block))
Other implementations provide other ways of "closing the world", in
order to allow optimizations like unboxed argument/result passing to
happen.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3213654193623720@naggum.net>
* Raymond Toy
| With the right speed and safety, this will probably be converted to a
| single 32-bit add instruction, which is what you wanted.
But it might box the result when returning it, unless the function call
is inlined or declared in to return unboxed results. E.g., Allegro CL
offers a means to do this which is pretty intricate, but which yields
significant speed-ups in some applications. I have only seen it used,
not used it myself, but if this is an issue, do ask and investigate.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
>>>>> "Erik" == Erik Naggum <····@naggum.net> writes:
Erik> * Raymond Toy
Erik> | With the right speed and safety, this will probably be converted to a
Erik> | single 32-bit add instruction, which is what you wanted.
Erik> But it might box the result when returning it, unless the function call
Erik> is inlined or declared in to return unboxed results. E.g., Allegro CL
I was leaving that as an exercise for the reader. :-)
Ray
Erik Naggum <····@naggum.net> writes:
> * Raymond Toy
> | With the right speed and safety, this will probably be converted to a
> | single 32-bit add instruction, which is what you wanted.
>
> But it might box the result when returning it, unless the function call
> is inlined or declared in to return unboxed results. E.g., Allegro CL
> offers a means to do this which is pretty intricate, but which yields
> significant speed-ups in some applications. I have only seen it used,
> not used it myself, but if this is an issue, do ask and investigate.
I agree; a user should ask and investigate.
However, there is a subtle snag here; Raymond's example uses
(unsigned-byte 32) values, and Allegro CL only does unboxed arithmetic
on (signed-byte 32). This isn't a big problem for someone who knows
how to use signed values as if they are unsigned values (i.e. the most
negative 32-bit number, when converted, looks like #x80000000, and the
machine integer representation for -1 in unboxed (signed-byte 32)
representation becomes #xffffffff.
But why only one choice? Why not allow both (signed-byte 32) _and_
(unsigned-byte 32)? The problem is in the range overlap in deciding
the type upgrade.
Background:
The compiler always tries to do regular boxed arithmetic whenever
the types assigned to calculations are within fixnum range, because
that is still most efficient. If the fixnum range is exceeded, but
the calculation remains within the "unboxed integer" range, then most
of the calculation can be done efficiently, but the final result must
be "boxed" by testing for fixnum and either shifting (for values in
fixnum range) or boxing into a bignum (for values too large for
a fixnum). We use a runtime primitive called fixnum-or-bignum
to do this. The final type upgrade is when the range of the calculation
exceeds even this unboxed integer range, and thus the compiler has to
generate generic code (in the generic sense, not in the CLOS sense).
In summary, there are three integer gradations: fixnum, then unboxed, and
then generic.
So consider the following function:
(deftype positive-fixnum () '(mod #.most-positive-fixnum))
(defun foo (x y)
(declare (optimize speed) (positive-fixnum x y))
(+ x y 10))
Each variable has a declaration of positive-fixnum, or in
normalized form: (integer 0 #.most-positive-fixnum).
There can actually be two additions implied here, but because
addition is associative I'll only describe the final calculation
result, which can be given a type of
(integer 10 #.(+ (* most-positive-fixnum 2) 10))
Now, the above type does not fall within the fixnum range, so it must
be upgraded. Question: does it fall within (unsigned-byte 32) range,
or (signed-byte 32) range? Answer: Yes!
This ambiguity would cause extra work for the compiler, to keep
track of what choice it has made, or to possibly keep two possible
compilation strategies, so as to know how to box the final result,
either using fixnum-or-bignum, or using unsigned-fixnum-or-bignum
instead. It should be possible to do this, but we chose not to,
because that would have made such compilations much more complex, and
introduced many possible bugs. Also, the decision to only track one
type allowed us to use the same unboxed-compilation mechanism
as we use for doing unboxed floating-point values. It also allowed us
to encode some of the low-level bit patterns representing gc states
into two-bit patterns, with four states each (lisp-value, single-float,
double-float, and (signed) machine-integer). This is useful for our
immediate-args concept, where unboxed arguments can be passed between
lisp funxtions.
Whether we made a correct decision to choose (signed-byte 32) over
(unsigned-byte 32) is debatable; I have little hard data, and only
a general sense, but I believe that the pros and cons are relatively
balanced; on the one hand, the obvious inadequacy of our choice is
that foreign interface communications are slightly harder to make
efficient (although since a 32-bit C compiler doesn't know the
difference between receiving an int or an unsigned int as an argument,
one could just lie to the foreign interface)
but on the other hand, most people don't create unsigned positive-fixnum
types, and instead tend to work with fixnum type declarations whenever
they want to say "this is a small number". Since fixnum is a signed
type, we chose to stay with the signed version rather than the unsigned,
as a philosophical balance to match the fixnum type.
The conclusion is the same as the start: a user should ask and
investigate.
--
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 ·····@Franz.COM (internet)
Francois-Rene Rideau <···········@tunes.org> writes:
> The character issue is much worse: it's a *semantic* problem.
> It might not be in the speed bottleneck of this particular code
> (still, a typical character-based application doing MD5 in *portable*
> Common LISP would have a least 4 or 5 layers of buffers, just in the
> LISP side -- which does slow things down). But it's a major PITA to
> code around this nasty abstraction inversion.
md5 is defined on a stream of octets. You should calculate it at that
level. That later on that stream of octets is converted into something
with meaning at a higher level, such as characters in a certain
encoding, is neither relevant nor an abstraction inversion.
--
Lieven Marchand <···@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
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3213559409134408@naggum.net>
* Francois-Rene Rideau <····@tunes.org>
| I was looking for a Common LISP implementation of MD5, but found none.
Several implementations are available for those who ask, some as fast as
those written in C, and about as low-level as C versions, too.
| Horrible things that get in the way: CL characters, and lack of builtin
| modular operators.
Huh? You probably mean that you open a file with element-type character
and since you get what you asked for, but not what you wanted, you blame
the language instead of your own incompetence at expressing your wishes.
If you really want to read a file of 8-bit bytes, specify it, and you get
exactly what you want.
| The problem is that CL purports to be a high-level language, but actually
| provides gratuitously incompatible and subtly unusable access to what is
| ought to be low-level constructs.
Huh? This sounds like a disgruntled programmer more than a language
problem. Perhaps we would be able to judge for ourselves if you posted
the actual _code_ you wrote to arrive at these weird conclusions?
| The world has standardized on low-level byte streams as the universal
| medium for communication of data, including text.
Which is a mistake, since they run into an enormous amount of trouble
with supporting more than one character encoding. The Unix model is one
of those "simpler than possible" models that do not actually work when
pushed too hard. That some operations require punning on the lowest
level of representation and that this is not only possible, but easy in
C, is not necessarily a good thing. Such representational issues should
be explicit. Even C++ has discovered the truth in this, these days.
What has stopped you from using "low-level byte streams" in _your_ code?
| Yet, CL strings are based on a pseudo-high-level characters that are not
| portably interoperable with worldly text, much less efficiently.
Whatever that means. I think you are simply seriously confused and would
have come a lot further if you had asked for help or read _all_ the fine
documentation before you became so frustrated, but that seems to be
incompatible with the tunes to which some people's egos play.
| That there can be direct support for >8 bit characters and for character
| attributes is great, but, particularly when efficient portable
| text-processing is meant, the only way is using (unsigned-byte 8), and
| suddenly, all builtin support for any text-processing at all vanish.
The myopia suffered by people who think 8 bits is sufficient is probably
never going to be discovered as long as they stare at their data from a
distance of only 1 inch. Just because you think you need a byte for a
particular operation does not mean that you do, nor that anything else
should conform to this particular requirement.
Look, you are not doing text processing when you process bytes. It works
in some environments and under some assumptions, but if you are dealing
with text, you deal with characters, not their coding, and if you deal
with bytes, you are not dealing with characters. It is that simple.
Since the C mindset is so insidious and unconscious with those who suffer
frm it, including some long-time (not Common) Lisp programmers,
| CommonLISPers often diss Scheme for being such a small language, which
| forces development of incompatible implementation-specific extensions for
| any interesting work. Well, we have to face the fact that in today's
| world, CL is also a small language by this criterion. Much much smaller
| than C, SML, OCAML, Haskell, Mercury, Oz, Perl, Python, or whatever.
What does this mean? Your conclusions seem to be drawn from a lot of bad
experiernce, but there is no way to determine whether that is due to your
incompetence or to whatever it is you conclude it must have been, blaming
the language for your problems. Just post the evidence: The code and let
people help you figure out what the real problem is.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
> | I was looking for a Common LISP implementation of MD5, but found none.
> Several implementations are available for those who ask, some as fast as
> those written in C, and about as low-level as C versions, too.
Ask whom? If someone was willing to publish code for others to use, he'd
already have done it. Or at least announced it on a webpage. So far, the
only advertised Common LISP implementation of MD5 is Franz' ACL6's - which
doesn't quite fulfill my needs, and is embedded in their application rather
than available as portable common lisp. So good for them - no good for me.
The ACL version is about twice slower than C. Mine, using CMUCL is about
5.5 times slower (but it calls an external C program for files or large
strings).
> | Horrible things that get in the way: CL characters, and lack of builtin
> | modular operators.
> Huh? You probably mean that you open a file with element-type character
> and since you get what you asked for, but not what you wanted, you blame
> the language instead of your own incompetence at expressing your wishes.
No, I blame the language for not allowing me to express my wishes.
I can, certainly, open files in octet mode - mind you, that's precisely
what I do. But then, I'm not interoperable with all the body of
character-based text, SEXP or (shudder) XML processing. It is certainly
possible to build translation layers from one to the other, but it's clumsy,
inefficient, not portable, and underspecified.
Certainly, each implementation specifies (more or less precisely)
what happens when you use code-char and such, but then, you have
the same kind of incompatible extension hell as in Scheme. Once again,
reading their specification, I happen to like the recent things done
by Franz (SIMPLE-STREAM), but it's unhappily not directly applicable to me.
For performance, lack of supported modular integer operators
is also a big problem.
> Perhaps we would be able to judge for ourselves if you posted
> the actual _code_ you wrote to arrive at these weird conclusions?
I consider it bad practice to post large code files on USENET. I posted
the URL to that code, which ought to be enough for anyone interested.
I repeat it here (and add a second one), in case you missed it:
ftp://Samaris.tunes.org/pub/lang/cl/fare/md5.lisp
http://tunes.org/cgi-bin/cvsweb/fare/fare/lisp/md5.lisp
[I made very minor cleanups and enhancements since yesterday;
those who downloaded, beware that two of the transient revisions
that I committed a few hours ago (1.3 and 1.4) had buggy typos - sorry;
latest released (1.5) is ok]
> | The world has standardized on low-level byte streams as the universal
> | medium for communication of data, including text.
> Which is a mistake, since they run into an enormous amount of trouble
> with supporting more than one character encoding.
It is not a mistake - it is the natural thing to do in a world of
proprietary black-box devices and software.
> The Unix model is one of those "simpler than possible" models that
> do not actually work when pushed too hard.
I agree, but this is beside the point. I hate UNIX about as one can
(does the UNIX haters mailing-list still exist?) - and I use it daily.
> What has stopped you from using "low-level byte streams" in _your_ code?
I did it. But it's not portably interoperable with the character-based
SEXP code that I have. Using MD5 to portably support code version tagging,
etc., becomes "interesting". By no means impossible. Just a PITA.
> Look, you are not doing text processing when you process bytes.
No I'm not. And sometimes, I want to do only one. Sometimes, I want to do
only the other. Sometimes, I am happy with the character processing done
by my implementation (though it's not portable). Sometimes, I need precise
control on the processing that happens (e.g. because I'm precisely
transcoding stuff from one protocol to another). And sometimes, I want to
do both byte-processing and text-processing at once on the same stream
(at once: switching from one to the other, or even doing both character
processing AND md5sum'ing on the same chunk).
In the latter cases, any implicit character processing done by the
implementation is an abstraction inversion, to me.
> if you are dealing
> with text, you deal with characters, not their coding,
Not even. I could be dealing with words, with sentences, with layout
elements. In such contexts, characters are too low-level and not what I like.
Yet I don't resent of CL not standardizing on high-level protocols -- it's
things that can easily be implemented on top of them. However, wrongly
standardizing on low-level things while adding restrictions to them is
an abstraction inversion and it's wrong - it's the language getting in the
way rather than helping.
One reason C has success is because it has little abstraction inversions
(it does, with the implicit call stack and unavailability of user-defined
safe-points with respect to temporary variable allocation).
Open single-implementation languages (ocaml, perl, python, etc.) can also
be fixed with respect to any abstraction inversion that may creep - and
indeed you'll find that they have little that gets in the way.
> | CommonLISPers often diss Scheme for being such a small language, which
> | forces development of incompatible implementation-specific extensions for
> | any interesting work. Well, we have to face the fact that in today's
> | world, CL is also a small language by this criterion. Much much smaller
> | than C, SML, OCAML, Haskell, Mercury, Oz, Perl, Python, or whatever.
> What does this mean?
I'm sorry I don't speak norvegian (yet). It means precisely what it says.
Despite the superiority of LISP on some matters (macros, dynamism, object
system), it is an inferior language on many other matters (static safety,
efficiency, modularity, concurrency/distribution, resource control,
modular numbers, interface to the real-world, openness, etc.).
If you pick a particular implementation and consider it your world,
you may gain back some of it - but then you'll see that you're no better
than Scheme, and that the weight of the LISP standard is something that
drags you back rather than helps you forth. [This reminds me of the
situation of FORTH, too.]
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
If you could ask a unique question to a computer during a Turing test,
what would you ask?
-- Douglas Hofstader, Metamagical Themas
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3213617417316421@naggum.net>
* Francois-Rene Rideau <···········@tunes.org>
| Ask whom?
This newsgroup, for instance.
| If someone was willing to publish code for others to use, he'd already
| have done it. Or at least announced it on a webpage.
That has actually been done. I will certainly not blame you for not
finding things on the Net, however. That is why asking those wetware
search engines called "humans" is still a very good idea.
| So far, the only advertised Common LISP implementation of MD5 is Franz'
| ACL6's - which doesn't quite fulfill my needs, and is embedded in their
| application rather than available as portable common lisp.
It is not an implementation in Common Lisp, but written in C as a
low-level system function. There seem to be serious performance
improvements in the upcoming 6.1 release.
| The ACL version is about twice slower than C.
Well, that much is fairly odd, considering that it is written in C. I
only noticed that it consed like mad because it used C space for a copy
of every string, and that C space was neither freed nor garbage collected.
| No, I blame the language for not allowing me to express my wishes.
I can sympathize with this. I frequently blame the planet earth for
exhibiting more gravitation than I wish it had, and I wish magic worked,
too, because I certainly do not want to do so much _work_ all the time.
The wishes of good engineers are subjugated to the reality in which they
need their wishes to come true. The wishes of really bad engineers are
completely disconnected from any reality. I think yours are of the
latter kind.
| I can, certainly, open files in octet mode - mind you, that's precisely
| what I do. But then, I'm not interoperable with all the body of
| character-based text, SEXP or (shudder) XML processing.
You really need to clue in that MD5 does not operate on characters. That
some languages have no idea what a character is, but treat it like a
small integer is really not something you can blame either MD5 or Common
Lisp for. If you really need a stream to exhibit characters while you do
MD5 processing on its underlying byte stream, you can do that by creating
a new stream class that reads from those 64-byte buffers that you read
from the input source and give to MD5. It is really not that hard if you
want to _work_ with the language and avoid "wishing" for things that are
incompatible with the language you use.
| It is certainly possible to build translation layers from one to the
| other, but it's clumsy, inefficient, not portable, and underspecified.
MD5 is specified to work on blocks of 64 bytes. How you get from what
you have to 64-byte blocks is really a question of quality of programmer
and implementation. I still think you are simply massively incompentent.
| Certainly, each implementation specifies (more or less precisely) what
| happens when you use code-char and such, but then, you have the same kind
| of incompatible extension hell as in Scheme.
Wrong.
| Once again, reading their specification, I happen to like the recent
| things done by Franz (SIMPLE-STREAM), but it's unhappily not directly
| applicable to me.
Well, what makes it impossible for you to take their good ideas and
implement them on your own?
| For performance, lack of supported modular integer operators is also a
| big problem.
I actually agree with this in general, but for MD5, just break the 32-bit
integers in half and operate on 16-bit values, instead. I assure you
that no significant performance loss is caused by this, and the algorithm
does not increase in complexity because of it. This is a fairly simple
engineering tradeoff that good engineers will do to get the work done and
bad engineers will refuse to do because they wish they did not have to.
| I consider it bad practice to post large code files on USENET.
Well, if your MD5 function is a large code file, then you have even more
problems.
| I posted the URL to that code, which ought to be enough for anyone
| interested.
There is no way to ascertain that what is pointed to by a URL will remain
the same after it has been criticized. We have seen how some massively
dishonest _frauds_ on this newsgroup have altered the text of published
URLs (even without updating the version) in order to make their critics
look bad. Post the code and it will be very hard to "update" it.
| I repeat it here (and add a second one), in case you missed it:
| ftp://Samaris.tunes.org/pub/lang/cl/fare/md5.lisp
| http://tunes.org/cgi-bin/cvsweb/fare/fare/lisp/md5.lisp
I find it rather odd that you cannot destill your problems down to a few
simple cases. Everybody can look elsewhere for the full context, but it
_should_ be possible to show people your problems with an appropriate
excerpt. A good bug report contains a destilled example. A bad bug
report contains a million lines of rotten code with a single line "this
code is perfect, but your compiler does not conform to my wishes".
| > | The world has standardized on low-level byte streams as the universal
| > | medium for communication of data, including text.
| > Which is a mistake, since they run into an enormous amount of trouble
| > with supporting more than one character encoding.
| It is not a mistake - it is the natural thing to do in a world of
| proprietary black-box devices and software.
Huh? You have a special knack for non sequiturs. TEXT IS NOT BYTES.
You _really_ need to understand this. Failing that, you will run into
all sorts of problems, and there will be no end to your complaints, as I
suspect you have already noticed.
| I did it. But it's not portably interoperable with the character-based
| SEXP code that I have.
Really? Tell you what, when I wrote my MD5 functions for Allegro CL 5.0,
I stuffed it between the I/O system and the reader, and I reset and grab
the md5 hashes while reading characters from the stream. If I can do
this in Allegro CL, so can you in CMUCL. If you naively implement the
fairly stupid C model used for MD5, sending blocks of 64 "bytes" down to
a new function, instead of grabbing the input buffers of the stream, and
run into problems that you do not look into seriously in order to find a
better way, you are simply incompentent at what you do and should not
blame anyone else, _especially_ not the language.
| Using MD5 to portably support code version tagging, etc., becomes
| "interesting". By no means impossible. Just a PITA.
I have no idea what you are trying to talk about.
| No I'm not. And sometimes, I want to do only one. Sometimes, I want to
| do only the other. Sometimes, I am happy with the character processing
| done by my implementation (though it's not portable). Sometimes, I need
| precise control on the processing that happens (e.g. because I'm
| precisely transcoding stuff from one protocol to another). And
| sometimes, I want to do both byte-processing and text-processing at once
| on the same stream (at once: switching from one to the other, or even
| doing both character processing AND md5sum'ing on the same chunk).
I honestly fail to see the problem. In my view, it takes a fairly dense
programmer to fail to deal with these things intelligently. If you need
both byte stream and character stream, as you would do in HTTP, there are
two ways of doing that: so-called "bivalent" streams, from which you can
read both bytes and characters, but which introduces serious problems in
maintaining state information about non-trivial character codings, or
some means to switch the type of the stream between byte and character,
which communicates to the lower levels what you intend to do from now on.
If you need precise control, ask for it. Your system does _not_ do a lot
of weird magic that you have no control over. Just trust me on this, OK?
Go read the fine documentation and discover for yourself that you _can_
trust the implementation.
| In the latter cases, any implicit character processing done by the
| implementation is an abstraction inversion, to me.
Yes, to you, because you have _already_ inverted the model. You do _not_
convert from bytes to characters to bytes in order to do MD5 hashing on
the bytes -- the danger of losing the original byte values is too high no
matter how you do things. You have to get at the bytes where they are
actually found, just after they have been read, and just before they are
written. Anything else is pretty damn stupid.
| > if you are dealing with text, you deal with characters, not their
| > coding,
| Not even. I could be dealing with words, with sentences, with layout
| elements. In such contexts, characters are too low-level and not what I
| like.
I am sure you think this is relevant to something. Could you try to make
it a bit more clear what it is might be relevant to? No, never mind.
| Yet I don't resent of CL not standardizing on high-level protocols --
| it's things that can easily be implemented on top of them. However,
| wrongly standardizing on low-level things while adding restrictions to
| them is an abstraction inversion and it's wrong - it's the language
| getting in the way rather than helping.
Have you at all considered that _you_ might be wrong in any of this? If
not, I would actually like to hear your arguments for why your way of
seeing things is correct. I am getting tired of your non sequiturs and
the randomness of your "conclusions".
| I'm sorry I don't speak norvegian (yet). It means precisely what it says.
Oh, geez, you really _are_ a typically French retard. Well, thank you
for proving that my guess that your whining is due to your incredible
incompetence and the arrogance that only rabid ignorants who have no
desire to listen to anyone other than the voices in their head. You
really made it clear that you lack the ability to express yourself in
English, but when you resort to the kind of low-level idiocy you do, all
hope is lost that you will ever recover enough of your thinking ability
to get back on track.
Of _course_ Common Lisp does not match your wishes, Francois-Rene Rideau.
If it did, it would be a really stupidly designed language. I am happy
you were not around when things _were_ designed.
Incompetence on your scale should be punishable by law.
If you think you had some valid concerns about the language, back up and
do a better job of presenting them, unoccluded by your stupidity and
incompetence and your "wishes". I am quite sure you will find people
sympathetic to a number of language design issues when it comes to coding
stuff like MD5, but a good engineer knows when to use languages that are
better for some particular tasks than others. Bad engineers should just
be encouraged to become better at what they do, or to switch careers to
one in which they _could_ become good at what they do.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
Erik Naggum <····@naggum.net> writes:
> Incompetence on your scale should be punishable by law.
You mean one like this?
> Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
;-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Erik Naggum <····@naggum.net> writes:
> | Ask whom?
> This newsgroup, for instance.
Ok. Do you (or someone else in this newsgroup) have some MD5 code
that you (they) are willing to publish without any licensing issues?
That said, the remark I made "I was looking for a Common LISP implementation
of MD5, but found none" just was context, not a reproach to you or to anyone.
You seem to be looking for things to argue over.
> It is not an implementation in Common Lisp, but written in C as a
> low-level system function.
I was imprecise in my phrasing. I meant "implementation available to
Common LISP programmers". This was indeed not enough to satisfy my standards
(and even less so considering that this implementation is not available to
me but for testing purposes). I suppose I could have also written a FFI to C
for CMUCL or CLISP, but I didn't feel like doing both of it, and wanted
my code to run on both, as well as on Genera, ThinLisp, etc. In other words,
I purported to support the (maybe illusive) idea that there is a usable
portable Common LISP language.
[Skipped ad-hominem attacks]
> You really need to clue in that MD5 does not operate on characters.
Who said it did? (actually, the ACL6 interface does, but that's why
I extended it to work on octets arrays, too). Still, it operates on
streams that I also have to interpret as characters, in a different
context (notably so as to use, e.g. WRITE, FORMAT, and all those text
processing libraries). CL forces me to do double buffering (actually,
treble, or more), which sucks because of coding nightmares even more
than for the slowness.
> That some languages have no idea what a character is, but treat it like a
> small integer is really not something you can blame either MD5 or Common
> Lisp for.
I actually don't blame languages that treat characters as small integers.
They provide limited functionality indeed, but at least, they provide
some functionality you can portably build upon.
I do blame CL for providing an implementation-dependent notion of character
that is both too low-level to portably do any interesting thing with it,
and too high-level to allow for portable interaction with standard low-level
protocols.
> creating a new stream class that reads from those 64-byte buffers
> that you read from the input source and give to MD5.
Sure. That's why I was talking about double, treble, whatever, buffering,
which is overhead in programming time as well as in running time and space,
and qualifying that as "clumsy, inefficient, not portable, and
underspecified".
> | Once again, reading their specification, I happen to like the recent
> | things done by Franz (SIMPLE-STREAM), but it's unhappily not directly
> | applicable to me.
>
> Well, what makes it impossible for you to take their good ideas and
> implement them on your own?
>
Sure I can. (Well, someone else seems to be doing that for CMUCL).
However, so it would be no more portable CL, and so that it remains
"ported CL", I'd have to do it on each of the implementations I use
(although most of it could hopefully be done in portable CL).
> but for MD5, just break the 32-bit integers in half and operate on 16-bit
> values, instead.
Yes, I have thought about this. However, I began with 32-bit because it
was more natural, and hoped CMUCL could do well with it. It could do better.
I was happy enough with the implementation so as to decide to publish it
before to optimize it, if I ever do it (but then instead of writing ugly
implementation-specific LISP - some of my friends call that "bugware" -
I'd rather write efficient assembly and FFI code, and/or develop
a special-purpose subLISP compiler that would do that for me).
> I assure you that no significant performance loss is caused by this,
Thanks for the tip.
> and the algorithm does not increase in complexity because of it.
Sure, but the discussion matters only if we're already into constant factors.
> | I consider it bad practice to post large code files on USENET.
> Well, if your MD5 function is a large code file, then you have even more
> problems.
It is small by for a code file (700 lines, including lots of comments),
but I consider it large and noisy by USENET post standards.
> There is no way to ascertain that what is pointed to by a URL will remain
> the same after it has been criticized. We have seen how some massively
> dishonest _frauds_ on this newsgroup have altered the text of published
> URLs (even without updating the version) in order to make their critics
> look bad. Post the code and it will be very hard to "update" it.
>
Wow, you seem have really low expectations about people, at least on USENET.
Well, if this is the kind of things you fear, I have no shame posting the
MD5 of my current CVS release 1.8:
dd512185e07d1aeeab11454568eb14e9 md5.lisp
Unless I can break MD5, or modify bits on every USENET archive, there is no
way I can now retract my code. The file I had when I originally posted was not
yet on CVS, and I didn't keep a copy (one of the tens of people who downloaded
might have it), but apart from a few type declarations, added documentation
and reordering of definitions, it is essentially the same as the current one.
Notice that now that the code is on CVS, you can browse old versions at any
moment - so even in a year, you can check that the MD5 is the one I said.
http://tunes.org/cgi-bin/cvsweb/fare/fare/lisp/md5.lisp
> I find it rather odd that you cannot destill your problems down to a few
> simple cases.
Here's my problem #1 in a simple case: (ub32-add x y z)
Here's my problem #2 in a simple case: (char-code c)
Sometimes, the few paragraphs of explanation is as simple as it can get.
> A good bug report contains a destilled example.
Words are a good vector for distilled ideas.
> A bad bug report contains a million lines of rotten code [...]
Which is another reason why I chose not to post my code on USENET.
> with a single line "this code is perfect,
> but your compiler does not conform to my wishes".
My code is not perfect, and part of the reason it isn't
is that the language has deficiencies.
> | > | The world has standardized on low-level byte streams as the universal
> | > | medium for communication of data, including text.
> | > Which is a mistake, since they run into an enormous amount of trouble
> | > with supporting more than one character encoding.
> | It is not a mistake - it is the natural thing to do in a world of
> | proprietary black-box devices and software.
>
> Huh? You have a special knack for non sequiturs. TEXT IS NOT BYTES.
You have a knack for straw man arguments.
Of course, text is not bytes. The point is, it is easy to agree on bytes,
and impossible to agree on text. Since "binary-compatible" proprietary
software and hardware cannot be mended after-the-fact to account for
a moving low-level extensional representation for the high-level intentional
agreement on what text is, proprietary vendors can but standardize on
low-level protocols. So once again, of course, text is not bytes.
But any world-standard protocol for communicating text will be based on bytes.
> Really? Tell you what, when I wrote my MD5 functions for Allegro CL 5.0,
> I stuffed it between the I/O system and the reader, and I reset and grab
> the md5 hashes while reading characters from the stream. If I can do
> this in Allegro CL, so can you in CMUCL.
Sure I can. But I don't want to do it for CMUCL, SBCL, CLISP, Genera, ACL,
ThinLisp, and every other implementation. In other words, if I pick one
implementation and stick to it, I'd be fine - but then, so would I picking
a Scheme implementation, OCAML, or a system
> If you need precise control, ask for it. Your system does _not_ do a lot
> of weird magic that you have no control over. Just trust me on this, OK?
Sure. But each system does its own non-weird magic, in an incompatible way.
That's called non-portability. I'm not criticizing ACL, CMUCL, CLISP, Genera,
or anything - each does its stuff correctly. I'm just criticizing CL,
and there unhappily seems to be no one to ask about fixing that.
(Well, actually, raising the problem in c.l.l will hopefully attract the
attention of implementers on the problem and its known solutions,
so they might provide efficient APIs to multivalent strings/streams
and modular integer operations).
> You have to get at the bytes where they are
> actually found, just after they have been read, and just before they are
> written. Anything else is pretty damn stupid.
Sure. Who said otherwise? This just means more buffering to handle
(costs development, performance, space, semantic gap, etc.)
Actually, it calls for doing everything with bytes, and nothing with
characters (unless wrapped in a macro for immediate conversion), in
any portable program sensitive to such problems -- except that this
precludes the use of many text-processing libraries, which is
the abstraction inversion.
> | > if you are dealing with text, you deal with characters, not their
> | > coding,
> | Not even. I could be dealing with words, with sentences, with layout
> | elements. In such contexts, characters are too low-level and not what I
> | like.
> I am sure you think this is relevant to something. Could you try to make
> it a bit more clear what it is might be relevant to? No, never mind.
>
Your claim all throughout was that text-processing was not about bytes.
Well, it isn't about characters either, you know.
For instance, I am currently writing a small lisp program that dumps
annotated diagrams in LaTeX+MetaPost, which can be considered text-processing,
and, mind you, nowhere in it does the concept of character even appear.
Does that mean that a language ought to not standardize on characters,
since they are NEVER an interesting human-level concept, and instead,
standardize on TeX-style glyphs and graphic or symbolic structures? No.
Languages should standardize on bricks with which to build applications.
Bytes are a sensible such brick, especially in a world that talks in bytes.
Characters are not such a brick, and never will be in any world.
Having characters as an *extra* feature is good. Making it so they divert
programming efforts in a hell of portability problems is bad.
> a good engineer knows when to use languages that are better
> for some particular tasks than others.
Sure. No question that. However, when a same application requires many
different tasks, and interfacing languages incurs both programming overhead
and portability issues, you will see good engineers pushing languages
into solving tasks for which they are not the best suited.
Yours freely,
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
The fundamental class division in any society is not between rich and poor, or
between farmers and city dwellers, but between tax payers and tax consumers.
-- David Boaz, CATO Institute
You all have been warned!
Francois-Rene Rideau <···········@tunes.org> writes:
...
> [ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
> [ TUNES project for a Free Reflective Computing System | http://tunes.org ]
> The fundamental class division in any society is not between rich and poor, or
> between farmers and city dwellers, but between tax payers and tax consumers.
> -- David Boaz, CATO Institute
Ordinarily I refrain from making politics comments on c.l.l., but a
quote from somebody from the CATO institute merits at least a
sarcastic remark. Especially when such Think-Tank essentially work as
a pundit for the rich tax payers who do not want to pay taxes on
behalf of the poor tax consumers.
There! I said it!
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> You all have been warned!
> Francois-Rene Rideau <···········@tunes.org> writes:
> > [ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics |
> > http://fare.tunes.org ]
> > The fundamental class division in any society is not between rich
> > and poor, or between farmers and city dwellers, but between tax
> > payers and tax consumers. -- David Boaz, CATO Institute
> Ordinarily I refrain from making politics comments on c.l.l., but a
> quote from somebody from the CATO institute merits at least a
> sarcastic remark. Especially when such Think-Tank essentially work
> as a pundit for the rich tax payers who do not want to pay taxes on
> behalf of the poor tax consumers.
> There! I said it!
That doesn't prevent it from being a reasonably pithy saying, and even
if all you suggest is true, doesn't prevent it from having some truth.
If there's a serious and persistent imbalance between the tax burdens
of different groups of people, that _will_ lead to divisiveness,
regardless of whether CATO folk are to be regarded for good or for
ill.
.. Which vaguely ties to Lisp what with the old quote about Lispers
knowing the value of everything, but the cost of nothing ...
--
(reverse (concatenate 'string ····················@" "454aa"))
http://www.cbbrowne.com/info/sap.html
Talk a lot, don't you?
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3213650592348094@naggum.net>
* Francois-Rene Rideau <···········@tunes.org>
| Ok. Do you (or someone else in this newsgroup) have some MD5 code
| that you (they) are willing to publish without any licensing issues?
No. Part of the reason I do not publish my code anymore is that there
are too many incompetents and assholes out there that I specifically do
_not_ want to get access to my work if they do not compensate me for it.
After all, you are whining and complaining and posting a bunch of crap
because you are unwilling to do the work on your own, so giving _you_
this code without any licensing terms seems like a really bad idea.
| You seem to be looking for things to argue over.
Wrong. For some people who think it is their birthright to be imprecise
and sloppy and disrespectful, being taken seriously and expected to be
precise is sometimes extremely provocative. You seem to be one of those.
| [Skipped ad-hominem attacks]
Well, gee, your own are apparently OK, while you have a problem with
mine. That kind of double standard _really_ annoys me. If you do not
want what you call ad hominem attacks (but you are still imprecise --
look it up), simply avoid them yourself -- if _you_ cannot do this or do
now _want_ to do it, shut the fuck up about what anyone else does, OK?
| I suppose I could have also written a FFI to C for CMUCL or CLISP, but I
| didn't feel like doing both of it, and wanted my code to run on both, as
| well as on Genera, ThinLisp, etc.
So design a common FFI framework! I have designed and implemented one
for my own needs, but I find the number of disgusting losers who would
benefit from it if I published my code to be too high. Sharing should be
rewarding, not felt as a loss. I choose to withhold what I do from the
public because of the number of assholes who would never respect my
rights as an owner, but fortunately, they are honest enough to scream
bloody murder if someone wants them to sign a license agreement.
Withholding from the general public is in fact the _only_ option an
author has in these days of "open source" and "free software". I find
that many of the problems people have are in fact solved in an hour or
two, but I have great fun solving problems for their own sake (and anyone
who enjoys mathematics knows what I mean), but the fun that used to be
found in seeing somebody else use my code vanished years ago with the
agressiveness of the demands of the consumers of open source and free
software -- there used to be a sense of gratitude and respect towards
those who solved your problems for you and gave you code, but this is
replaced by lazy fucks who demand that others solve their problems for
them and get pissed off if somebody else refuse to give them their work
for free. This gives me solid reason to believe that certain problems
are problems only to incompetents and it also gives me a good way to
determine if certain "problems" are posted by trolls who do not really
want a solution to them. There are lots of people on the Net who only
want to get sympathy for their plight, not actually solve their problems.
That kind of whining wimps tick me off, and if I can help one of them
lose their job or fail an exam by not answering their stupid requests for
somebody else's work, that is good!
| In other words, I purported to support the (maybe illusive) idea that
| there is a usable portable Common LISP language.
There is, and you have not been betrayed because you need to do some hard
work to get something you want. In fact, that sense of betrayal you feel
is that same irrational attitude problem that comes from believing in a
"perfection" that somebody else owes to you.
| > You really need to clue in that MD5 does not operate on characters.
| Who said it did?
You did, when you complained about the character concept.
| Still, it operates on streams that I also have to interpret as
| characters, in a different context (notably so as to use, e.g. WRITE,
| FORMAT, and all those text processing libraries).
Well, considering that I have actually done precisely the same thing and
did not have _any_ or your problems, what does that tell me about you?
Sometimes, the only problem _is_ the person, but you do not believe me,
and _stupidly_ think everything is an ad hominem attack. Clue in, dude,
an ad hominem attack is an attack on the arguments via the person, it is
_not_ an attack on the person for something that person does wrong.
Arguing tha you cannot trust someone because he has a bad credit record
is ad hominem, sending his unpaid bills to a collection agency is not.
Using the fact that somebody has been caught with a Swiss Army pocket
knife in Oslo against them in a debate over efficienty Java is ad
hominem, arguing that it was not particularly nice to lie to the police
about the reason he carried it so he would not get into serious trouble
is not. But because you are not very precise, you will probably not
understand this difference. So I do not argue that you cannot be trusted
or your arguments suck because you are not very precise or pay much
attention to detail -- I simply point out that you are imprecise and do
not pay much attention to detail, and then I expect you to _fix_ that,
but since you are that stupid antagonistic, imprecise dude who seems to
think that "you seem to be looking for things to argue over" is a much
better approach to the criticism, you will not quite grasp what you are
being told in any case. That kind of arrogance is something that those
who suffer from it will exhibit in many ways, and the belief that their
code is perfect (or any flaws somebody else's fault) goes with it.
| CL forces me to do double buffering (actually, treble, or more), which
| sucks because of coding nightmares even more than for the slowness.
No, the language does _not_ force you to do that, damnit. Your very own
incompetence and extremely annoying _arrogance_ forces you to do that.
Just be smarter. Think more, whine less, work better.
| > That some languages have no idea what a character is, but treat it
| > like a small integer is really not something you can blame either MD5
| > or Common Lisp for.
| I actually don't blame languages that treat characters as small integers.
Huh? Nobody said you did, either. Do you argue against straw men, now?
| I do blame CL for providing an implementation-dependent notion of
| character that is both too low-level to portably do any interesting thing
| with it, and too high-level to allow for portable interaction with
| standard low-level protocols.
I think you need to explain your understanding of the character type,
because this sounds like the rantings of an incredibly incompetent person
who has not paid a lot of attention to detail in his life. The _fact_ is
that the implementation-dependent aspects of the character are precisely
those that manifest itself in the coding and representation which you
want to get access to directly. How you can fail to understand this is
truly amazing. I wonder when you were satisfied with your bogus belief
in "character flaw" as a good explanation for your problems. (If you
pardon the pun -- I simply could not resist. :)
| That's why I was talking about double, treble, whatever, buffering, which
| is overhead in programming time as well as in running time and space, and
| qualifying that as "clumsy, inefficient, not portable, and
| underspecified".
That is how you would implement them. Your implementation is only partly
a consequence of the language, and only a small part, because you have
contributed a lot more than the language has. I get really annoyed by
people who think that their algorithm and implementation is perfect and
if it does not work the way they want, it is somebody else's fault. You
are obviously that kind of person, and there is a serious flaw with your
thinking that you need to fix before you are willing and able to listen
to counter-arguments. As long as you protect your notion of perfect
implementation, you will never get anywhere.
| Sure I can. (Well, someone else seems to be doing that for CMUCL).
| However, so it would be no more portable CL, and so that it remains
| "ported CL", I'd have to do it on each of the implementations I use
| (although most of it could hopefully be done in portable CL).
Yes, it seems that you are one of those perennially dissatisfied people
who do not understand that the _only_ way you can arrive at portable
_interfaces_ to some common functionality is to write non-portable,
implementation-dependent code that implements them efficiently in a
particular Common Lisp system. In fact, I am frankly _stunned_ by the
lack of insight among people who want _both_ portable interfaces _and_
portable implementations of such interfaces. That is simply not how
things work. Common Lisp itself is a prime example: It is a supremely
portable language, yet requires massively implementation-dependent code
to implement correctly. Actually, it seems that it takes a particular
willingness to think things through that many people lack to figure out
that what comes out elegant and beautiful at the other end of a long
production line has been through a very _dirty_ process. Like, do you
think the factory that makes office furniture is as clean as the offices
their furniture is sold to, or that writing an elegant poem about love
and happiness did not require the usual incredible amount of pain that
getting a poem "right" requires? No, creating something beautiful takes
a lot of ugly, painful work. If you are not up to that, you really have
no business _demanding_ that other people do it for you, or complaining
that they have or do not. It is that demanding attitude that makes me
_not_ want to give people like you an easy way out of your problems.
| > but for MD5, just break the 32-bit integers in half and operate on 16-bit
| > values, instead.
| Yes, I have thought about this. However, I began with 32-bit because it
| was more natural, and hoped CMUCL could do well with it. It could do better.
| I was happy enough with the implementation so as to decide to publish it
| before to optimize it, if I ever do it (but then instead of writing ugly
| implementation-specific LISP - some of my friends call that "bugware" -
| I'd rather write efficient assembly and FFI code, and/or develop
| a special-purpose subLISP compiler that would do that for me).
Well, if you have friends like that, no wonder you have problems choosing
good engineering practices. Using implementation-specific things to
implement a common/standard interface to some functionality is not wrong,
it is in fact right, and a very good way to move forward and _get_ that
functionality, but if people do not want the functionality because they
cannot get it their perfect way, which it seems that the several Lisp
communities suffer from to a frighteningly high degree, they will not
_get_ that functionality, either.
| It is small by for a code file (700 lines, including lots of comments),
| but I consider it large and noisy by USENET post standards.
700 lines!? Geez. Using implementation-specific features in Allegro CL,
the core algorithm is 100 lines. Setting up and preparing for this short
and fast algorithm takes another 150 lines.
| My code is not perfect, and part of the reason it isn't is that the
| language has deficiencies.
You ridiculous idiot. You probably even _believe_ this bullshit.
| But I don't want to do it for CMUCL, SBCL, CLISP, Genera, ACL, ThinLisp,
| and every other implementation.
Have you ever wondered how all these implementations sprung into being
from nowhere when people like you do not want to implement things they
say they want? Ever wondered how all of this "free software" depends on
people's willingness to implement things that sometimes are _boring_ and
which some lazy fuck like yourself does not want to do?
| In other words, if I pick one implementation and stick to it, I'd be fine
| - but then, so would I picking a Scheme implementation, OCAML, or a system
It is not a question of picking one implementation and sticking with it,
but of actually using an implementation to get what you want. If you are
so inept that you cannot design and implement something with an interface
that does not expose the implementation-dependent features, that is not
the fault of any language. Whether to "stick with" an implementation is
an orthogonal issue to whether you use implementation-specific features.
If you want to make something really useful that needs to be portable or
the foundation for something portable, you will probably need to use some
implementation-specific features. If not, you could have done it fully
portably, right?
Then there is the issue of how _often_ you need to use such featuers to
implement common/standard things and how hard it is to do so. You seem
to believe that as soon as it is necessary to do something like this, you
have found a flaw in the language. This is fantastically misguided.
| But each system does its own non-weird magic, in an incompatible way.
| That's called non-portability.
If you use one implementation's internal stuff and expect it to work
elsewhere, yes, but it is the assumption that you can do that that is
flawed. If you use another implementation's internal stuff to provide
the same interface to the same functionality, you have done a good thing.
This is how smart programmers design both compatibility layers and pave
the ground for new standards.
| I'm just criticizing CL, and there unhappily seems to be no one to ask
| about fixing that. (Well, actually, raising the problem in c.l.l will
| hopefully attract the attention of implementers on the problem and its
| known solutions, so they might provide efficient APIs to multivalent
| strings/streams and modular integer operations).
So if I understand you right, you think it is perfectly OK for a vendor
to use internal, implementation-specific features to implement a common
or standard specification (or, in case you are not quite up that level of
quality, just fix things your way), that is perfectly OK, but if you do
it yourself, it is _not_ OK? Just _why_ is it that you cannot do this
yourself? What makes it so important to you that somebody else do the
dirty work that you do not want to do yourself?
| > You have to get at the bytes where they are actually found, just
| > after they have been read, and just before they are written.
| > Anything else is pretty damn stupid.
| Sure. Who said otherwise?
You have strongly implied "otherwise", you insuffable numbnut.
| This just means more buffering to handle (costs development, performance,
| space, semantic gap, etc.)
... and this is where you say it! This "more buffering" crap that _you_
think is necessary is in fact _not_ necessary for your particular needs.
As you well know, the MD5 algorithm uses 64-byte blocks and it does not
care one hoot where they are. If you use the _same_ buffer that you just
read data into from the external source, you can actually get at the raw
bytes _before_ they are interpreted as characters. This is not hard to
do. This is not even difficult. This is _not_ rocket science. All this
requires is that you are willing to study your implementation or talk to
the vendor and get at the underlying buffer. You are really annoying in
the way you keep thinking that no better solution than your own can exist.
| Actually, it calls for doing everything with bytes, and nothing with
| characters (unless wrapped in a macro for immediate conversion), in any
| portable program sensitive to such problems -- except that this precludes
| the use of many text-processing libraries, which is the abstraction
| inversion.
Wrong, you insufferable numbnut.
| Your claim all throughout was that text-processing was not about bytes.
| Well, it isn't about characters either, you know.
Sigh. Quit your stupid game-playing, will you?
I think you are no more than another stupid troll who will never be
satisfied no matter what anyone provides you with, and who will certainly
never do any decent work on your own to get what you claim to want.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
In article <················@naggum.net>, Erik Naggum wrote:
>* Francois-Rene Rideau <···········@tunes.org>
>| Ok. Do you (or someone else in this newsgroup) have some MD5 code
>| that you (they) are willing to publish without any licensing issues?
>
> No. Part of the reason I do not publish my code anymore is that there
> are too many incompetents and assholes out there that I specifically do
> _not_ want to get access to my work if they do not compensate me for it.
Similarly, people who apply the GNU license to the programs don't want
assholes to take code and spin it into a proprietary program that carries
use restrictions, doesn't permit redistribution, has no source code and
so on. So you see, it boils down to your definition of ``asshole'',
which is generally a subjective specialization of ``someone who does
things I very strongly disapprove of''.
In article <···················@news1.rdc1.bc.home.com>, Kaz Kylheku wrote:
> In article <················@naggum.net>, Erik Naggum wrote:
>>* Francois-Rene Rideau <···········@tunes.org>
>>| Ok. Do you (or someone else in this newsgroup) have some MD5 code
>>| that you (they) are willing to publish without any licensing issues?
>>
>> No. Part of the reason I do not publish my code anymore is that there
>> are too many incompetents and assholes out there that I specifically do
>> _not_ want to get access to my work if they do not compensate me for it.
>
> Similarly, people who apply the GNU license to the programs don't want
> assholes to take code and spin it into a proprietary program that carries
> use restrictions, doesn't permit redistribution, has no source code and
> so on. So you see, it boils down to your definition of ``asshole'',
> which is generally a subjective specialization of ``someone who does
> things I very strongly disapprove of''.
I think you have missed something here, Erik's position does not
encumber other people by not releasing his code and the gpl does place
oblagations on people(in theory, it has not been tested in court as
far as I know) of the type you must give me back/make avalable your
source code. There are several expences involved in this, here is a
short list:
1: you need to keep it avalible on the internet, you need to rent some
space & bandwitdth
2: you need to keep backups and keep track of them, for all versions
of your software that is encumbered with gpl, to the best of my
knoledge
3: if you fail to do 1 and 2 you could get sued by some one else and
draged through the legal system, always fun.
A quick aside look at freebsd getting turned into OS X. Apple did the
right thing (darwin) and kept parts closed source, which is there
right under the bsd licence.
Also the GPL does not realy hurt big companys, they see an idea they
have the resources to copy it with out touching the source. The
people the gpl hurts are small businesses that do not have the
resources to reimplement everything by denying them the ability to
recoup there investment and/or protect any trade secretes that are
used in their derived work. This hurts people who could use the
product and the businesses that could make them. I would even say it
hurts open source because it deprives them of a source of good
commericaly viable ideas to build projects around, producte with an
installed base give open source cloning projects a much better chance
at success.
One last thing, if I add enough value to get people to pay me money
even when there is a free version avalable, am I not entitled to the
fruits of my labor?
Good night
,arc
In article <···················@oscar.eng.cv.net>, "Marc Spitzer"
<····@oscar.eng.cv.net> wrote:
> I think you have missed something here, Erik's position does not
> encumber other people by not releasing his code and the gpl does place
> oblagations on people(in theory, it has not been tested in court as far
> as I know) of the type you must give me back/make avalable your source
Lest you think that the fact that the GPL hasn't been tested in court
somehow makes it legally shaky, you might be interested in
http://www.gnu.org/philosophy/enforcing-gpl.html. In that article the
FSF's legal counsel argues that the GPL hasn't been tested in court
precisely because it is solid, potential GPL violators understand that, and don't
want to lose in court.
> code. There are several expences involved in this, here is a short
> list:
> 1: you need to keep it avalible on the internet, you need to rent some
> space & bandwitdth
> 2: you need to keep backups and keep track of them, for all versions of
> your software that is encumbered with gpl, to the best of my knoledge
> 3: if you fail to do 1 and 2 you could get sued by some one else and
> draged through the legal system, always fun. A quick aside look at
This is just silly. Maybe you're imagining a scenario in which you don't
provide the source along with binaries? If you really want to do that, you're allowed to
charge for providing the source if requested. I don't see anything in
the GPL that says you must provide the exact source that produced
whatever version an enduser has.
> One last thing, if I add enough value to get people to pay me money even
> when there is a free version avalable, am I not entitled to the fruits
> of my labor?
Sure, but not against the wishes of those who provided you the basis for
free.
Tim
In article <············@216.39.145.192>, Tim Moore wrote:
> In article <···················@oscar.eng.cv.net>, "Marc Spitzer"
> <····@oscar.eng.cv.net> wrote:
>
>
>> I think you have missed something here, Erik's position does not
>> encumber other people by not releasing his code and the gpl does place
>> oblagations on people(in theory, it has not been tested in court as far
>> as I know) of the type you must give me back/make avalable your source
> Lest you think that the fact that the GPL hasn't been tested in court
> somehow makes it legally shaky, you might be interested in
> http://www.gnu.org/philosophy/enforcing-gpl.html. In that article the
> FSF's legal counsel argues that the GPL hasn't been tested in court
> precisely because it is solid, potential GPL violators understand that,
> and don't want to lose in court.
>
first just because I dont want to go to court over it(spemd lots of
money and time) does not mean I think it is valid. Remember the FSF
has to defend ther GPL and its fellows because if they loose in court
it attacks there reason for existence. They loose there one big club.
And what else it the lawyer going to say, "this has wholes you could
drive a truck through" perhaps? He/she has a legal responability to
represent his clients best interests.
>> code. There are several expences involved in this, here is a short
>> list:
>> 1: you need to keep it avalible on the internet, you need to rent some
>> space & bandwitdth
>> 2: you need to keep backups and keep track of them, for all versions of
>> your software that is encumbered with gpl, to the best of my knoledge
>> 3: if you fail to do 1 and 2 you could get sued by some one else and
>> draged through the legal system, always fun. A quick aside look at
>
> This is just silly. Maybe you're imagining a scenario in which you don't
> provide the source along with binaries? If you really want to do
> that, you're allowed to
> charge for providing the source if requested. I don't see anything in
> the GPL that says you must provide the exact source that produced
> whatever version an enduser has.
I have to get in the source archiving busness for at least 3 years
from the date I stop developing to comply with the gpls licence if I
supply a binary package(rpm).
>
>> One last thing, if I add enough value to get people to pay me money even
>> when there is a free version avalable, am I not entitled to the fruits
>> of my labor?
>
> Sure, but not against the wishes of those who provided you the basis for
> free.
If they provided it to me for free then they would not have packaged
it with obligations that effect all my other work that comes in
contact with it. Since they did add this to there work by there
choice how can you call this free? There is definatly a charge
against me being made and the cost is linked to how much work I do
using gpled products.
>
> Tim
marc
Erik Naggum <····@naggum.net> writes:
> Part of the reason I do not publish my code anymore is that there
> are too many incompetents and assholes out there that I specifically do
> _not_ want to get access to my work if they do not compensate me for it.
With such an attitude, I think it is useless for you to wonder why
people do not ask you anything.
> | [Skipped ad-hominem attacks]
> Well, gee, your own are apparently OK, while you have a problem with
> mine. That kind of double standard _really_ annoys me.
I have tried hard not to make any such attack in the current thread.
I apologize if there is anything that could be construed as such in
my messages.
> So design a common FFI framework!
That's indeed a good idea of thing to do.
> I have designed and implemented one for my own needs,
> but I find the number of disgusting losers who would
> benefit from it if I published my code to be too high.
> Sharing should be rewarding, not felt as a loss.
It sure should be. I regret that you do not feel it is.
If you are only ready to help people better than yourself,
you'll find that the only people whom you accept to help
are those who don't need your help.
> if I can help one of them
> lose their job or fail an exam by not answering their stupid requests for
> somebody else's work, that is good!
I think your are wasting your precious time with them? Just ignore them.
You will thus do yourself (and them) a favor.
You seem to me to react like you take perfection as a granted ideal
such that ethical behaviour consists in destroying whatever is imperfect.
I think that that on the contrary, perfection is an unreached ideal
such that ethical behaviour consists in building more perfect things.
> | In other words, I purported to support the (maybe illusive) idea that
> | there is a usable portable Common LISP language.
> There is, and you have not been betrayed because you need to do some hard
> work to get something you want.
I do not feel "betrayed" - nobody owes me anything.
I feel like there is a room for improvement,
the perception of which can be usefully discussed
in such a community forum as comp.lang.lisp.
> Clue in, dude,
> an ad hominem attack is an attack on the arguments via the person, it is
> _not_ an attack on the person for something that person does wrong.
Granted. Whereas you are only very rude and quick to ignore or dismiss
arguments (rather than actually attack them) once you decided that
someone was a bad person.
> I simply point out that you are imprecise
And I thank you for it.
> and do not pay much attention to detail,
> and then I expect you to _fix_ that,
I will try to.
> | CL forces me to do double buffering (actually, treble, or more), which
> | sucks because of coding nightmares even more than for the slowness.
> No, the language does _not_ force you to do that, damnit.
Indeed, if I manage to avoid characters altogether (and thus not use any
character-based library), or else use non-portable extensions (and lose
some interoperability) I can avoid double-buffering. This is a worthwhile
engineering tradeoff to consider. But I argue that this is a current flaw
in the language.
> | > That some languages have no idea what a character is, but treat it
> | > like a small integer is really not something you can blame either MD5
> | > or Common Lisp for.
> | I actually don't blame languages that treat characters as small integers.
> Huh? Nobody said you did, either. Do you argue against straw men, now?
I didn't say you did. I tried to clarify and argue my opinion,
which from your post I construed to be opposite to yours.
> The _fact_ is that the implementation-dependent aspects of the
> character are precisely those that manifest itself in the coding
> and representation which you want to get access to directly.
No. I do not want to access implementation-dependent aspects of the character.
I want to access protocol-dependent aspects of the character, in an
implementation-independent way. Sometimes, the protocol and the
implementation agree, and then I like to be able to take advantage of it;
sometimes they do not, and I find it a pity that it makes reuse of
code designed to manipulate characters a nuisance.
> I get really annoyed by
> people who think that their algorithm and implementation is perfect and
> if it does not work the way they want, it is somebody else's fault. You
> are obviously that kind of person,
I know many flaws in my code (it notably does much more consing
that it should, which currently makes it very slow on big data -
but for big data I call /usr/bin/md5sum, anyway, so that's not
a bottleneck to me right now - on the other hand, the way I call an
external program might or not leak memory, which is not a concern to
me right now but might become in the future).
> the _only_ way you can arrive at portable
> _interfaces_ to some common functionality is to write non-portable,
> implementation-dependent code that implements them efficiently in a
> particular Common Lisp system.
Well, the fact that something implementation-dependent has to be done
for efficiency is precisely what an "abstraction inversion" is about
when you try to do it portably. I argue it's a flaw in a language;
a flaw that may be part of a valid engineering tradeoff in the
design and implementation of said language, but a flaw nonetheless.
A lot of useful code is written in LISP, C, C++, Java, OCAML, SML,
Python, Perl, etc., that is written in a portable way and provide
portable interfaces efficiently. But various languages have various flaws;
CL has a lot of interesting features that other languages have not,
it has also flaws that other languages have not; this means that the
potential non-portability issues or abstraction inversions come at
different places in various languages. Tradeoff? Maybe.
But it is interesting to discuss these tradeoffs.
> creating something beautiful takes a lot of ugly, painful work.
Indeed. But the pain is not the goal, the beauty is. Fruitful discussions
help determine how to achieve more beauty with less pain.
> Using implementation-specific things to
> implement a common/standard interface to some functionality is not wrong,
> it is in fact right,
Indeed. *Having to do it* is the wrong, and *doing it* is the right
that hopefully fixes that wrong. The cost of doing it is the measure of
the wrong. Better ways of doing it alleviate the wrong,
worse ways increase it. Discussing is a way to find better ways.
> 700 lines!? Geez. Using implementation-specific features in Allegro CL,
> the core algorithm is 100 lines. Setting up and preparing for this short
> and fast algorithm takes another 150 lines.
I get the approximate same code size. The rest is documentation, and
a collection of functions to portably mock up the implementation-specific
features you use, until each implementation has them. I also add lots of
declarations in an attempt to keep the CMUCL compiler happy.
> Have you ever wondered how all these implementations sprung into being
> from nowhere when people like you do not want to implement things they
> say they want?
Uh? My post was precisely about code I was publishing.
I admit I should be back to coding -- wasted more than enough time
posting on USENET.
> Ever wondered how all of this "free software" depends on
> people's willingness to implement things that sometimes are _boring_ and
> which some lazy fuck like yourself does not want to do?
It's not boring when it's the Right Thing(tm)
(or rather, the joy overcomes the bore).
> It is not a question of picking one implementation and sticking with it,
> but of actually using an implementation to get what you want.
Maybe you should explain the difference.
> interface that does not expose the implementation-dependent features
In the case of modular integers that's easy.
In the case of doing the Right Thing(tm) with characters, that's difficult.
For other flaws in CL (modularity, concurrency, etc.),
I doubt it is possible.
> You seem to believe that as soon as it is necessary to do something
> like this, you have found a flaw in the language.
Yes. It might not be a big flaw (depending on what it is),
but it is a flaw nonetheless.
> | > You have to get at the bytes where they are actually found, just
> | > after they have been read, and just before they are written.
> | > Anything else is pretty damn stupid.
> | Sure. Who said otherwise?
> [...] You have strongly implied "otherwise", you insuffable numbnut.
In as much as I might not always be precise enough in what I say,
you read everything with negative prejudice and then become rude.
> [...] All this requires is that you are willing to study your
> implementation or talk to the vendor and get at the underlying buffer.
"All this requires" for a portable program is thus a lot of work in each
implementation to achieve desired functionality efficiently.
So this particular flaw is fixable (and being fixed, it seems).
It's still a flaw.
Back to coding,
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
I made it a rule to forbear all direct contradictions to the sentiments of
others, and all positive assertion of my own. I even forbade myself the use
of every word or expression in the language that imported a fixed opinion,
such as "certainly", "undoubtedly", etc. I adopted instead of them "I
conceive", "I apprehend", or "I imagine" a thing to be so or so; or "so it
appears to me at present".
When another asserted something that I thought an error, I denied myself the
pleasure of contradicting him abruptly, and of showing him immediately some
absurdity in his proposition. In answering I began by observing that in
certain cases or circumstances his opinion would be right, but in the present
case there appeared or semed to me some difference, etc.
I soon found the advantage of this change in my manner; the conversations I
engaged in went on more pleasantly. The modest way in which I proposed my
opinions procured them a readier reception and less contradiction. I had
less mortification when I was found to be in the wrong, and I more easily
prevailed with others to give up their mistakes and join with me when I
happened to be in the right.
-- Autobiography of Benjamin Franklin
Francois-Rene Rideau <···········@tunes.org> writes:
> Erik Naggum <····@naggum.net> writes:
> > | CL forces me to do double buffering (actually, treble, or more), which
> > | sucks because of coding nightmares even more than for the slowness.
> > No, the language does _not_ force you to do that, damnit.
> Indeed, if I manage to avoid characters altogether (and thus not use
> any character-based library), or else use non-portable extensions
> (and lose some interoperability) I can avoid double-buffering. This
> is a worthwhile engineering tradeoff to consider. But I argue that
> this is a current flaw in the language.
No, this seems rather more like a misunderstanding on your part.
You're half understanding that using characters is a Bad Idea; you
have to get the rest of the way, and conclude that using characters is
not only a Bad Idea, but also pointless.
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://www.cbbrowne.com/info/sap.html
"Oh, I've seen copies [of Linux Journal] around the terminal room at
The Labs." -- Dennis Ritchie
In article <··············@Samaris.tunes.org>, Francois-Rene Rideau wrote:
> Erik Naggum <····@naggum.net> writes:
>> Part of the reason I do not publish my code anymore is that there
>> are too many incompetents and assholes out there that I specifically do
>> _not_ want to get access to my work if they do not compensate me for it.
> With such an attitude, I think it is useless for you to wonder why
> people do not ask you anything.
Well every time anyone posts a question or a request for help here
thea are asking Erik, among many others, for help. And he does know
his lisp and programing.
>
>> | [Skipped ad-hominem attacks]
>> Well, gee, your own are apparently OK, while you have a problem with
>> mine. That kind of double standard _really_ annoys me.
> I have tried hard not to make any such attack in the current thread.
> I apologize if there is anything that could be construed as such in
> my messages.
>
>> So design a common FFI framework!
> That's indeed a good idea of thing to do.
>
>> I have designed and implemented one for my own needs,
>> but I find the number of disgusting losers who would
>> benefit from it if I published my code to be too high.
>> Sharing should be rewarding, not felt as a loss.
> It sure should be. I regret that you do not feel it is.
> If you are only ready to help people better than yourself,
> you'll find that the only people whom you accept to help
> are those who don't need your help.
>
I think you mis read this, Erik is complaining about leaches. What I
read in his statment is that he has a big problem with people who not
only use his work with out being gracious about it but they demand
more work from him for free. A few mails like "buddy where is my
fuckking feature!!!" would piss me off royally. One thing that is
glossed over in open source is that the majority of people who can not
produce software are asking the small minority who can to do them a
BIG FAVOR but most of the end users act like it is a right, "where is
my applacation, I want it now". Now if we have a contracr or I work
for you or you are a customer of mine then that attatude might be
reasonable, but as a person who I no business relation ship asking me
to do something that they could not do them selves for free and then
giving me shit, go fuck yourself.
>> if I can help one of them
>> lose their job or fail an exam by not answering their stupid requests for
>> somebody else's work, that is good!
> I think your are wasting your precious time with them? Just ignore them.
> You will thus do yourself (and them) a favor.
> You seem to me to react like you take perfection as a granted ideal
> such that ethical behaviour consists in destroying whatever is imperfect.
> I think that that on the contrary, perfection is an unreached ideal
> such that ethical behaviour consists in building more perfect things.
>
Being intolerant of bad work encourages good work, no? So if a person
is intolerant of junk he is encouraging people to make the world a
better place. So Erik apears to be helping you along the road to
perfection, acording to your statement he is behaving in an ethical
manner.
Good night
marc
From: Juliusz Chroboczek
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <87d72uuqz3.fsf@pps.jussieu.fr>
Marc Spitzer:
MS> A few mails like "buddy where is my fuckking feature!!!" would
MS> piss me off royally.
An Emacs Lisp function that replies ``I am not currently interested in
commercial consulting'' does wonders. You'll never hear from them
again.
The problem (I find) is with nice people who submit code for inclusion
in a future version, and get offended when you refuse on stylistic grounds.
Juliusz
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214224141578177@naggum.net>
* Juliusz Chroboczek
| The problem (I find) is with nice people who submit code for inclusion
| in a future version, and get offended when you refuse on stylistic grounds.
Well, try submitting something that uses standard if, when, unless, or
loop, to people who believe in a certain "Lisp Coding Standard" document
and get chided for using standard Common Lisp. It is certainly rejection
on stylistic grounds, but so irrational that future attempts to deal with
such people is tainted with an unanswered "why bother?". In many cases,
stylistic grounds are indeed irrational as seen from the receiver, and
the most rational thing in the world by the person arguing them, but it
is probably fair to assume that the submitter of a thus rejected patch is
in his right to consider the argument irrational, and probably the person
who argues with them. On the other hand, the inability to continue to
use a style that the code alrady uses may just be irrationally stubborn
or ignorant, but it depends a little on how the style evolved. If it is
the kind of style that deprecates standard features in favor of a bogus
"invention" of the writer, that writer is trying to build a community all
of his own, explicitly rejecting the community that the suggester would
like to belong to. I find such behavior offensive and good grounds never
again to submit code to such people. Fortunately, there are usually only
single individuals who are so beyond reach.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
From: Juliusz Chroboczek
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <87d72tb415.fsf@pps.jussieu.fr>
| The problem (I find) is with nice people who submit code for inclusion
| in a future version, and get offended when you refuse on stylistic grounds.
Erik Naggum:
EN> Well, try submitting something that uses standard if, when, unless, or
EN> loop, to people who believe in a certain "Lisp Coding Standard" document
EN> and get chided for using standard Common Lisp.
I was thinking of a person who rewrote a quick hack of mine in what he
described as ``clean and elegant object-oriented Perl.'' He got badly
offended when I refused to maintain his code, and suggested that he
may want to distribute it himself.
EN> that writer is trying to build a community all of his own,
EN> explicitly rejecting the community that the suggester would like
EN> to belong to.
Yes, I think that's a fair description. I explicitly reject the
community that believes in such a thing as ``clean and elegant
object-oriented Perl.''
Juliusz
You make a good point that programs within a language
that use only built-in features of that language
cannot be classified as having the same style.
Any sufficiently rich language can support many different styles.
Common Lisp is certainly a language that supports
many many styles. I've seen code written in a
Fortran style (lots of prog's, tagbody's and go's)
and in a scheme style (passing "continuations" in
as arguments to functions). And there are many other
styles as well.
Common Lisp also supports macros and it shows a
*profound* lack of understanding of Common Lisp if someone
were to suggest that making use of this very important
and powerful feature of Common Lisp was rejection of the
Common Lisp community.
In article <··························@news.dnai.com>, John Foderaro wrote:
> Common Lisp also supports macros and it shows a
> *profound* lack of understanding of Common Lisp if someone
> were to suggest that making use of this very important
> and powerful feature of Common Lisp was rejection of the
> Common Lisp community.
one point, you are making no distinction between proper use of the
power available and the abuse of that power. There is a serious moral
issue here, should I use the power I have with restraint where it is
proper to do so and with due consideration for its impact on the
community as a whole or not. Should macros be used to expand the
language or fragment it.
marc
In article <····················@oscar.eng.cv.net>, ····@oscar.eng.cv.net
says...
> Should macros be used to expand the
> language or fragment it.
>
Every macro expands the language *and* fragments it.
There will be people who understand the macro and those
that don't. That's your fragmentation.
Adding the extended loop macro has fragmented the
Common Lisp community more than any other macro.
The people who use it write code that the people who
dislike it can't even read.
Was it morally wrong to add the extended loop macro
to Common Lisp?
I don't think so. Lisp is a language you can evolve
to suit your needs. When you write a macro or even
a function you separate people into those who
know and understand it and those that don't.
The Common Lisp community is not one giant brain
that learns things simultaneously. People must develop
things independently and put them out there for
Lisp to grow.
John Foderaro wrote:
> In article <····················@oscar.eng.cv.net>, ····@oscar.eng.cv.net
> says...
>> Should macros be used to expand the
>> language or fragment it.
>>
>
>
> Every macro expands the language *and* fragments it.
> There will be people who understand the macro and those
> that don't. That's your fragmentation.
I think it simply fragments people into those who _use_ it
and those who don't _use_ it. It has nothing to do with "understanding"
since that would imply that there is one right thing (tm) where often
both ways are perfectly rational.
> Adding the extended loop macro has fragmented the
> Common Lisp community more than any other macro.
> The people who use it write code that the people who
> dislike it can't even read.
> Was it morally wrong to add the extended loop macro
> to Common Lisp?
>
> I don't think so. Lisp is a language you can evolve
> to suit your needs. When you write a macro or even
> a function you separate people into those who
> know and understand it and those that don't.
Yes I agree (besides of the repeated "understand" here).
I think the problem is not that macros (or whatever facility else)
fragment the community but more what follows from there. If both camps
can tolerate each others preferences all goes well - if one camp tries to
shut up the other camp by postulating them evil, dumb or simply "not
understanding ones" *then* the things stop being manageable.
I particularily like Common Lisp because it is a language that often chooses
to include multiple ways of thinking about something if no final consensus
has been reached. You are perfectly welcome to invent new things if you do
not try forcing others that _their_ approach is not permitted to use.
I _always_ hated people that are trying to _forbid_ me doing things the way
I liked it and I prefer not working with them anymore instead of being a
slave drone.
The irony is that in reality "intolerance" is intolerable. ;-)
ciao,
Jochen
--
http://www.dataheaven.de
From: John Foderaro
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3BEB17C0.5090801@franz.com>
Jochen Schmidt wrote:
>
> I think it simply fragments people into those who _use_ it
> and those who don't _use_ it. It has nothing to do with "understanding"
> since that would imply that there is one right thing (tm) where often
> both ways are perfectly rational.
>
I meant 'understanding' in the most basic sense.
when you see
(with-slot-frobbers (x 'slota 'slotb)
...)
you will either know what with-slot-frobbers does
or you won't.
So this macro has divided the world into those who
understand with-slot-frobbers and those who don't (yet).
John Foderaro <···@franz.com> writes:
> I meant 'understanding' in the most basic sense.
Why are you quoting the word "in"?
(Ignore me. It was out-of-place and probably failed humor that belonged
in a different thread. ;-)
In article <····················@oscar.eng.cv.net>, Marc Spitzer wrote:
>community as a whole or not. Should macros be used to expand the
>language or fragment it.
I think they should be used to transform destructuring lambda lists into
objects to be treated as forms that are substituted in place of the
macros.
····@oscar.eng.cv.net (Marc Spitzer) writes:
> In article <··························@news.dnai.com>, John Foderaro wrote:
> > Common Lisp also supports macros and it shows a
> > *profound* lack of understanding of Common Lisp if someone
> > were to suggest that making use of this very important
> > and powerful feature of Common Lisp was rejection of the
> > Common Lisp community.
>
> one point, you are making no distinction between proper use of the
> power available and the abuse of that power. There is a serious moral
> issue here, should I use the power I have with restraint where it is
> proper to do so and with due consideration for its impact on the
> community as a whole or not. Should macros be used to expand the
> language or fragment it.
In what way would this be any different a question if asked about functions
and not macros?
In article <···············@shell01.TheWorld.com>, Kent M Pitman wrote:
> ····@oscar.eng.cv.net (Marc Spitzer) writes:
>
>> In article <··························@news.dnai.com>, John Foderaro wrote:
>> > Common Lisp also supports macros and it shows a
>> > *profound* lack of understanding of Common Lisp if someone
>> > were to suggest that making use of this very important
>> > and powerful feature of Common Lisp was rejection of the
>> > Common Lisp community.
>>
>> one point, you are making no distinction between proper use of the
>> power available and the abuse of that power. There is a serious moral
>> issue here, should I use the power I have with restraint where it is
>> proper to do so and with due consideration for its impact on the
>> community as a whole or not. Should macros be used to expand the
>> language or fragment it.
>
> In what way would this be any different a question if asked about functions
> and not macros?
>
I see your point the if* function would be an equaly bad idea, but
I don't think it would be possable for this to work as a function.
marc
····@oscar.eng.cv.net (Marc Spitzer) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman wrote:
> ...
> > In what way would this be any different a question if asked about functions
> > and not macros?
> >
>
> I see your point the if* function would be an equaly bad idea, but
> I don't think it would be possable for this to work as a function.
It's not about that.
Forget how they're applied. In code, you see a lot of
(this (that (the-other)))
where this, that, and the-other are variously functions or macros.
The question of whether macros should expand the language [community]
or fragment it is no different sociologically than the question of
whether functions or even variables should. Every name you introduce
that is nonstandard risks dividing the community, but on balance adds
potential power to someone at the same time.
If you'd had a CAR*, we'd be fighting over that. It's not a macro issue.
The problem comes when some people (I think somewhat rightly) feel
that IF doesn't really add power, and so it divides the community for
nothing. We made CL in the believe that being standard was more
powerful than being uniquely right. The choices in CL aren't all
defensible as "uniquely right", but they were intended to appease the
CL community enough that we didn't waste time (as we used to in the
past) arguing whose LET to use (does it have tagbody or not, must I
init my variables, etc), whose backquote (does it do a full copy or
only an if-needed copy), etc. It was getting boring. So we nailed it
down. We're supposed to have moved beyond those things to new areas
to bicker about.
The if* macro is much older than Common Lisp. I've used it a long
time and since I have to read code that uses it and code that doesn't
use it I'm continually made aware that it solves the problem it was
intended to solve. Thus I'd like to continue to use it.
However suppose you were given the power today to tell me that I can no
longer use if*. Would you tell me that?
.. and unrelated to that here's an editorial opinion (not directed
specifically at any one person):
You talk about "community standards" and that's a very politically
correct term that doesn't raise anyone's shackles. However I think
that Marc Spitzer hit the nail on the head when he talked about the "morality"
of writing a macro. We can make the definition that if it was
immoral of me to write the if* macro then if* is an immoral macro.
Now I hope that people are starting to get bothered by such
a declaration. Is it the case that the ANSI spec laid down the laws
as to what's a legal and non-legal Common Lisp program but now
some people are saying that legal Common Lisp programs are divided
between moral and immoral programs? The decision as to what's moral
is made by self appointed people who read the scriptures (ANSI spec)
and come to their own interpretation and feel they can speak for the members
of the congregation (er.. I mean common lisp community).
Shall we anoint a Pope? I know of one militant Common Lisp fundamentalist
who's been terrorizing non believers here for years who would love to
be able to force his will on others in the name of the community.
The beauty of morality arguments over proofs is that contradictions
are just fine. You can say "Thou shalt not write control flow macros
that duplicate what's in Common Lisp" and claim that if* is immoral
and at the same time say that when and unless are perfectly find macros
and in fact divinely inspired.
Or just maybe we should once again step back from the brink of registering
Common Lisp as a religion. It's a programming language folks!!
It's a tool to get a job done. Use it any way you want and don't
let anyone tell you differently. If you do something interesting
share it with the group. They may not pick up on it but at least
you tried. Chance are a few people will find it interesting.
A lot has occurred in the software world since Common Lisp was designed.
Lisp can and must absorb new ideas from other languages to maintain
its leadership position (even if these new ideas end up being
control flow macros that duplicate existing common lisp ones).
Also no person on this newsgroup speaks for the community. Don't
be bullied into believing otherwise.
John Foderaro wrote:
> The if* macro is much older than Common Lisp. I've used it a long
> time and since I have to read code that uses it and code that doesn't
> use it I'm continually made aware that it solves the problem it was
> intended to solve. Thus I'd like to continue to use it.
>
> However suppose you were given the power today to tell me that I can no
> longer use if*. Would you tell me that?
At least _I_ would never tell you that *you* are not allowed to use IF*.
But we _still_ have to disjunct arguments here:
- Should you be forced not to use IF*?
No - definitely not! But at the _same_ emphasis _you_ cannot force
others to use it or even to use it explicitely!
- If IF* a good idea for inclusion into a standard
To answer this question we would have to discuss (again...) what the
merits of IF* are. For building a community standard I think it is
ok to include it if a significant amount of people use it and as long
as a reference implementation is made public. (At least the latter is
already done)
Note that my opinion of the latter point is because I think it is better to
include a facility used by a significant subset of the community over
disciminizing them by explicitely not including it. Note too that this does
_not_ imply including the attitude to forbid use of IF, WHEN , UNLESS
instead of IF*.
We have to realize that the topic IF* is not only yet another control-macro
but also the try to enforce the not-usage of some other facilities!
Now you can claim that it was the whole point of IF* was to replace the
other constructs and without that it would not much sense - if that is true
then the answer if IF* (seen at a whole) is _not_ morally tolerable because
it would include discriminating others style of programming.
ciao,
Jochen
--
http://www.dataheaven.de
I can't force anyone to program in any style unless I hire them to
work for me and we agree that a certain programming style is part
of the contract.
I'm not telling anyone here how to program. I simply codified my own
personal programming style. I could have written "I don't use
if, when and unless for secret reasons that I'll never reveal"
and maybe that would have reduced the contraversy. Frankly
I thought that people could handle reading opinions different
than their own.
As for whether if* should be part of a future standard, I probably
wouldn't push for it given the current state. It's not like there are
every likely to be competing incompatible if* macros out there.
Even if if* were to be part of the standard I would fight any
effort to remove if, when and unless. Lisp has always been
about the inclusion of different personal styles, not the exclusion.
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214336087889777@naggum.net>
* John Foderaro
| I could have written "I don't use if, when and unless for secret reasons
| that I'll never reveal" and maybe that would have reduced the
| contraversy.
The controversy would indeed have been significantly less, because it
would only make you look pretty stupid and would not insult anyone who
actually like and want to use if, when, and unless.
| Frankly I thought that people could handle reading opinions different
| than their own.
Good. Keep on thinking that. However, when your "opinion" is about
other people and it is factually and definitely _wrong_, expect to be
criticized for it. If you cannot deal with criticism, guess who cannot
handle opinions different from their own. Guess what people think when
you have to invoke "religion" to attack people whose opinions you cannot
handle. Do you think anyone actually _fails_ to understand who is the
real culprit of all of your accusations? Get a better grip on yourself.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
Jochen Schmidt wrote:
> Now you can claim that it was the whole point of IF* was to replace the
> other constructs and without that it would not much sense - if that is
> true then the answer if IF* (seen at a whole) is _not_ morally tolerable
> because it would include discriminating others style of programming.
Sorry this paragraph got terribly wrong - I want to rephrase it.
Now you can claim that it was the whole point of IF* to replace the other
constructs and without that it would not make much sense to use it. If that
is true, then the answer if IF* (seen at a whole is _not_ morally tolerable
is simply answered, because it would include discriminating others style of
programming.
ciao,
Jochen
--
http://www.dataheaven.de
John Foderaro <···@xspammerx.franz.com> writes:
> The if* macro is much older than Common Lisp. I've used it a long
> time and since I have to read code that uses it and code that
> doesn't use it I'm continually made aware that it solves the problem
> it was intended to solve. Thus I'd like to continue to use it.
Common Lisp is not the language you are programming in, then.
> However suppose you were given the power today to tell me that I can no
> longer use if*. Would you tell me that?
I read a wonderful piece of text yesterday. This reminds me of it.
http://www.mit.edu/people/dpolicar/writing/prose/text/godTaoist.html
You can't force anything on other peopre here, on USENET. And why
would you want that?
> .. and unrelated to that here's an editorial opinion (not directed
> specifically at any one person):
> ...
> Is it the case that the ANSI spec laid down the laws as to what's a
> legal and non-legal Common Lisp program but now some people are
> saying that legal Common Lisp programs are divided between moral and
> immoral programs?
Yes. See section 1.5.2 of The Standard. Unless your programs include
the definition of if* macro they are non-conforming.
I won't comment on morality.
> The decision as to what's moral is made by self appointed people who
> read the scriptures (ANSI spec) and come to their own interpretation
> and feel they can speak for the members of the congregation (er.. I
> mean common lisp community).
You are not talking about anyone specifically, do you?
> Or just maybe we should once again step back from the brink of
> registering Common Lisp as a religion.
You keep dragging this in. Why?
> It's a programming language folks!! It's a tool to get a job done.
> Use it any way you want and don't let anyone tell you differently.
What kind of political propoganda is this? Do you think we're a bunch
of brainless folks here waiting for someone to tell us what to do?
As long as argumentation goes -- Erik out-argumnts you hands down. I
don't take any sides here. I like seeing the brain-at-work in his
posts. Will we see a _real_ reply with quotes of the poster you reply
to any time soon? Or will they be this "nothing personal in here, just
my opinion; I have the rights to express my opinion, right?" stuff you
picked up recently?
I actually liked your posts before this "I'll help you get rid of
Erik" duty you have taken on yourself. I have learned a lot of things
from your open-source software as well. Thank you for that.
> If you do something interesting share it with the group. They may
> not pick up on it but at least you tried. Chance are a few people
> will find it interesting.
Ok, you tried. You failed with some people, prevailed with other. Will
it stop now?
> A lot has occurred in the software world since Common Lisp was
> designed. Lisp can and must absorb new ideas from other languages
> to maintain its leadership position (even if these new ideas end up
> being control flow macros that duplicate existing common lisp ones).
I think Common Lisp does not have to "absorb" something. It has to
pick the best out of it and incorporate it in a way consistent with
the language.
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
In article <··············@asaka.latnet.lv>, ·····@latnet.lv says...
>
> Common Lisp is not the language you are programming in, then.
>
Partially correct. As has been mentioned here a few times if* is just
the If macro from Franz Lisp which preceded Common Lisp.
However it's *not* correct to say that that I'm programming
in Common Lisp now (and for the last many years).
> You can't force anything on other peopre here, on USENET. And why
> would you want that?
You miss the point of the question. I was trying to see whether
Kent believed more in personal freedom or what he personally believes
to be the will of the people.
> Yes. See section 1.5.2 of The Standard. Unless your programs include
> the definition of if* macro they are non-conforming.
>
What are you talking about???
> > Or just maybe we should once again step back from the brink of
> > registering Common Lisp as a religion.
>
> You keep dragging this in. Why?
>
Because it's appropriate.
>
> What kind of political propoganda is this? Do you think we're a bunch
> of brainless folks here waiting for someone to tell us what to do?
>
I'm expousing a different view that that "some macros are immoral view"
That's the point of this newsgroup, to post views.
> > If you do something interesting share it with the group. They may
> > not pick up on it but at least you tried. Chance are a few people
> > will find it interesting.
> Ok, you tried. You failed with some people, prevailed with other. Will
> it stop now?
I'm not the one whose been continually bringing up this if* thing
for the last two months. So I can't make it stop.
John Foderaro <···@xspammerx.franz.com> writes:
> In article <··············@asaka.latnet.lv>, ·····@latnet.lv says...
> > Yes. See section 1.5.2 of The Standard. Unless your programs include
> > the definition of if* macro they are non-conforming.
> >
>
> What are you talking about???
That you are completely free to define an IF* macro or any other macro
in your code as you like but that publishing major pieces of source
code that use IF* without defining it or refering to a definition
gives users of the particular implementation you help to maintain the
impression that it is standard. This does fracture the CL community.
We went over all of this the previous time. You didn't acknowledge any
arguments or points except your own last time and you probably won't
this time so I'll drop this mess now.
--
Lieven Marchand <···@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
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214335588766680@naggum.net>
* John Foderaro
| However suppose you were given the power today to tell me that I can no
| longer use if*. Would you tell me that?
For external, published code, in order to keep the community stability,
all of us rid our code and even our prose, of personal idiosyncrasies.
Publishing houses and their copy editors exist primiarily to get rid of
the "personal dialects" of its staff of authors, and series editors of
technical books make sure that all authors agree on the terminology. We
have a large number of other examples of how people have to extinguish
their pet peeves in order for the community to work better. To reject
_all_ of the consensus-forming procedures in a community is hostile to
every single memer of that community, because every one of us has already
made, and will continue to make, sacrifices in order to further the goal
of a coherent community. It has been obvious for a very long time that
you have no such goal, and would rather sacrifice the community coherence
to your ability to "use" (read "publish"; nobody cares about unpublished
code) your macro. Other people have used other forms predating Common
Lisp, too, but they do in fact not publish hostile documents that tell
people _not_ to use the standard.
| I know of one militant Common Lisp fundamentalist who's been terrorizing
| non believers here for years who would love to be able to force his will
| on others in the name of the community.
You are quite alone in this psychotic delusion which only further your
own insane rage. You have created a deamon that keeps haunting you, but
it is not real. _Nobody_ wants what you think they want. You are the
kind of person who believes in dictating what is _right_, and that is
actually quite amazingly stupid of you. Most other thinking people know
that anyone who has even looked the philosophy of law in western cultures
would argue for dictating what is _wrong_, given solid grounds and good
evidence. That you cannot distinguish one from the other only paints you
as rather stupid and ignorant and arrogant. Which is why you get most of
the reactions you get here.
| You can say "Thou shalt not write control flow macros that duplicate
| what's in Common Lisp" and claim that if* is immoral and at the same time
| say that when and unless are perfectly find macros and in fact divinely
| inspired.
Can you _please_ get it into your stale mind that nobody argues what you
keep saying they do? Last time we had this annoying round, you kept
making a large number of completely bogus claims about what other people
had said, and you simply cannot quit living in your psychotic delusion of
a make-believe world.
What is being said is actually this: "Please quit denouncing the standard
and people who happen to like it and want it simply because you think you
are the singularly most brilliant genius on the face of this planet past,
present and future who came up with the if* macro."
The fact that your macro is not being adopted _should_ have told you
something. The fact that lots of people denounce it, quite independently
despite your paranoid delusions that there is a conspiracy against you,
does not register with you. You do not get your will, and therefore you
fight people with _amazingly_ dirty tactics. This does _not_ win you
friends, nor does it influence people to adopt if* -- which has become a
symbol of irrational, arrogant stubbornness _only_ because of your lack
of ability to back down and consider other people's opinions. One _has_
to wonder what kind of personality problem has caused this, when you make
a very strong point of arguing that people should voice their objections
when they do not like what is posted to this newsgroup -- obviously, if
anyone happens not to "agree" with you in their objections, they must be
shot down -- by you. This lack of insight into your own behavior is not
rational. In fact, it is _so_ irrational that any hope of you _ever_
getting the picture and starting to figure out that you would benefit a
lot by not _publishing_ code with that annoyingly stupid if* sunt is nil.
| Or just maybe we should once again step back from the brink of
| registering Common Lisp as a religion.
The _only_ religion here is called "if*". People object to your stupid
accusations of a religion in ways that cause your bigoted mind to think
they are guilty _because_ they object. That people object to some insane
accusation does not make the accuser any more right, but an insane
accuser will not notice this, because he has already made up his mind.
| It's a programming language folks!! It's a tool to get a job done.
Then why the hell do you have such a problem writing standard Common Lisp?
Your _entire_ chain or agumentation falls flat on its face when you make
this argument.
| Lisp can and must absorb new ideas from other languages to maintain its
| leadership position (even if these new ideas end up being control flow
| macros that duplicate existing common lisp ones). Also no person on this
| newsgroup speaks for the community. Don't be bullied into believing
| otherwise.
Geez, did those objections to you believing you are the censor of this
newsgroup not even _register_ with you? _You_ are the bully here, John
Foderaro, trying to make people _not_ use the standard, trying to force
people to shut up. Go away and create comp.lang.lisp.foderaro, where you
_are_ the supreme genius and censor and everything else you seem to be
really pissed that you are in fact _not_ in this newsgroup.
The moment you understand that you are a worse bully than anyone else
here and far more destructive to the community than anyone else, there
might a chance you achieve enlightenment. The world will know that this
has happened when you publish code without the stupid if* conditional.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214331000184216@naggum.net>
* Kent M Pitman <······@world.std.com>
| We made CL in the believe that being standard was more powerful than
| being uniquely right.
I believe the best notion of what is right will emerge by itself if you
keep the definitely wrong away. Evolution works this way: Contrary to
popular belief and the statement "survival of the fittest", a much more
accurate description is "early death of the unfit". Among all the weird
ideas people get, weed out the bad ones early, and whatever is not bad
enough to stand out as monumentally stupid at the time may have enough
merit to make a difference somewhere down the line. Believing in the
survival of "right" leads to _really_ bad social experiments.
| So we nailed it down. We're supposed to have moved beyond those things
| to new areas to bicker about.
But this requires people who are cognizant of the necessarily political
nature of _every_ community consensus-forming process and who are not
irrationally allergic to forming networks of agreement with other people
despite the lack of a "uniquely right" way. People _cannot_ agree on
what is right -- that would starve a community of every opportunity to
evolve. They _can_, however, agree on what is _wrong_, and if they can
limit that to that which is _definitely_ wrong, the more room there is
for things right. However, it does require that people in the community
are able to listen when their suggestions fall in the "definitely wrong"
category. So far, nothing suggests that the if* stunt, _including_ its
abject rejection and attempt at full replacement of _all_ the standard
conditionals in the language, if, when, unless, case, typecase, etc, is
going to avoid falling in the "definitely wrong" category, mostly because
it does nothing but add some redundant noise to cond and is no _actual_
replacement for or _definite_ improvement over anything. It is simply an
irrational stylistic issue (the part about rejecting everything else),
and a historical accident perpetuated for irrational reasons. "Move on"
is precisely what we should do, but, unfortunatley, it require that the
perpetrator of this silliness respects when the community rejects him.
So far, that that is _not_ going to happen is the only thing we know
about the current situation.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214291134727903@naggum.net>
* Kent M Pitman -> Marc Spitzer
| In what way would this be any different a question if asked about
| functions and not macros?
If a Common Lisp programmer insists on using C's standard library names
for his string functions instead of the standard Common Lisp ones _and_
argues that those who use the standard functions are nuts, I think there
would probably be the same kind of uniform rejection of this stupidity as
what appears to be building towards the limited IF* crowd, not primarily
because of the specific idiotic new "feature" that nobody needs or wants,
but because of the sheer irrationality of the whole endeavor and because
of the incredible _arrogance_ exuded by those who thus reject the whole
community they _pretend_ or may even helplessly _want_ to be members of,
but are in fact rejecting completely. It is that initial rejection of
the community, the pretentious arrogance of one who thinks he knows so
much better than everybody else, and the holier-than-thou attitude when
criticized that comes from both of the former attitude problems, that
_really_ ticks people off. It is no longer about some stupid invention
of a macro or a function or a new sub-language, it is about the lack of
willingness to yield in traffic as opposed to a willingness to run into
people on purpose because one thinks one is a superior to others -- it is
the _exact_ same process that makes people become criminals.
It is actually a good thing to have lots of people argue vociferiously
for and defend a community standard because it shows that the community
comes before the person, but it is a really _bad_ thing to have someone
argue vociferiously _against_ community standards, especially when the
only reason for doing so is that those very few who argue against it
subjugate community interests to their own ego, even more so when it has
become badly bruised in a battle over its anti-community tactics.
At issue is not the specific new "features", whether they be macros,
functions, or anything else, it is simply a rejection of someone who has
decided to be an outlaw and force his own way regardless of consequences
instead of trying to work within the law to make people agree with him
how to make a better world -- probably because he realizes that it would
in fact not _be_ a better world if he did not rule everything in it.
I have long had an interest in law and the philosophy of law, but with it
comes an interest in why people choose to abide by or violate a law, or
even ethics. Everybody has their own ethical standards which come into
conflict with the law or at least other people's ethics at various points
in their lives. The really _big_ question is whether you are the kind of
person who realizes that the only thing the law and ethics _really_ say
is what is _wrong_ or you are the the kind of person who (mistakenly)
believes that law and ethics tell people what is _right_. The latter go
on to be quite the intolerable moralists who want people to follow a
specific path (i.e., whatever path they have chosen, and the two usually
become conflated) or else they are doomed sinners upon which all evil can
be hurled in a "defensive" action. The former find it interesting how
people choose among a very large number of ways to go about their lives,
but may also be intolerant of those who, by breaking law and ethics and
taking both in their own hands, make it harder or impossible for others
also to choose their own ways. It is threfore quite illuminating how our
perpetrator continues to argue that he is within the law and community
ethics when he does something he can have no doubts at all the community
has resoundingly _rejected_. The lack of willingness to stop doing,
indeed, the insistence on _continuing_ what the community has disapproved
of is precisely what defines the criminal mind.
Law and ethics are wisely set up by lots of smart people working very
slowly to ensure that proper procedure is followed, resulting in both
being _vastly_ smarter than the average joe, in order to ensure that
_very_ different people can live together under the same rules without
needing special privileges for particular groups, which was the general
situation before these intricate procedures were followed. "Equality
before the law" is definitely not in the _personal_ interest of most
people, who would rather get a break than be held responsible for their
actions. (Punishment also does not work on those who do not understand
what happened to them, only the threat of punishment does, although it
can take an initial actual punishment for some people to "get it", but
without real punishment, there is no threat, so this is a very hard
problem to resolve.)
What defines a community is in part its process of agreeing on its laws
and ethics and other standards. We have a language standard that should
have united us. Because of some lunatics who value being rebels higher
than a working community, this is not quite so, and we still have to
fight battles over what the community standards-setting procedures are.
In essence, it will be fought over whether some nutcase can publish a
"Coding Standard" document where he ridicules and undermines the standard
that the community has in fact agreed upon and which thus rejects the
community _and_ get away with it through stubbornness and sheer tenacity,
or whether the community rejects this nutcase and moves on, despite the
everpresent lack of _total_ agreement with any community standard.
Some people will always disagree with some part of what has been agreed
upon for a large population, and there are many reasons for this, but the
real question is not what people disagree with, not with what they do
when they disagree, not with how they plan to "convert" people to their
ways, but with whether they wish to maintain a respect for that community
standard or seek to destroy that respect and thus obliterate what holds
the community together.
This is not about some language feature or another, which, typically and
predictably, the perpetrator will continue to whine that it is. This is
about how we wish to hold a community together. There is no doubt that
this insipid if* macro stunt is fragmenting the community like nothing
else, despite the perpetrator's propagandistic lies about loop, which is
the object of another of his destructive machinations. The _only_ issue
is whether the perpetrator can manage to stop fragmenting the community
when he realizes that that is precisely what it does. So far, all we
have seen is an _increasing_ arrogance and even more stubbornness in his
fight against the community. Clearly, this nutcase/perpetrator values
his protest _much_ higher than that which he knows that he is destroying
in the process. That kind of destructive attitude cannot be tolerated.
If the nutcase/perpetrator had been willing to back down early, this
would never have gotten to be such an issue. It has become an issue only
because he does _not_ back down. Now he cannot back down because he
would lose his personal prestige doing so, wrecking his "standing" among
whoever still supports him. This is pretty pathetic, but that is how
things evolve when you are _wrong_ and are prevented from realizing it in
time for personal and highly irrational reasons. We must expect the
perpetrator to protest his innocence too much and continue to pester the
Common Lisp community with his bogus claims about the standard and how
the language and the community should welcome his stupid stunt.
Finally, if* has already become a symbol for the clueless rebels, but the
likelihood that whoever initially thinks that stupid macro is a good idea
will stick to it as they see what they are buying into by using this
symbol of anti-standard, anti-community, childish rebellion against
authority, will also decrease, hopefully further isolating the rebels.
I have used an Emacs Lisp function to transform if* into an if, cond,
when, or unless form as deemed appropriate through some simple measures,
but it needs tweaking to make it work better. It reverts the form to the
bogus if* form when saving the file, unless it has been modified so as
not to affect patches and other updates to the code from people who have
yet to rid the code of the bogosity. It should probably also realize
when the if* nonsense is really trying to macroexpand a case, typecase or
any of the other numerous much better ways of expressing things than an
overly verbose and poorly formatted list of elseifs.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
What you may mistake for arrogance is my policy (which I've stated before)
of not responding to messages flaming me. Someone who flames is just
trying to boost their own ego and isn't really interested in a serious
discussion. The fact it that most of your messages directed at me
(such as this last one) contain numerous personal insults (and don't start
with the line about "I only insult people's behavior not the people
themselves". No one has ever bought that argument).
I will break my rule and answer your last letter. You'll then respond with
posts full of insults for the next few months which I'll happily ignore.
ok.. let's see if we can find the key points of your letter:
>> because of the specific idiotic new "feature" that nobody needs or wants,
>> but because of the sheer irrationality of the whole endeavor and because
>> of the incredible _arrogance_ exuded by those who thus reject the whole
>> community they _pretend_ or may even helplessly _want_ to be members of,
>> but are in fact rejecting completely.
You shouldn't use absolutes like this. People know that you're wrong and
when you start out being wrong so early they aren't going to trust
the rest of what you say. "nobody needs or wants" is clearly wrong.
I need and want it. There are others here that need and want it.
And I've heard from people via email that need and want it.
"..but are in fact rejecting completely." -- I can't see that I'm
rejecting *anything* let alone rejecting *everything.* If I rejected
everything then I would be off programming in some other language.
>> _really_ ticks people off. It is no longer about some stupid invention
>> of a macro or a function or a new sub-language, it is about the lack of
>> willingness to yield in traffic as opposed to a willingness to run into
>> people on purpose because one thinks one is a superior to others -- it is
>> the _exact_ same process that makes people become criminals.
I really love this one. Writing a perfectly legal Common Lisp macro
and continuing to using it despite your vocal dislike of it is like
running into people on the streets.
>> Some people will always disagree with some part of what has been agreed
>> upon for a large population,
Macros are part of Common Lisp. The large population agreed that they
should be part of the language. Using macros is not wrong. Using
macros that a few people on comp.lang.lisp dislike is not wrong.
>> in their lives. The really _big_ question is whether you are the kind of
>> person who realizes that the only thing the law and ethics _really_ say
>> is what is _wrong_ or you are the the kind of person who (mistakenly)
>> believes that law and ethics tell people what is _right_. The latter go
>> on to be quite the intolerable moralists who want people to follow a
>> specific path (I.e., whatever path they have chosen, and the two usually
>> become conflated) or else they are doomed sinners upon which all evil can
>> be hurled in a "defensive" action.
What I enjoy about when I read your messages is that you always put up
some strawman to attack and more often than not the behavior of the
strawman is precisely your own. In this case you're the one who
believes that the Common Lisp spec says tell us precisely what
is right (if, when, unless) and that anything else you write that's
similar to if, when and unless must therefore be wrong. You're the one who
is the intolerable moralist about this whole thing.
>> about how we wish to hold a community together. There is no doubt that
>> this insipid if* macro stunt is fragmenting the community like nothing
>> else, despite the perpetrator's propagandistic lies about loop, which is
>> the object of another of his destructive machinations.
I don't think that if* has fragmented the community one bit.
Does anyone out there feel that there is any fragmentation due
to if*???
>> If the nutcase/perpetrator had been willing to back down early, this
>> would never have gotten to be such an issue.
I did a google groups search and the last message I can find from me
on the if* topic was Sept 5th, over two months ago. In that time
you've posted nearly every day some reference either direct or
indirect to if*. Who is the nutcase here? Why are you
so obsessed with this macro? I've written plenty of other macros
which, if you read my code, you'll have to deal with. Why not get
obsessed about one of them and give if* a break?
I don't know what your problem is. It certainly isn't about
some insignificant macro that most people couldn't care less about.
I suggest you look in the mirror. You are one person. You are
*not* the Common Lisp community. Everyone's opinion is important
but no one can speak for us all. Keep that in mind.
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214336766919081@naggum.net>
* John Foderaro
| What you may mistake for arrogance is my policy (which I've stated
| before) of not responding to messages flaming me.
Now, now. It is nothing personal, John.
I shall consequently strive not to respond to people who defend
_themselves_ rather than whatever they are criticized for.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
John Foderaro <···@xspammerx.franz.com> writes:
John Foderaro <···@xspammerx.franz.com> writes:
> In article <··············@asaka.latnet.lv>, ·····@latnet.lv says...
> >
> > Common Lisp is not the language you are programming in, then.
> >
>
> Partially correct. As has been mentioned here a few times if* is just
> the If macro from Franz Lisp which preceded Common Lisp.
> However it's *not* correct to say that that I'm programming
> in Common Lisp now (and for the last many years).
>
> > You can't force anything on other peopre here, on USENET. And why
> > would you want that?
>
> You miss the point of the question. I was trying to see whether
> Kent believed more in personal freedom or what he personally believes
> to be the will of the people.
Personal freedom is accompanied by personal responsibility. You have
the right to use macros and functions of your own devising. You have,
I think, the responsibility to include their definitions in a
distribution that uses them and that purports to be runnable in
conforming CL. Of course, you can write conforming code that isn't
runnable. For example (foo x) is conforming, but without a definition
of FOO it's not worth much. If you make a claim that a module
implements a certain functionality, but it leaves out definitions of
operations necessary to make the module go, it seems to me that either
the claim that the module implements the functionality is false or
else you need to explicitly document what other modules are
prerequisites to running your system. And in that sense, you are not
running just on CL but on some layered system defined by
CL+the-other-modules. e.g., you can write MACSYMA or CLIM
in CL and a program that uses that system, and that's fine. But saying
that (clim:accept 'integer :prompt "Type a number:") is the CL way
to do program input or (MACSYMA:$INTEGRATE '((MACSYMA:$SIN) $X) '$X) is the
"CL way" to integrate sin(x) is a bit of a stretch.
> > Yes. See section 1.5.2 of The Standard. Unless your programs include
> > the definition of if* macro they are non-conforming.
> >
>
> What are you talking about???
I believe the point is that people shouldn't have to separately
download if*. If it's just a personal macro, its definition will
appear in any distribution that uses it, just like any other
user-defined function that makes said distribution work. The entire
fuss over "where do we get that definition" was artificial because one
doesn't ask that about any other user-defined variable, function, or
macro--the answer is: loading the user module defines it. If the user
module doesn't define it, then the language/environment is expected
to. The CL language doesn't, so if you're depending on it, it's not
CL you're depending on.
> > Ok, you tried. You failed with some people, prevailed with other. Will
> > it stop now?
>
> I'm not the one whose been continually bringing up this if* thing
> for the last two months. So I can't make it stop.
I'd be willing to take your side and lobby for the rhetoric to stop if
I were assured that if* were just a normal definition as part of any
facility (such as AllegroServe) you export that purports to run
outside of Franz life support, or if, failing such an added
definition, you tell me that you put #+Allegro in front of each its
uses to make it clear that it's system-dependent just as you would (or
should) with any other non-portable aspect of such a system.
You might have already done this; I'm not asserting you haven't.
I'm just assuming that the rhetoric can be triggered by actions, and some
rhetoric is legit and some is not. Tell me that the rhetoric is not
legit by asserting you've met these or some other definable criteria
that establish an equivalent sense of "predictable platform" and I'll
help you lobby for more calm.
The normal way to do what you did, btw, is to make a new package.
In my software at HyperMeta, Inc., I don't like a few operators
(DEFPACKAGE and ASSOC) so I changed them (mostly upward-compatibly, but
in the case of DEFPACKAGE, technically there is a possibility of
obscure clashes). I just made another package called COM.HYPERMETA.CL
that has my versions of these. No one will use it by accident; anyone
using my software can feel free to import either CL's versions or
mine. I don't expect to get heat from this approach because I'm not
fighting other people's uses. I just made my own space to play in
non-invasively. People who don't want the extra DEFPACKAGE options I
offer, or who don't want to use SETF of ASSOC, can just ignore my
extensions.
Also, I *do* regard my changed package as a new language. I don't know why
you don't think of CL+IF* as a new language. Maybe you're worried it will
lose you the support of CL users, and as an empirical thing, it may. But
if so that isn't because of your being a new language, it's because you
made a bad choice that people don't want to flock toward. Like you,
I expect people to flock toward my changes, but if they don't, I'm not
going to hide behind "it's just CL". I'll say it's because they didn't
like the trivially different language I made.
Incidentally, I have another language, COM.HYPERMETA.LISP which is
much less trivially different -- that is, contains a lot of other junk
/ goodies (depending on yourpoint of view). I just went in two stages,
first changing CL non-invasively, then adding other stuff as
extensions to that, in case people cared to only go one of the two
steps. Or there are ways they can pick and choose from only the parts
of COM.HYPERMETA.LISP they like... but it's easier with my DEFPACKAGE. ;-)
I also didn't try to pick bad names. I personally don't like IF* because
it looks bad. But if you called it EXT:IF, I'd be fine with it because
I could either import it or not. If I did, I'd be programming in your
language. If I didn't, I'd be programming in mine. That feels cleaner
to me. If I'd wanted co-resident operators, CL:IF and your:if-surrogate,
I'd have named the operator something prettier. UPON or WHENEVER or
BECAUSE or DO-IF, or something whose name didn't confusingly seem like
it was a friend of LIST* or LET*, two name conventions that already clash
and don't need yet a third source of competition. Or else I'd have done
what COM.HYPERMETA.CL:DEFPACKAGE does, and I'd just be "mostly compatible"
and say that I distinguish based on whether a
macro-whose-name-was-formerly-IF* keyword was present, doing its actions
only if they were, and doing CL:IF's actions otherwise. Yes, not totally
compatible, and no, not "CL", but still "defensible" as long as you're
willing to admit you've carved out your own langauge (which isn't a sin
but one of many the purposes of CL to enable)...
>> the right to use macros and functions of your own devising. You have,
>> I think, the responsibility to include their definitions in a
>> distribution that uses them and that purports to be runnable in
>> conforming CL.
Have I ever made a claim that any of the code that I've distributed
can be run in any conforming CL? If I did then it was a mistake.
The code that I find interesting enough to distribute generally
has dependencies on multithreading, sockets and acl-dependent streams.
In fact I can only promise that it runs on certain recent versions of
ACL.
Why should I even distribute it? Well, the people using ACL can use it
off the shelf and those that use other Lisp may be able to port it or at least
may be curious how something was done.
The cost to me to ensure that it works in all the various conforming CL's
out there would probably mean that I'd just not distribute anything.
>> I believe the point is that people shouldn't have to separately
>> download if*. If it's just a personal macro, its definition will
>> appear in any distribution that uses it, just like any other
>> user-defined function that makes said distribution work.
The best solution here is a Compatibility Library. If users of
CL A want to load code written for CL B with minimal changes,
then the CL A users have to write and maintain a library B->A.
That's something the community here can help get going. This library
would be a lot bigger than just the if* macro.
If I merely added the definition of if* to all my source files it would
add nearly nothing to making the code easier to run on other Common Lisps.
>> I'd be willing to take your side and lobby for the rhetoric to stop if
>> I were assured that if* were just a normal definition as part of any
>> facility (such as AllegroServe) you export that purports to run
>> outside of Franz life support, or if, failing such an added
>> definition, you tell me that you put #+Allegro in front of each its
>> uses to make it clear that it's system-dependent just as you would (or
>> should) with any other non-portable aspect of such a system.
Now that I've made it clear that the code I offer does not purport
to run on any Common Lisp other than recent versions of ACL, can
I eliminate that need to mark the acl-specific parts of it?
I know that this sounds like I'm lazy or selfish but remember back
to what Erik said about not distributing code any more because he finds
the people receiving it are ungrateful and just complain.
I've got three choices (and yes technically it's Franz's choice but
in the case of code I've written I think they would go along with
what I wanted).
1. I could not opensource the code
2. I could opensource what I've written which is ACL only
3. I could make it work on all lisps and open source that.
well 3 is out, since I don't have the time, knowledge or energy to
coordinate such an effort, and it may not be the best thing for
the code.
So I could either do 1 or 2. If people are offended that I chose 2
I can always do 1. That's very easy to do. Would that benefit
the community more?
>>
>> Also, I *do* regard my changed package as a new language. I don't know why
>> you don't think of CL+IF* as a new language.
It can or cannot be considered a new language based on what you intend
to infer from 'new language'.
If by 'new language' you mean that due to the addition of if* existing
Common Lisp books are invalid, this is not true at all.
if* is actually excl:if*. If you work in a package that doesn't
use the excl package then it is as if the if* macro didn't exist.
So by my definition of 'new language' you can add a million functions
and macros to a Common Lisp system and not change the language
a single bit as long as the user still has the capability of
sees the ansi defined common-lisp package.
In the case where you're shadowing ANSI defined functions then you
are indeed defining a new language.
>> I also didn't try to pick bad names. I personally don't like IF* because
>> it looks bad.
I would have preferred to use If as in Franz Lisp but you know quite
well why that's not a practical choice.
if*'s a better name than shadowing 'if' since emacs doesn't have to
be very clever to distinguish 'if' from 'if*' and indent each correctly.
Also you can give someone some code and the if* macro and they can run it.
They don't have to go through shadowing 'if' in a package to use it.
If I were to publish code using a shadowed 'if' that had the 'if*'
keywords it would totally baffle the newbies and even old timers
would dislike it.
In my programming style if* is the single most important conditional
expression, so I want it to have a terse name. If people used
multiple-value-bind a lot it wouldn't be called multiple-value-bind,
just like car is car and not contents-of-address-register.
"John Foderaro" <···@xspammerx.franz.com> wrote in message
·······························@news.dnai.com...
> >> the right to use macros and functions of your own devising. You have,
> >> I think, the responsibility to include their definitions in a
> >> distribution that uses them and that purports to be runnable in
> >> conforming CL.
>
> Have I ever made a claim that any of the code that I've distributed
> can be run in any conforming CL? If I did then it was a mistake.
> The code that I find interesting enough to distribute generally
> has dependencies on multithreading, sockets and acl-dependent streams.
> In fact I can only promise that it runs on certain recent versions of
> ACL.
>
Don't you think there is a big difference between a pervasive control flow
construct and functionality that is not included in the standard at all?
> Why should I even distribute it? Well, the people using ACL can use it
> off the shelf and those that use other Lisp may be able to port it or at
least
> may be curious how something was done.
>
> The cost to me to ensure that it works in all the various conforming CL's
> out there would probably mean that I'd just not distribute anything.
>
True, but the cost of making it an order of magnitude easier is small.
> >> I believe the point is that people shouldn't have to separately
> >> download if*. If it's just a personal macro, its definition will
> >> appear in any distribution that uses it, just like any other
> >> user-defined function that makes said distribution work.
>
> The best solution here is a Compatibility Library. If users of
> CL A want to load code written for CL B with minimal changes,
> then the CL A users have to write and maintain a library B->A.
> That's something the community here can help get going. This library
> would be a lot bigger than just the if* macro.
>
This indicates more than anything else you have written that you *prefer* to
create incompatible branches in the Common Lisp tree. It may be very hard to
avoid for some areas not forseen when the ANSI work was done, but it is
something one should at least *try* to avoid. I truly belive that Franz has a
business plan similar to MS - gain marketshare --> dominate --> ignore
community standards to damage competitors --> monopolize. This is not the only
way to be successful in business.
I think it is very disengenuous of you to use arguments based on things like
multi-processing and sockets which unfortunately are *not* defined in the
standard in a discussion of a simple control-flow macro. Nuts and bolts stuff
is usually where incompatabilities lie and are usually easy to confine. When
you use something non-standard of your own devising to the exclusion of all of
the other control flow constructs this seems to me very different.
Again you have every right to write and use something like if* and the religion
argument you keep setting up and knocking down is not what most people (any
people, really) have been raising. Surely you realize most of the fuss was
over the attitude that came with it. It is obvious that if* is _not_ just a
utility to you, it has history and political baggage that, while I don't know
the details, the existence of is very evident. I use personal little utilities
all the time, they are kept in a utilities file and go everywhere with the rest
of the source. Why is that so difficult?
> If I merely added the definition of if* to all my source files it would
> add nearly nothing to making the code easier to run on other Common Lisps.
>
That doesn't seem to be a common position. And it would sure do alot to
satisfy peoples concerns.
> >> I'd be willing to take your side and lobby for the rhetoric to stop if
> >> I were assured that if* were just a normal definition as part of any
> >> facility (such as AllegroServe) you export that purports to run
> >> outside of Franz life support, or if, failing such an added
> >> definition, you tell me that you put #+Allegro in front of each its
> >> uses to make it clear that it's system-dependent just as you would (or
> >> should) with any other non-portable aspect of such a system.
>
> Now that I've made it clear that the code I offer does not purport
> to run on any Common Lisp other than recent versions of ACL, can
> I eliminate that need to mark the acl-specific parts of it?
>
> I know that this sounds like I'm lazy or selfish but remember back
> to what Erik said about not distributing code any more because he finds
> the people receiving it are ungrateful and just complain.
>
Most of the attacks you have endured were prompted by the insult you delivered
with your gift. (ie your coding standards v. 1.0(a) document). It is
understandable people took exception to that. Especially as it was hosted by
one of the major vendors.
> I've got three choices (and yes technically it's Franz's choice but
> in the case of code I've written I think they would go along with
> what I wanted).
> 1. I could not opensource the code
> 2. I could opensource what I've written which is ACL only
> 3. I could make it work on all lisps and open source that.
>
> well 3 is out, since I don't have the time, knowledge or energy to
> coordinate such an effort, and it may not be the best thing for
> the code.
>
> So I could either do 1 or 2. If people are offended that I chose 2
> I can always do 1. That's very easy to do. Would that benefit
> the community more?
What about 2(a). Do 2 and include the code for if* and any other logically
significant macros and functions you use?
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
>> Don't you think there is a big difference between a pervasive control flow
>> construct and functionality that is not included in the standard at all?
>>
In the case under question the difference is obvious: the control
flow construct is no impediment to porting the code, the
non-common lisp functionality may make porting extremely difficult.
Are you implying by your question that if I came up with a new
control flow construct that require special runtime system support
(and thus only worked on ACL) that you wouldn't mind if I use
that pervuasively throughout my code? In other words you're willing
to allow me to use any amount of non-common-lisp code but are unhappy
when the common lisp macro facility to write something that is
in fact totally portable??
>> True, but the cost of making it an order of magnitude easier is small.
ok, I'll ask Jochen Schmidt: If I had included the source to if*
with AllegroServe would it have made the port to LispWorks an order
of magnitude easier?
>> > The best solution here is a Compatibility Library. If users of
>> > CL A want to load code written for CL B with minimal changes,
>> > then the CL A users have to write and maintain a library B->A.
>> > That's something the community here can help get going. This library
>> > would be a lot bigger than just the if* macro.
>> This indicates more than anything else you have written that you *prefer* to
>> create incompatible branches in the Common Lisp tree.
Not at all. This is a practical response to the problem of there
being multiple lisps out there each of which has grown unique features.
We in fact wrote (and I think still distribute) a Lucid compatibility package
for those who want to port from Lucid Lisp to our lisp, as just one example.
This is simple software engineering based on the reality that exists today.
Franz may write a Lispworks to Allegro compatibility package and
the Lispworks folks may write an Allegro to Lispworks compatibility package.
Creating a compatibility package from X to Y does not imply any kind
of judgement of the relative values of X and Y.
>> That doesn't seem to be a common position. And it would sure do alot to
>> satisfy peoples concerns.
>>
To be honest I haven't seen concerned raised by many people.
And for some people I think they are arguing in principle rather than
any experience. I say that because a grep through AllegroServe
shows the following internal macros used that no one has
ever complained or asked about:
excl::atomically
excl::with-dynamic-extent-usb8-array
excl::fast
>>
>> What about 2(a). Do 2 and include the code for if* and any other logically
>> significant macros and functions you use?
>>
I already direct people to the if* macro in a few places.
The software engineer in me says the correct place to deal with
implementation incompatibilities is in a compatibility library.
I won't promote what I know to be bad design by putting if* in
the code for each of the packages I opensource.
If people have questions about constructs in the code I opensource
that don't exist or seem to work on their Lisp they should
send me email. I'll tell you what it does in ACL.
I'm not using ACL specific things to exclude other Lisps, I'm
simply writing the code in what I think is the best way for ACL>
John Foderaro wrote:
>>> Don't you think there is a big difference between a pervasive control
>>> flow construct and functionality that is not included in the standard at
>>> all?
>>>
>
> In the case under question the difference is obvious: the control
> flow construct is no impediment to porting the code, the
> non-common lisp functionality may make porting extremely difficult.
>
> Are you implying by your question that if I came up with a new
> control flow construct that require special runtime system support
> (and thus only worked on ACL) that you wouldn't mind if I use
> that pervuasively throughout my code? In other words you're willing
> to allow me to use any amount of non-common-lisp code but are unhappy
> when the common lisp macro facility to write something that is
> in fact totally portable??
>
>
>
>>> True, but the cost of making it an order of magnitude easier is small.
>
> ok, I'll ask Jochen Schmidt: If I had included the source to if*
> with AllegroServe would it have made the port to LispWorks an order
> of magnitude easier?
Hehe - no certainly not a magnitude ;-)
I think Chris Double who had the first port of AllegroServe (on Corman
Lisp) working agrees too that IF* was no real problem for porting
AllegroServe and I think we should honor the work John did with
AllegroServe particularily that he made it public under a well suited
license. (Btw. the extended Reader conditionals of ACL was by far more
hassle while porting than IF*...)
I did and do not like IF* because of stylistic issues and
because I see no gain for _me_ but this does not mean that I would go so far
like claiming the creation and usage of IF* would be morally wrong to
anyone. The only thing I really do not like is forcing others not to use
facilities they like (this counts _for_ and _against_ John).
You said that you cannot really force anyone to use IF* but I wonder how you
would react if I would offer you some code for AllegroServe that would
contain IF, WHEN, UNLESS, COND or probably the extended LOOP? Would you
take it? Would you change it to IF* and simple LOOPs before adding? Would
you say me I had to rewrite it using only IF* and simple LOOP?
> We in fact wrote (and I think still distribute) a Lucid compatibility
> package for those who want to port from Lucid Lisp to our lisp, as just
> one example.
>
> This is simple software engineering based on the reality that exists
> today. Franz may write a Lispworks to Allegro compatibility package and
> the Lispworks folks may write an Allegro to Lispworks compatibility
> package.
It may be interesting to note here that Portable AllegroServe already
contains such a package (called ACL-COMPAT). It offers the ACL style
socket API, multiprocessing API and some other stuff (including IF*)
for at least LispWorks and CMUCL so far.
I do not claim that the package provides the complete ACL API but it is at
least enough to get AllegroServe (and some other packages) running.
> To be honest I haven't seen concerned raised by many people.
> And for some people I think they are arguing in principle rather than
> any experience. I say that because a grep through AllegroServe
> shows the following internal macros used that no one has
> ever complained or asked about:
> excl::atomically
> excl::with-dynamic-extent-usb8-array
> excl::fast
As I already said - most of this things were no real problem while porting.
The biggest problems were things like the bivalent socket support or
differences in multithreading APIs.
>>> What about 2(a). Do 2 and include the code for if* and any other
>>> logically significant macros and functions you use?
>>>
>
> I already direct people to the if* macro in a few places.
> The software engineer in me says the correct place to deal with
> implementation incompatibilities is in a compatibility library.
> I won't promote what I know to be bad design by putting if* in
> the code for each of the packages I opensource.
>
> If people have questions about constructs in the code I opensource
> that don't exist or seem to work on their Lisp they should
> send me email. I'll tell you what it does in ACL.
> I'm not using ACL specific things to exclude other Lisps, I'm
> simply writing the code in what I think is the best way for ACL>
Through my experience in porting AllegroServe I can agree with this.
It was not rocket science to make AllegroServe portable.
There are still some missing things like chunking support for CMUCL,
Unicode, Proxy-Cache and so on.
ciao,
Jochen
--
http://www.dataheaven.de
In article <············@rznews2.rrze.uni-erlangen.de>, ···@dataheaven.de says...
>> You said that you cannot really force anyone to use IF* but I wonder how you
>> would react if I would offer you some code for AllegroServe that would
>> contain IF, WHEN, UNLESS, COND or probably the extended LOOP?
Well it depends on how central the code is to the functioning of
AllegroServe. The main code has to follow the standard. What good
is it establishing a standard if you don't follow it?.
You may note that one of the example files (puzzle.cl), a very
cool aserve application written by another developer at Franz
(Charley Cox) actually uses when and unless. Some day I plan
on converting that over to use if* but I don't feel
an urgency to do so.
>> Would you take it?
>> Would you change it to IF* and simple LOOPs before adding?
If we assume that you're talking about core AllegroServe code
then I would see converting it over the the standard as a cost
to including the code. If I felt that the cost was low enough
and the benefits high enough then I would take it and convert
it myself. I may not even be able to read and understand
the extended loop code though.
>>Would
>> you say me I had to rewrite it using only IF* and simple LOOP?
If you give me a gift I don't complain about it and tell *you*
to do anything
for me. You may not see your code incorportated in the source I have
though very quickly or even in the same form if I see that I'm going
to have to do a lot of work on it to incorporate it.
And to turn things around, you have distributed code yourself
for various things. My response is simply "Thank You". I'm
never going to look at your code and tell you that you better
change it so that it's more readable to me or that it use only
standard Common Lisp forms. If you've invented some new interesting
macros, especially for control flow, I'll study them to see if
you've discovered something that I'd find useful myself. Even if
I don't like it (of even if I despise it) I won't tell you to
change it. It may be that due to your style I may not
be able to use the code as much as if it were written in a
style I like, but that's all on me. You take no blame for that.
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214775823510728@naggum.net>
* John Foderaro
| What good is it establishing a standard if you don't follow it?
Funny you should ask... But it clearly applies only to your own.
| You may note that one of the example files (puzzle.cl), a very cool
| aserve application written by another developer at Franz (Charley Cox)
| actually uses when and unless. Some day I plan on converting that over
| to use if* but I don't feel an urgency to do so.
Someone should convert the "ported" AllegroServes and other open source
from your end to use the standard conditionals, because what good _is_
having a community standard if one does not follow it? Publishing source
code for others to read is all about letting people who want to find good
programming style and quality design learn by example, after they have
found textbooks teaching or standards defining the language they are
reading -- that is not what they find in if*-infested code. If they have
to deal with some wacky old historical accident that transports them back
to pre-Common Lisp times with every programmer's own version of basic
language constructs, we have gained nothing with the standard, and that
is clearly the _purpose_ of the if* form. We were _supposed_ to have
progressed beyond random user macros for fundamental control structures
with the establishment of the standard, but some have still not accepted
it. I do not think they should be rewarded for their retro-rebellion and
nostalgic pining for a time when we _had_ no standards.
The Open Source community does not have to accept anyone's very personal
"coding standard", especially when it proves to be a _liability_ to the
community. Quite the contrary, the Open Source community should strive
to make its projects acceptable to as many people as possible, to be
inclusive of tastes -- which, contrary to the childish whining of those
who have no concern for anything but their _own_ taste, to mature people
means finding a point of _common_ agreement that offends as few people as
possible and thus allows people to make _serious_ improvements instead of
petty ones that only annoy lots of people. One such obvious common point
of agreement is the _standard_, within its scope; outside its scope, we
must strive to find other points of agreements, obviously, but still the
respect for such agreements must be established and maintained.
The Open Source community is already loaded with political issues that
tend to exclude people who could have contributed serious improvmenets,
so finding the intersection of those who accept the political issues and
those who accept the irrationality of refusing to deal with standard
conditionals and community-accepted coding practices, will of necessity
be quite hard. Furthermore, does any part of the Open Source community
_really_ want to marry into the anti-standard political agenda of someone
who expresses strong disdain for _many_ clauses and committee decisions,
disrespect for and hostility towards central committee members, and who
refers to the upper-case symbol names of the standard as "braindamaged
mode" as opposed to the "modern mode" of his own design? I certainly do
not want to help further such agendas, so if I find bugs or some features
I do not like, I just drop it or do not use it at all, just like some
Microsoft "operating system", rather than try to make it better, which
would simply mean making it better at hurting what I value. Sharing code
with people who have agendas that are contrary to mine would be self-
destructive -- I _really_ want ANSI Common Lisp to survive, and more than
that, to be _the_ point of agreement for the whole commnunity. I want to
work _within_ the accepted procedures to make changes or improvements if
any are necessary, not undermine the standard by changing the language
people see, indeed, to make sure that _textbooks_ and _references_ on
Common Lisp really teach people the language they can expect to see
_used_. By changing the conditionals, which John Foderaro says he thinks
of as _fundamental_ to a language, he exposes people to a _different_
language, regardless of how much he keeps claiming that he is writing and
using "Common Lisp".
Getting rid of the personal idiosyncrasies of individual contributors
does in fact improve both readablity and acceptability of the source code
to a large number of people, just as it does for prose text. As I have
pointed out repeatedly, publishers and _responsible_ companies ensure
that their _published_ materials follow standards that are far more
_inclusive_ than some "style" of a wacky employee, because the use of
slang, sociolects, etc, in technical documentation, code, and the like
_excludes_ all those who do not appreciate it, who do not want to be
members of a freak show just because they want to use or take part in
something. Considering the "sterility" of technical documentation and
the sheer absence of "personality" in such material, one has to grasp the
intent to communicate the ideas as cleanly as possible, understandable by
as many people as possible, and thus is nearly devoid of idioms, local
vocabulary, slang, poetic expressions, etc. It is considered hard to
write good technical documentation because it has be "alive" despite all
the usual means to keep prose text alive. But not only technical stuff,
_every_ author has to deal with the kind of "ego bruises" that come from
dealing with a serious publisher's copy editor, and most authors who are
serious about being published _understand_ that their editors know a lot
more about this than they do as authors -- after all, the author knows
the subject matter while the editors know the publishing business, and
that includes the language to use. Those who are too stupid and arrogant
to listen to expertise, who refuse to consult dictionaries and style
guides or who refuse to learn from those who have been published, do not
get published -- it is a matter of "I know everything best" versus "I
know _my_ stuff". The Net has unfortunately had a dramatic effect on the
publication rate of trash and documents that scream "Look at my personal
style!" instead of whatever they were trying to communicate, the same way
many documents screamed "Look at what my Macintosh can do!" back when
that was the measure of ridiculous hipness. But still we have publishing
houses that manage to break in their authors and cause the whole stable
of authors to agree to publish books using the same style, the same font,
the same layout, etc, even though you can be dead certain that very few
of them would have chosen it on their own, and some of them probably had
a pet style that did _not_ get used. Those who go bananas over the use
of certain quotation marks, say, are simply dropped by the publisher. A
renegade author costs so much more for these publishers that you have be
a _real_ big name to pull any such stunts.
There are parts of Common Lisp that one Common Lisp programmer or another
most probably does not like, would have designed differently, etc, but
out of deference to the community of readers of _published_ code, they
understand that it is actually _preferable_ for their _own_ personal
goals to work towards community coherence over getting their personal ego
stroked, because that means fighting people all the time, every time.
Just in case there are _still_ some people who think this is about any
"technical" aspects of the if* macro: It has never been. It is certainly
not a smart macro -- is just a sugar-coated cond. What it has been about
all along is the arrogance, disrespect, stupidity, egotistical attitude
problem, and giving the finger to the community, that the primary (if not
only by this time) user of if* has ensured has become the community-wide
connotations of if*, but these connotations will not go away -- if* has
to go away for people to forget this and return to value the community
created by the standard, the textbooks, the editor and development system
support, etc, that they share. This is just like those who have read
Scheme texts that never use iteration because the authors think their
readers will figure out for themselves what their recursive style is a
_variation_ upon, since they are expected to know languages that do
iteration already, but instead these readers believe that iteration is
somehow evil and recursion is divine. In particular, if the readers of
if* code do not know how Common Lisp can be used to define new control
structures and accomodate any random lunatic's or smart programmer's
desires alike for personal macros, especially when the macro definitions
are not even included in the published source, they will not understand
any point about the supposed "power" of the language being used -- what
they will go away with it is the same kind of hostility that the author
of the if* macro first made explicit: using the standard conditionals is
_bad_. Even thinking that using such a bogus historical accident will
tell people anything new just by example unless they were shown a number
of such variations, is just silly, and yet that is precisely what they
are _not_ shown. If if* was supposed to be an exercise in pedagogy, it
was the most astonishingly incompetent such exercise in the history of
pedagogy, so let us just dispell with the notion that it was. It was and
remains a political vehicle for filibustering against the standard. This
is what I oppose, just as I oppose the equally idiotic notion that loop
is inherently bad, that upper-case symbol names are bad, that iteration
is bad, etc. _This_ is why if* is bad. Since if* also has no inherent
value for anyone besides those exposed to it in the past, meaning only
"historical reasons", there is no point it keeping it along everything
else, either. The end result is that when a vendor promotes if* in their
published code, they are _actually_ saying "screw the community and its
standard", whether they understand it or not, and admit to it or not --
it should, however, be fairly hard to ignore the consequences by now.
They can say whatever they want, in fact, about how much they treasure
the standard, but actions speak so much louder than words. The only
reason they keep publishing code with if* in it, is that they do not care
about those who want the standard to be the common point of agreement in
the comunity. Customers and users of their open source offerings should
take note of this and make their concerns explicit, just like the
perpetrator and perpetuator of the if* stunt tells everybody else to do
when they do not like something. The other possibility is that John
Foderaro is able to hold Franz Inc hostage to his insane requirements. I
would hope that this is not very likely, but by now, I no longer know.
| I may not even be able to read and understand the extended loop code
| though.
Good! So you _do_ understand what using if* in your code _does_ to its
readability and understandability and acceptability! I thought you never
would. But keep it up, and maybe you can grasp why your keyword-laden,
unnavigatable, unformattable, and generally ridiculous macro does to its
non-fan readers _just_ as you have a hard time with loop, but probably
even more so, since anyone can read up on what loop does in any number of
references and get multiple views on its merits and demerits, including
the ability to combine extended loop with do forms, mapping forms, simple
loop, iterator functions, etc. Since there is no combining if* with any
other conditionals, however, one has to buy the whole package deal, and
that by itself is revolting to many people. Additionally, seeing that
you are going to change their contributed code to use a bogus historic
artifact instead of the _standard_ conditionals, will turn people away
from contributing to source code that is full of if*. _None_ of this
political baggage comes with using loop, so understanding that if* is
much worse to readers who do not like it than loop is to you might be a
good starting point if you really want to understand why it is rejected
and why you and the vendor you _represent_ are hurting the coherence of
the community.
I really wonder what you get out of using and promoting if* at this time.
All it is telling the world is "screw you all!", which you have also said
in tone if not in words in every single one of your recent messages. How
can that be of value to you? How can it be of value to your employer? I
cannot be the only previously happy customer whose impression of your
employer has fallen dramatically because of your insistence on publishing
offensive code. It is clear to a lot of people that you would sacrifice
the standard any minute if you could get away with it, because that is
precisely what you _do_. That you obviously do not see this yourself is
a problem that at least _some_ of your colleagues must recognize, but
from what I understand, several people agree with you that upper-case is
"braindamaged" and probably agree with you that whoever wants when and
unless and extended loop are equally deranged, so you are _unreachable_.
That nothing happens to your insistence or even to your arguments in what
you probably believe is rightfully defending yourself, is not a good
sign. It frankly has me worried. At some point, the personal value of
continuing to publish if*-infested code will be less than the value of
keeping your job, your customers, your membership in the _Common_ Lisp
community, etc. This is not a threat, it is a simple prediction, which
you are of course free to think will never come true. We all choose what
we value higher among our options, and dedication bordering on stubborn
is generally valuable, except when self-destructive. Some realize this
in time to get help. Others self-destruct and take a lot of other people
with them in the process. I care about those other people.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
Erik Naggum <····@naggum.net> writes:
> * John Foderaro
> | What good is it establishing a standard if you don't follow it?
>
> Funny you should ask... But it clearly applies only to your own.
Yesterday I went to look at the inflate.cl source to check if the if*
macro is still there -- and it was. And no extended loop, when or
unless in there (although I think the code would be a lot more
readable if when and unless was used instead of the (if* ... then ...)
or (if* (not ...) then ...)).
And one more thing I couldn't find the explanation of in the John's
"Coding Standards" page is the use of single semicolon comments. I
once tried to add something to the AServe code, and when I tried to
indent it, all those comments went where they should, not where they
were put; Franz's ELI knows how to indent if*, but these single
semicolon comments are still treated the way I expect it to be, which
is a good thing. Now I keep my additions in seperate files (which use
extended loop when appropriate and only standard conditionals) so as
to not have to edit the code where I have to either update most
comments to the community agreed-upon way (or to place them manually
whenever I reindent the code, what is silly).
I actually once used the if* macro -- but after some time of using it
I found cond a lot more readable.
And if it is not still clear, I think the if* macro is bad exactly for
the reason Erik speaks about -- complete disrespect for community.
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
In article <··············@asaka.latnet.lv>, ·····@latnet.lv says...
>
> And if it is not still clear, I think the if* macro is bad exactly for
> the reason Erik speaks about -- complete disrespect for community.
>
I've got a few questions:
1. how many members of the community did you poll for their
opinions before drawing this conclusion in their name?
2. are you in favor of removing all macros from the Common Lisp
language? If the answer is no, then do you have a
algorithm for determining if the use of a given macro
shows disrespect for the Common Lisp community?
If there is no algorithm would you advocate appointing
a Pope of Common Lisp to decide if a given macro
respects or disrespects the community?
John Foderaro <···@unspamx.franz.com> writes:
> 2. are you in favor of removing all macros from the Common Lisp
> language?
No.
> If the answer is no, then do you have a algorithm for determining if
> the use of a given macro shows disrespect for the Common Lisp
> community?
Yes:
1. Does the macro provide something substantial beyond what is
provided by the operators defined in the ANSI CL standard?
2. The opposite answer to the question in step 1 is the return value
of the algorithm.
There can still of course be contention about what "something
substantial" is, but to me it seems quite clear that if* doesn't do
anything the standard conditionals don't already do well enough.
I think I'd prefer to label such macros antisocial rather than
disrespectful, though. It's like saying "I don't want to be a part of
the CL community", which of course is your choice.
The obvious question is this: What if everyone else did what you do?
Reading and sharing CL code would be a _lot_ more
problematic. Neglecting to ask oneself this question and to act on it,
is antisocial in my book.
--
Frode Vatvedt Fjeld
In article <··············@dslab7.cs.uit.no>, ······@acm.org says...
> There can still of course be contention about what "something
> substantial" is, but to me it seems quite clear that if* doesn't do
> anything the standard conditionals don't already do well enough.
>
How can it be so clear to you when you face evidence to the contrary
(that evidence being me at least and you can assume there are others)?
We bemoan the fact that C programmers take one look at the
Lisp syntax and say "yuck, I can't program like that.".
We know that if we can get them over the hurdle and starting to
program in Lisp many will realize the power of the Lisp syntax.
So when you said that it was clear that if* didn't do anything
substantial was that based on a snap judgement or did you
actually do some work with it over a period of time?
You also realize that reasonable people will disagree on whether
something is a substantial enhancement or not. Thus you'll
need an unquestioned leader to make the decision or else
the community will split many ways. Thus I'll put you
down for wanting a Pope of Common Lisp.
>
> The obvious question is this: What if everyone else did what you do?
I would thank them for the code they contributed.
I would look at what they had done and try to understand
what benefit the macros had over what I was using myself
and I would take their ideas (to the extent it was legal
to do so) and make my own programs better.
John Foderaro <···@xspammerx.franz.com> writes:
> You also realize that reasonable people will disagree on whether
> something is a substantial enhancement or not. Thus you'll need an
> unquestioned leader to make the decision or else the community will
> split many ways.
The "unquestioned leader" is the community compromise known as the
ANSI CL standard. Being part of a community usually involves making
compromises, and in this context of programming languages it seems to
me that agreeing on how to express primitive conditionals reasonably
fall into the "required" category for being part of a community.
I think it's unreasonable to claim that "slightly improved indenting
in some people's view" is a substantial enhancement for such an
important part of the language.
> Thus I'll put you down for wanting a Pope of Common Lisp.
This is ridiculous.
>> The obvious question is this: What if everyone else did what you do?
>
> I would thank them for the code they contributed.
> I would look at what they had done and try to understand
> what benefit the macros had over what I was using myself
> and I would take their ideas (to the extent it was legal
> to do so) and make my own programs better.
I think that after having learned about 5 random pet syntaxes that
provide essentially nothing beyond what standard operators do, you
would be sick and tired of it.
--
Frode Vatvedt Fjeld
In article <··············@dslab7.cs.uit.no>, ······@acm.org says...
>> The "unquestioned leader" is the community compromise known as the
>> ANSI CL standard. Being part of a community usually involves making
>> compromises, and in this context of programming languages it seems to
>> me that agreeing on how to express primitive conditionals reasonably
>> fall into the "required" category for being part of a community.
>>
There has never been any question that an otherwise ANSI
compliant program using the if* macro along with the source for
the if* macro results in a 100% ANSI compliant common lisp program.
So the ANSI spec is out of this. Now we're down to people
making judgment calls and all the people agreeing to relinquish
their freedom to one supreme leader (or committee) who will tell them
if their code is immoral/disrespectful/unsubstantial.
Since this kind of judgment is clear to you let me ask you to
pass judgment on three things. You can't hedge. You must make
a judgement, the community is counting on you.
1. suppose I have a macro +$ that puts fixnum declarations around
everything in a +
(+$ a b c) => (the fixnum (+ (the fixnum a) (the fixnum b) (the fixnum c)))
Is +$ moral/respectful/substantial?
2. suppose I have +% which is simpler and just declares the result
to be a fixnum
(+% a b c) => (the fixnum (+ a b c))
Is +% moral/respectful/substantial?
3. regression testing is important to find bugs and ensure they
come back in. One question you always have about your test suites
is "how much of my code is really being tested?"
One way to measure test coverage is to put meters at all
branch points in the code and count how many times each branch
was taken while the test suites were run. If the count is zero
for any branch you should investigate why you aren't testing that
branch.
Suppose I modify if* so that it if a certain switch is set
when code using it is compiled. it puts meters at the
beginning of all the 'then' clauses (each if* can have multiple
then clauses). This will give an approximate idea of the
test coverage (only approximate since there are other
ways of doing branching than if*)
however it will point out all of the branches within an if*
that were *not* taken and that's useful information.
So we've got an if* that normally works as it does now but can go
into test mode and insert metering.
Is if* now moral/respectful/substantial?
From: Dorai Sitaram
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <9t0us8$n6l$1@news.gte.com>
In article <··························@news.dnai.com>,
John Foderaro <···@xspammerx.franz.com> wrote:
>In article <··············@dslab7.cs.uit.no>, ······@acm.org says...
>>> The "unquestioned leader" is the community compromise known as the
>>> ANSI CL standard. Being part of a community usually involves making
>>> compromises, and in this context of programming languages it seems to
>>> me that agreeing on how to express primitive conditionals reasonably
>>> fall into the "required" category for being part of a community.
>>>
>
> There has never been any question that an otherwise ANSI
>compliant program using the if* macro along with the source for
>the if* macro results in a 100% ANSI compliant common lisp program.
>
> So the ANSI spec is out of this. Now we're down to people
>making judgment calls and all the people agreeing to relinquish
>their freedom to one supreme leader (or committee) who will tell them
>if their code is immoral/disrespectful/unsubstantial.
I don't think if* is disrespectful but the
objection may be that it is _too_ substantial.
I think that people don't really like complicated
macros for some reason. If the macro is doing mere
visual rearranging, of a template sort, they
don't seem to mind, but if it involves keeping track of
the macro's subforms in an accumulative fashion,
something defensive goes off. It's almost as if you
gave someone a Pushtu-to-English dictionary and a
grammar of the Pushtu language in English, proceeded to
speak Pushtu, and then claimed you were really only
speaking English because the dictionary and the grammar
constitute a macro.
Why this judgment call (for CL, not for English) I
don't know. I seem to share in this feeling that a
non-template-esque macro somehow changes the language
in a non grata way. But I recognize it's just a
feeling and not something solider.
--d
John Foderaro <···@xspammerx.franz.com> writes:
> So the ANSI spec is out of this.
No it's not. The ANSI standard also helps people reading code, not
just the computer. It is not my concern that computers will not be
able to compile if*.
> Now we're down to people making judgment calls and all the people
> agreeing to relinquish their freedom to one supreme leader (or
> committee) who will tell them if their code is
> immoral/disrespectful/unsubstantial.
I'm not saying if* is immoral. I find it anti-social, somewhat like a
child refusing to wear clothes in public, unwilling to relinquish that
freedom to the "supreme leader" that has installed the custom of
wearing some minimum of clothing in our community. Or perhaps more
like myself insisting on writing in my native language in this news
group because I find it much more aestethically pleasing or whatever.
> Since this kind of judgment is clear to you let me ask you to pass
> judgment on three things. You can't hedge. You must make a
> judgement, the community is counting on you.
I don't think your examples/questions are very relevant, because they
deal with what I'd consider a very specialized task of optimizing what
would have to be a very particular sort of application for requiring
so many fixnum declarations as to warrant such macros. This is simply
nowhere near as important or ubiquitous a concept as the primitive
conditionals.
For example, someone recently asked here why he couldn't specialize
the equal function for his own user-defined type. Suppose he decided
it would be really nice to be able to do this, and he added his own
generic function "test" that he'd consistently use in place of
equal. I'd advice against this on pretty much the same grounds I'd
advice against using if*.
I agree with you that there may be borderline cases as to what is
important and basic functionality, and what is substantial
enhancement. But if* is just not a borderline case, in my opinion.
> [...] So we've got an if* that normally works as it does now but can
> go into test mode and insert metering.
>
> Is if* now moral/respectful/substantial?
I suppose for the same reason you will add your own defun*,
defmethod*, and so on? And then make use of the star operators
mandatory, so that metering will not miss out on half the execution
paths? Then what have you achieved? A new lisp* that allows every
operator in the common-lisp* package to be redefined, a feature that
certainly would be useful at times, but which was rejected for Common
Lisp for good reasons. I think it would be a very poor design for a
regression test package.
--
Frode Vatvedt Fjeld
I'm disappointed that you failed to answer the three
simple questions I presented. I think that what
we've learned here is that is silly to talk about
a macro being antisocial, immoral or insufficient
on a community level. This kind of talk falls apart
when you are now faced with making judgements about
other macros and variants of existing macros.
You simply couldn't do it so you hedged and gave
excuses.
In article <··············@dslab7.cs.uit.no>, "Frode Vatvedt Fjeld"
<······@acm.org> wrote:
> John Foderaro <···@xspammerx.franz.com> writes:
>> So the ANSI spec is out of this.
> No it's not. The ANSI standard also helps people reading code, not just
> the computer. It is not my concern that computers will not be able to
> compile if*.
>
We don't demand that literature be understandable to those with only a
grade school education; nor do we have a similar expectation for
programs.
> I'm not saying if* is immoral. I find it anti-social, somewhat like a
> child refusing to wear clothes in public, unwilling to relinquish that
> freedom to the "supreme leader" that has installed the custom of wearing
> some minimum of clothing in our community.
Heh. That kind of behavior would make me think "Yeah! Fight the power!"
To each is own. It's clear to me that a macro is not immoral unless
perhaps it contains a documentation string like "By viewing use of this
macro you agree to serve as John Foderaro's personal towelboy on demand."
On the other hand, one can make judgements of taste about macros and
programming style in general. I personally disagree with just about
everything Foderaro has to say about Lisp style, and wouldn't touch if*
with a 10 foot pole, but that's OK. I find other macro constructs, such as introducing
magic variables, even more distasteful. Equating morality and taste
never does any good.
I think this whole flame is serving as a kind of proxy for resentment of
Franz' success, its power in the Lisp community, and anxiety over its actions and
perceived arrogance. Indeed, the nature of Franz' open source contributions is a little
ambiguous; the license is cool, but "open source" these days carries, for better or
worse, a notion of "compile and install anywhere." The Franz code is not
like that, mostly because it does unportable things like going to the
network. Foderaro has equated supplying the source to if* with supplying
the source to all the unportable features of ACL; but I don't buy that.
if* can obviously be implemented in portable Common Lisp without a lot of
effort. I encourage and applaud making the source to if* easily
available. Perhaps the source to if* can go in CLOCC or CCLAN and we can be
done with this flame.
>> Is if* now moral/respectful/substantial?
> I suppose for the same reason you will add your own defun*, defmethod*,
> and so on? And then make use of the star operators mandatory, so that
> metering will not miss out on half the execution paths? Then what have
> you achieved? A new lisp* that allows every operator in the common-lisp*
> package to be redefined, a feature that certainly would be useful at
> times, but which was rejected for Common Lisp for good reasons.
This was absolutely not rejected in Common Lisp. In fact, you can define
your own operators with the same names as the standard operators; the
editor of the standard itself has recently posted examples of how to do
this! Your suggestion of making new * operators seems less confusing
then that approach to a casual reader, but so what? Not all code
can/should require only casual viewing for comprehension.
Tim
In article <··············@dslab7.cs.uit.no>, Frode Vatvedt Fjeld
<······@acm.org> wrote:
> For example, someone recently asked here why he couldn't specialize
> the equal function for his own user-defined type. Suppose he decided
> it would be really nice to be able to do this, and he added his own
> generic function "test" that he'd consistently use in place of
> equal
Why isn't "equal" a generic function? It (and "<") are in Dylan. Is it
because CLOS is too recent to be fully-integrated into the language? Or
is it for efficiency reasons?
> > [...] So we've got an if* that normally works as it does now but can
> > go into test mode and insert metering.
> >
> > Is if* now moral/respectful/substantial?
>
> I suppose for the same reason you will add your own defun*,
> defmethod*, and so on? And then make use of the star operators
> mandatory, so that metering will not miss out on half the execution
> paths? Then what have you achieved? A new lisp* that allows every
> operator in the common-lisp* package to be redefined, a feature that
> certainly would be useful at times, but which was rejected for Common
> Lisp for good reasons.
Can you say what those good reasons are?
Dylan allows you to do this. When you import a library -- such as the
base Dylan library -- you can choose to not import some things, or to
import them with different bindings, and then construct your own. You
can then if you want export some of your stuff and some of the standard
stuff as a new library. So, you might well make a
"regression-testing-Dylan" library and start your program with "use
regression-testing-Dylan" instead of "use Dylan" or "use
Harlequin-Dylan".
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <··············@dslab7.cs.uit.no>, Frode Vatvedt Fjeld
> <······@acm.org> wrote:
>
> > For example, someone recently asked here why he couldn't specialize
> > the equal function for his own user-defined type. Suppose he decided
> > it would be really nice to be able to do this, and he added his own
> > generic function "test" that he'd consistently use in place of
> > equal
> Why isn't "equal" a generic function? It (and "<") are in Dylan.
> Is it because CLOS is too recent to be fully-integrated into the
> language? Or is it for efficiency reasons?
No, for the scenario to be comparable to that of IF*, the reason to
make up TEST to replace EQUAL is that the creator of TEST considers
EQUAL to be, somehow, braindamaged, and prefers to make up his own
private variation.
Peoples' private variations are certainly their own business, and
nothing to be terribly concerned about.
What would certainly become distressing would be if:
- One person despises EQUAL, and makes up their own TEST, and starts
pushing that out into public code bases, rewriting other peoples'
code to use TEST rather than EQUAL;
- Another person despises LOOP, makes up their own alternative,
DLOOP, and starts rewriting others' code to use DLOOP;
- I come along, despise TEST, love LOOP, and start dueling with the
other guys over what should be out there in public chunks of CL
code.
What with the strangeness of LOOP, it would not seem blatantly
deranged to explore having some Alternative Control Structures like
IF*; the problem comes in when someone tries to start pressuring
everyone to adopt such devoid of there having been any debate on
whether or not this was a good idea.
The Scheme folk have started a "pseudo-standardization process" called
SRFIs whereby:
- someone puts together a proposal for some libraries;
- that someone provides a sample implementation;
- there is then a debate by interested parties as to whether the
proposal seems wise or whether it is somehow totally deranged.
If there is general assent, the SRFI gets treated as "final;" if not,
discussion continues, and when assent has not been reached, some
SRFI's have been _dropped_.
That bears at least vague similarities to how you get standards
formalized. Whether the effort involved with SRFI's is sufficient is
certainly open to debate; they're certainly not any sort of massive
"de jure" standard. In the absense of likelihood of standards bodies
coming along to debate putting such stuff into an "R6RS," it's at
least better than _nothing_. Right now, there's not much in the way
of analagous discussions in the CL world; there's _zero_ likelihood of
ANSI CL changing any time soon, and there's not vastly a lot of
"SRFI-like" stuff going on either.
When IF* is being publicized as a "Lisp Coding Standard," devoid of
there having been any group of people agree on this, the _process_ is
clearly quite deranged.
--
(reverse (concatenate 'string ····················@" "454aa"))
http://www.cbbrowne.com/info/x.html
Rules of the Evil Overlord #54. "I will not strike a bargain with a
demonic being then attempt to double-cross it simply because I feel
like being contrary." <http://www.eviloverlord.com/>
Bruce Hoult wrote:
> In article <··············@dslab7.cs.uit.no>, Frode Vatvedt Fjeld
> <······@acm.org> wrote:
>
>> For example, someone recently asked here why he couldn't specialize
>> the equal function for his own user-defined type. Suppose he decided
>> it would be really nice to be able to do this, and he added his own
>> generic function "test" that he'd consistently use in place of
>> equal
>
> Why isn't "equal" a generic function? It (and "<") are in Dylan. Is it
> because CLOS is too recent to be fully-integrated into the language? Or
> is it for efficiency reasons?
No it is because < is meant specifically as "arithmetic lesser" and EQUAL is
for comparison based on structural similarity.
Creating a gf for equal and < would imply that it is enough to look at the
type of the operands to decide how they should be compared. Imagine a
"person" type - how do you compare persons? Without _any_ context only the
identity (EQ) would make some sense.
>> > [...] So we've got an if* that normally works as it does now but can
>> > go into test mode and insert metering.
>> >
>> > Is if* now moral/respectful/substantial?
>>
>> I suppose for the same reason you will add your own defun*,
>> defmethod*, and so on? And then make use of the star operators
>> mandatory, so that metering will not miss out on half the execution
>> paths? Then what have you achieved? A new lisp* that allows every
>> operator in the common-lisp* package to be redefined, a feature that
>> certainly would be useful at times, but which was rejected for Common
>> Lisp for good reasons.
>
> Can you say what those good reasons are?
A lisp-system can depend rather heavily on the specific behaviour of it's
provided core-functions. *Redefining* such a core function can lead to very
nasty bugs. Think of the TRACE utility and it's dependence on input/output.
> Dylan allows you to do this. When you import a library -- such as the
> base Dylan library -- you can choose to not import some things, or to
> import them with different bindings, and then construct your own. You
> can then if you want export some of your stuff and some of the standard
> stuff as a new library. So, you might well make a
> "regression-testing-Dylan" library and start your program with "use
> regression-testing-Dylan" instead of "use Dylan" or "use
> Harlequin-Dylan".
This is not the same as "redefining" in the above sense. In Common Lisp you
could create a package "MY-VERY-OWN-LISP" and then let this package USE the
common-lisp package. For all those symbols for which you want to "overload"
the meaning in you own package you "shadow" the symbol of the Common Lisp
package and provide your own implementation. This means you will get a
_different_ symbol for all "redefined" entities in the new package and all
other entities can still rely on the consistency of the originals.
ciao,
Jochen
--
http://www.dataheaven.de
In article <············@rznews2.rrze.uni-erlangen.de>, Jochen Schmidt
<···@dataheaven.de> wrote:
> Bruce Hoult wrote:
>
> > In article <··············@dslab7.cs.uit.no>, Frode Vatvedt Fjeld
> > <······@acm.org> wrote:
> >
> >> For example, someone recently asked here why he couldn't specialize
> >> the equal function for his own user-defined type. Suppose he decided
> >> it would be really nice to be able to do this, and he added his own
> >> generic function "test" that he'd consistently use in place of
> >> equal
> >
> > Why isn't "equal" a generic function? It (and "<") are in Dylan.
> > Is it because CLOS is too recent to be fully-integrated into the
> > language? Or is it for efficiency reasons?
>
> No it is because < is meant specifically as "arithmetic lesser" and
> EQUAL is for comparison based on structural similarity.
>
> Creating a gf for equal and < would imply that it is enough to look at
> the type of the operands to decide how they should be compared. Imagine
> a "person" type - how do you compare persons? Without _any_ context
> only the identity (EQ) would make some sense.
Two comments to that:
1) no one is forcing you to implement = and < for every class. If it's
not appropriate then don't do it. Good taste is always essential in
pogramming.
2) what if your class is a new representation for numbers? Continued
fractions, say. Surely it is useful to be able to add a method to
the < GF in that case?
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> 2) what if your class is a new representation for numbers? Continued
> fractions, say. Surely it is useful to be able to add a method to
> the < GF in that case?
In that case:
(defpackage :my-numbers
(:use :cl)
(:shadow "<" ...))
Programs that use CL:< know what they're getting, and that's a good
thing.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@apocalypse.OCF.Berkeley.EDU>,
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > 2) what if your class is a new representation for numbers? Continued
> > fractions, say. Surely it is useful to be able to add a method to
> > the < GF in that case?
>
> In that case:
>
> (defpackage :my-numbers
> (:use :cl)
> (:shadow "<" ...))
>
> Programs that use CL:< know what they're getting, and that's a good
> thing.
Surely you've just contradicted the whole *idea* of polymorphic and/or
object-oriented programming?
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@apocalypse.OCF.Berkeley.EDU>,
> ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > Bruce Hoult <·····@hoult.org> writes:
> >
> > > 2) what if your class is a new representation for numbers? Continued
> > > fractions, say. Surely it is useful to be able to add a method to
> > > the < GF in that case?
> >
> > In that case:
> >
> > (defpackage :my-numbers
> > (:use :cl)
> > (:shadow "<" ...))
> >
> > Programs that use CL:< know what they're getting, and that's a good
> > thing.
>
> Surely you've just contradicted the whole *idea* of polymorphic and/or
> object-oriented programming?
No, I've shown how you can better fit CL to your desires. I suppose I
should have finished my example:
(defpackage :my-dialect
(:use :cl)
(:shadow "<" ">" "EQUAL" ...))
(in-package :my-dialect)
(defmethod < (x y) (cl:< x y))
(defmethod > (x y) (cl:> x y))
(defmethod equal (x y) (cl:equal x y))
;;; ...
CL has built-in support for OOP, but it doesn't favor it over other
styles, and I'm glad. If you want to program exclusively in the OO
subdialect of CL, you can. If you want to mostly ignore CLOS, that's
also pretty easy. About the only place I wish CLOS were more tightly
integrated is the condition system. Other than that, it gives you the
facilities to build a wide range of Lisp dialects of your own, with
minimal effort.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214871414432291@naggum.net>
* Thomas F. Burdick
| About the only place I wish CLOS were more tightly integrated is the
| condition system.
I am not sure I follow you. What would you want?
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
Erik Naggum <····@naggum.net> writes:
> * Thomas F. Burdick
> | About the only place I wish CLOS were more tightly integrated is the
> | condition system.
>
> I am not sure I follow you. What would you want?
Pretty much I'd want the condition system to acknowledge CLOS as a
first-class, permanent part of the language, that it wasn't a bad
idea, and that it's not going anywhere. For example:
| Condition Type CONDITION
|
| Class Precedence List:
|
| condition, t
|
| Description:
|
| All types of conditions, whether error or non-error, must inherit
| from this type.
[...]
| Whether a user-defined condition type has slots that are accessible
| by with-slots is implementation-dependent. Furthermore, even in an
| implementation in which user-defined condition types would have
| slots, it is implementation-dependent whether any condition types
| defined in this document have such slots or, if they do, what their
| names might be; only the reader functions documented by this
| specification may be relied upon by portable code.
So with objects of the condition classes that I define myself, I'm not
allowed to use with-slots if I expect my code to be portable. Hrm.
| Conforming code must observe the following restrictions related to
| conditions:
|
| * define-condition, not defclass, must be used to define new
| condition types.
That's weird. Why not just define a "condition type" to be any class
that inherits from "condition", and let me use defclass? [*]
| * make-condition, not make-instance, must be used to create
| condition objects explicitly.
Well, why not? Are these or aren't these CLOS objects? [*]
| * The :report option of define-condition, not defmethod for
| print-object, must be used to define a condition reporter.
|
| * slot-value, slot-boundp, slot-makunbound, and with-slots must not
| be used on condition objects. Instead, the appropriate accessor
| functions (defined by define-condition) should be used.
Well, that's weird. More things I can do with ordinary, pedestrian
objects, that I can't do with these weird condition objects. This
last set of restrictions I find particularly annoying. I use the
presence or absence of accessor functions as a way of implying the
private nature of a slot. If you're a consumer of one of my classes
and you find yourself using SLOT-VALUE, there's something wrong.
That's an internal detail that might change, and it indicates poor use
or poor design of the API. (Unless you're extending the class, but
even still, the slot might change). But with condition classes, I
can't do this [**].
[*] These are, of course, rhetorical questions. The answer is because
maybe condition types aren't CLOS classes, and maybe condition objects
aren't CLOS objects, in case CLOS was later decided to be a mistake.
[**] And not just in portable code, but CMUCL, in complete compliance
with the standard, doesn't let me do this. Conditions are structures,
not CLOS objects. Bleah. For once, C++ has the right idea,
conditions should use the full class system, not structures.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
[Not sure what this has to do with md5 any more, but I'm not sure this
hopefully small point needs to be a whole separate thread either...]
Erik Naggum <····@naggum.net> writes:
> * Thomas F. Burdick
> | About the only place I wish CLOS were more tightly integrated is the
> | condition system.
>
> I am not sure I follow you. What would you want?
Well, we deliberately kept away from making any condition types use
multiple-inheritance in the original design because some wanted to
protect the possibility of "backing out" of CLOS. In file system
errors, MI would have been handy. For example, one sometimes wants
to mix a network error with a file error, or a directory error with a
file error. Indeed, just having a broad class of "temporary error"
with a "wait a little while and try again" restart would be very handy.
HOWEVER, I do urge people not to use the terminology "CLOS is not tightly
integrated" to describe this. CLOS describes even structure classes and
builtin classes. So the choice of structure class (or something that could
be implemented as structure class, since error objects have no defined
metaclass) doesn't move far away from CLOS.
It might also have been nice to have a read-only metaclass for
conditions, had we been able to work out the details of what it would
mean to initialize such a thing (usually requiring low-level
assignments to unassignable slots ... mostly just a terminology
nightmare, perhaps a few small semantics nits to deal with :-). And
conditions might have had such a defined metaclass. But again, the failure
to have this isn't a weakness of CLOS integration.
I would instead say it would be nice if the condition system made
better use of the many well-integrated features of CLOS. Perhaps that's
just words, but I think it expresses things better.
I'm still bristling a little from seeing someone in the discussion next
to my Slashdot interview remark that CLOS was little more than a macro
package. What an amazing stretch that point of view was...
Kent M Pitman <······@world.std.com> writes:
> [Not sure what this has to do with md5 any more, but I'm not sure this
> hopefully small point needs to be a whole separate thread either...]
>
> Erik Naggum <····@naggum.net> writes:
>
> > * Thomas F. Burdick
> > | About the only place I wish CLOS were more tightly integrated is the
> > | condition system.
> >
> > I am not sure I follow you. What would you want?
>
> Well, we deliberately kept away from making any condition types use
> multiple-inheritance in the original design because some wanted to
> protect the possibility of "backing out" of CLOS. In file system
> errors, MI would have been handy. For example, one sometimes wants
> to mix a network error with a file error, or a directory error with a
> file error. Indeed, just having a broad class of "temporary error"
> with a "wait a little while and try again" restart would be very handy.
>
> HOWEVER, I do urge people not to use the terminology "CLOS is not tightly
> integrated" to describe this. CLOS describes even structure classes and
> builtin classes. So the choice of structure class (or something that could
> be implemented as structure class, since error objects have no defined
> metaclass) doesn't move far away from CLOS.
Hmm, but that's exactly how it feels, unintegrated. It certainly has
to use *some* class or structure or something system, but not
necessarily one like CLOS. The rest of the standard can't really be
seperated from CLOS. The condition system carefully avoids CLOS, and
keeps it at an arm's length, using what feels like very careful
language.
> It might also have been nice to have a read-only metaclass for
> conditions, had we been able to work out the details of what it would
> mean to initialize such a thing (usually requiring low-level
> assignments to unassignable slots ... mostly just a terminology
> nightmare, perhaps a few small semantics nits to deal with :-). And
> conditions might have had such a defined metaclass. But again, the failure
> to have this isn't a weakness of CLOS integration.
>
> I would instead say it would be nice if the condition system made
> better use of the many well-integrated features of CLOS. Perhaps that's
> just words, but I think it expresses things better.
Those features are well-integrated in the rest of the language,
though. It's not that CLOS isn't well integrated -- it's an inseparable
part of the language, except for the condition system.
> I'm still bristling a little from seeing someone in the discussion next
> to my Slashdot interview remark that CLOS was little more than a macro
> package. What an amazing stretch that point of view was...
$10 says the poster was regurgitating what his/her professor told
him/her. :-/
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@whirlwind.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Hmm, but that's exactly how it feels, unintegrated.
Incidentally, when I was getting the page from the hyperspec that I
quoted in my reply to Erik, I noticed for the first time the failed
cleanup issue "CLOS-CONDITIONS:INTEGRATE". This is pretty much what I
was talking about. And, apparently, I'm not the only one who thinks
it is an issue of CLOS-Condition integration :-)
In article <···············@shell01.TheWorld.com>, Kent M Pitman wrote:
> I'm still bristling a little from seeing someone in the discussion next
> to my Slashdot interview remark that CLOS was little more than a macro
> package. What an amazing stretch that point of view was...
Lol! I'm venturing to guess it was this remark, which
also struck me, more than any other, as particularly odd:
"The object system in Common LISP was an afterthought,
and it shows. It's really a macro package kind of thing.
LISP has a strong history of overly elaborate macros;
ever see the MIT LOOP macro? These have the usual problem;
what you're looking at in the source isn't what's running,
and debugging macros (especially those written by others)
is hell. Most other high-level languages have banished
macros, or discourage their use."
In contrast to this point of view, Kaz Kylheku wrote
elsewhere in comp.lang.lisp a penetrating and insightful
comment on CLOS and macros:
"An example of the power of LISP macros is the Common LISP Object
System (CLOS); an entire object oriented programming system that
can be implemented using macros. It polymorphism through generic
functions, multiple inheritance, and implementations of it even
support meta-class programming. The (defclass ...) construct of
CLOS is (implemented as) a macro for defining a class. Consider
that when LISP macros were invented, OOP didn't exist. When OOP
came along, entire programming language families hit a brick wall
and died. LISP programmers just wrote OOP systems in LISP and
merrily carried on. This inspires a kind of confidence in LISP that
it will be able to acquire any language feature that anyone comes up
with in the forseeable future."
···@whirlwind.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > HOWEVER, I do urge people not to use the terminology "CLOS is not tightly
> > integrated" to describe this. CLOS describes even structure classes and
> > builtin classes. So the choice of structure class (or something that could
> > be implemented as structure class, since error objects have no defined
> > metaclass) doesn't move far away from CLOS.
>
> Hmm, but that's exactly how it feels, unintegrated. It certainly has
> to use *some* class or structure or something system, but not
> necessarily one like CLOS. The rest of the standard can't really be
> seperated from CLOS. The condition system carefully avoids CLOS, and
> keeps it at an arm's length, using what feels like very careful
> language.
But CLOS didn't address ANY of the objects in the system. It didn't
single out conditions not to address. From a procedural point of
view, it was up to those other chapters to address CLOS. The CLOS
proposal offered itself as a wholly generic total view of all data,
and didn't really need to go in and say "this has this many slots" or
"this will be done by gf" or "this will have this metaclass" or
whatever... So however it "feels", procedurally and historically
you have it backwards.
It may be unintegrated, but the lack of integration is the condition
system's with CLOS, not vice versa. It's not a symmetric thing.
There is close to zero chance anyone would have accepted a CLOS
proposal that attempted to diddle with individual facilities that way.
The other way around, though, it could have been that a conditions
proposal that addressed CLOS was adopted; it just wasn't. But the
vote was much closer.
It simply is not reasonable to say that CLOS is not 100% in there from
the ground up throughout the language. The condition system, on the
other hand, is just like any user program. It uses CLOS in the way
its particular programmer/designers thought to use it (and how the
language designers were willing to accept).
Bruce Hoult wrote:
> In article <···············@apocalypse.OCF.Berkeley.EDU>,
> ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
>> Bruce Hoult <·····@hoult.org> writes:
>>
>> > 2) what if your class is a new representation for numbers? Continued
>> > fractions, say. Surely it is useful to be able to add a method to
>> > the < GF in that case?
>>
>> In that case:
>>
>> (defpackage :my-numbers
>> (:use :cl)
>> (:shadow "<" ...))
>>
>> Programs that use CL:< know what they're getting, and that's a good
>> thing.
>
> Surely you've just contradicted the whole *idea* of polymorphic and/or
> object-oriented programming?
Common Lisp is not (only) about polymorphic and/or object-oriented
programming! Common Lisp is not a "pure" language and this is _definitely_
a good thing. Thomas showed perfectly valid how to use the package system
of Common Lisp to enhance the language in it's basics. In my post I
outlined this option, and the other option to use a different called
generic function. You can even combine both approaches and create a package
that shadows several of CLs non-generic constructs with generic ones.
It _is_ possible - and it is not difficult to do it. It is a particular good
sign that this things are so easyly doable in Common Lisp...
ciao,
Jochen
--
http://www.dataheaven.de
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@apocalypse.OCF.Berkeley.EDU>,
> ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > Bruce Hoult <·····@hoult.org> writes:
> >
> > > 2) what if your class is a new representation for numbers? Continued
> > > fractions, say. Surely it is useful to be able to add a method to
> > > the < GF in that case?
> >
> > In that case:
> >
> > (defpackage :my-numbers
> > (:use :cl)
> > (:shadow "<" ...))
> >
> > Programs that use CL:< know what they're getting, and that's a good
> > thing.
>
> Surely you've just contradicted the whole *idea* of polymorphic and/or
> object-oriented programming?
(defpackage :my-numbers
(:use :cl)
(:shadow "<" ...))
(defgeneric < ((n1 number) (n2 number))
(cl:< n1 n2))
(defgeneric < ((n1 my-number) (n2 my-number))
(some-fancy-ge-operator n1 n2))
I do not understand your comments. While is it true that cl:< is not
- quote - polymorphic - unquote - it seems to me that you can add
"polymorphism" as you like.
Dylan surely has newer and better ways to do this sort of things. But
the essence is here in CL.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti
<·······@cs.nyu.edu> wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > In article <···············@apocalypse.OCF.Berkeley.EDU>,
> > ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> >
> > > Bruce Hoult <·····@hoult.org> writes:
> > >
> > > > 2) what if your class is a new representation for numbers?
> > > > Continued
> > > > fractions, say. Surely it is useful to be able to add a method
> > > > to
> > > > the < GF in that case?
> > >
> > > In that case:
> > >
> > > (defpackage :my-numbers
> > > (:use :cl)
> > > (:shadow "<" ...))
> > >
> > > Programs that use CL:< know what they're getting, and that's a good
> > > thing.
> >
> > Surely you've just contradicted the whole *idea* of polymorphic and/or
> > object-oriented programming?
>
> (defpackage :my-numbers
> (:use :cl)
> (:shadow "<" ...))
>
> (defgeneric < ((n1 number) (n2 number))
> (cl:< n1 n2))
>
> (defgeneric < ((n1 my-number) (n2 my-number))
> (some-fancy-ge-operator n1 n2))
>
> I do not understand your comments. While is it true that cl:< is not
> - quote - polymorphic - unquote - it seems to me that you can add
> "polymorphism" as you like.
This will obviously work within new code that you're writing, but as far
as I can see it's not going to do a thing when you pass a list of
my-number objects to someone else's code e.g. the built in "sort"
function.
OK, sort isn't a good example, because it explicitly takes a predicate
argument. How about "min" or "max"??
> Dylan surely has newer and better ways to do this sort of things. But
> the essence is here in CL.
While I started out with Dylan, I wouldn't be here if I didn't think
there might be something to learn from CL :-)
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti
> <·······@cs.nyu.edu> wrote:
>
> > Bruce Hoult <·····@hoult.org> writes:
> >
> > > In article <···············@apocalypse.OCF.Berkeley.EDU>,
> > > ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> > >
> > > > Bruce Hoult <·····@hoult.org> writes:
> > > >
> > > > > 2) what if your class is a new representation for numbers?
> > > > > Continued
> > > > > fractions, say. Surely it is useful to be able to add a method
> > > > > to
> > > > > the < GF in that case?
> > > >
> > > > In that case:
> > > >
> > > > (defpackage :my-numbers
> > > > (:use :cl)
> > > > (:shadow "<" ...))
> > > >
> > > > Programs that use CL:< know what they're getting, and that's a good
> > > > thing.
> > >
> > > Surely you've just contradicted the whole *idea* of polymorphic and/or
> > > object-oriented programming?
> >
> > (defpackage :my-numbers
> > (:use :cl)
> > (:shadow "<" ...))
> >
> > (defgeneric < ((n1 number) (n2 number))
> > (cl:< n1 n2))
> >
> > (defgeneric < ((n1 my-number) (n2 my-number))
> > (some-fancy-ge-operator n1 n2))
> >
> > I do not understand your comments. While is it true that cl:< is not
> > - quote - polymorphic - unquote - it seems to me that you can add
> > "polymorphism" as you like.
>
> This will obviously work within new code that you're writing, but as far
> as I can see it's not going to do a thing when you pass a list of
> my-number objects to someone else's code e.g. the built in "sort"
> function.
>
> OK, sort isn't a good example, because it explicitly takes a predicate
> argument. How about "min" or "max"??
I do not understand. "Someone else's code" comes with documentation
(at least in the form of self-documentig code :) ). I will know what
I can do with her/his code.
You are complaining because cl:< (et similia) is not polymorphic. It
seems to me like complaining that in C '+' cannot add complex numbers.
That is the way it is. Dylan came later and it did the right thing
(while doing one major, immense screw up we are all aware of :) ).
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> That is the way it is. Dylan came later and it did the right thing
> (while doing one major, immense screw up we are all aware of :) ).
Well, this screw up actually seems to draw people into the Lisp world
who wouldn't have touched anything with infix syntax otherwise. And
once they are brainwashed, they don't actually mind the syntax that
much anymore. :)
Here's a poll: how many people out there would be interested in:
- using an infix version of the Gwydion Dylan compiler
- actually contributing code to an infix parser for GD?
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Marco Antoniotti <·······@cs.nyu.edu> writes:
> That is the way it is. Dylan came later and it did the right thing
> (while doing one major, immense screw up we are all aware of :) ).
Well, this screw up actually seems to draw people into the Lisp world
who wouldn't have touched anything with infix syntax otherwise. And
once they are brainwashed, they don't actually mind the syntax that
much anymore. :)
Here's a poll: how many people out there would be interested in:
- using a prefix version of the Gwydion Dylan compiler
- actually contributing code to a prefix parser for GD?
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Bruce Hoult wrote:
> In article <············@rznews2.rrze.uni-erlangen.de>, Jochen Schmidt
> <···@dataheaven.de> wrote:
>
>> Bruce Hoult wrote:
>>
>> > In article <··············@dslab7.cs.uit.no>, Frode Vatvedt Fjeld
>> > <······@acm.org> wrote:
>> >
>> >> For example, someone recently asked here why he couldn't specialize
>> >> the equal function for his own user-defined type. Suppose he decided
>> >> it would be really nice to be able to do this, and he added his own
>> >> generic function "test" that he'd consistently use in place of
>> >> equal
>> >
>> > Why isn't "equal" a generic function? It (and "<") are in Dylan.
>> > Is it because CLOS is too recent to be fully-integrated into the
>> > language? Or is it for efficiency reasons?
>>
>> No it is because < is meant specifically as "arithmetic lesser" and
>> EQUAL is for comparison based on structural similarity.
>>
>> Creating a gf for equal and < would imply that it is enough to look at
>> the type of the operands to decide how they should be compared. Imagine
>> a "person" type - how do you compare persons? Without _any_ context
>> only the identity (EQ) would make some sense.
>
> Two comments to that:
>
> 1) no one is forcing you to implement = and < for every class. If it's
> not appropriate then don't do it. Good taste is always essential in
> pogramming.
>
> 2) what if your class is a new representation for numbers? Continued
> fractions, say. Surely it is useful to be able to add a method to
> the < GF in that case?
This is true and I realized this side of the question first after I've
already submitted the post. So your question was not on having a "generic"
EQUAL but more having an EQUAL that does semantically the same as the
inbuilt but for some new datatype. An example would be structurally
comparing graphs or having arithmetic operators for new number types.
I think the reason is mainly that CLOS came after many of this things were
made. On the other side - there is nothing that hinders you creating a
generic function EQUAL that resides in your own package (shadowing the
original EQUAL) - I think that it easy enough. Another way would be to
create the generic function using a new name like EQUALS or something like
that (but please not EQUAL* ;-) ) and then implementing it similar to this:
(defmethod equals (object1 object2)
(cl:equal object1 object2))
(defmethod equals ((object1 graph) (object2 graph))
(do-whatever ..))
ciao,
Jochen
--
http://www.dataheaven.de
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214932822476660@naggum.net>
* Bruce Hoult <·····@hoult.org>
| 1) no one is forcing you to implement = and < for every class.
But what does it mean to implement < for a new class, supposing for the
sake of argument it was a generic function? This remains unclear to me.
(< a b c d) has a well-defined meaning for all real number types. (It is
less clear what it means for complex numbers, for instance.) E.g., even
though we most probably test only (< a b), (< b c), and (< c d), a true
return value implies that (< a c), (< a d), and (< b d) are also true,
and we are free to exploit this knowledge. To make sure this holds for a
user-defined type, it may be necessary to make those tests explicit,
meaning that < becomes as expensive as /=. (Some may not have realized
that (/= a b c d) is not simply (not (= a b c d)).)
We also know that (< a b) and (not (< b a)) is true for numbers, but
because of generic function dispatch, (< a b) and (< b a) may be
implemented by different methods, and it may no longer hold. Even if we
have an implementation of < that dispatches only on its first argument,
this would be true. It would also mean that (and (< a b) (< b c)) may
yield a different result than (< a c) if only because of which method is
called.
The probability of creating a royal mess here is staggeringly high, as
any C++ programmer who has tried to overload < will know, but no C++
programmer will ever bother to see if a<c if he has done a<b && b<c. The
Common Lisp specification of < means that (< a b c) should check for it.
| 2) what if your class is a new representation for numbers? Continued
| fractions, say. Surely it is useful to be able to add a method to
| the < GF in that case?
It may not be. For instance, it may make sense to create a set of
functions specialized for comparing the lengths of sequences such that no
more cdr operations are needed on lists than absolutely necessary to
determine the correct result. (length< a b c) is then different from
(and (length< a b) (length< b c)), not in value, of course, but the
latter would defeat the whole purpose of this function. A generic
function that accepted any number of arguments would have to dispatch on
the type of one or two arguments, and it would be most natural to
implement it as a progression through the argument list, comparing two
values at a time, unless one grasps the need to implement it like /=, but
in any case, the convenience value of this general implementation
technique would make smarter options much less likely to be implemented,
and the likelihood of creating a mess that computes wrong values for the
implicit would go way up.
I think the notion of adding methods to a generic function for a purely
mathematical function like < stems from a lack of reasonable builtin
support for the necessary numeric types. I mean, how often _should_ you
need to add a new kind of number class to a system? Rather than optimize
for this extremely unlikely need, optmizing for the most likely need,
i.e., using the existing number classes, seems like good engineering.
If you really want to build an experimental system, you can do it with
the package system, but you would of course not get the benefit of any
type declarations unless you had access to the compiler environment.
Franz Inc has done some work in that area. It still appears to be one of
the more complex things to experiment with and get reasonable performance
out of at the same time. If you have an incomplete number stack to begin
with, you would need good support for user-defined number types, and C++
has that, but the other way to optimize this situation is to get it right
from the start, and I think Common Lisp did that, both in terms of what
it made efficient and what it made possible with the package system.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Bruce Hoult <·····@hoult.org>
> | 1) no one is forcing you to implement = and < for every class.
>
> But what does it mean to implement < for a new class, supposing for the
> sake of argument it was a generic function? This remains unclear to
> me.
>
> (< a b c d) has a well-defined meaning for all real number types.
> (It is less clear what it means for complex numbers, for instance.)
Well, the choices are fairly limited if you want the results for complex
numbers that happen to have an imaginary part of zero to be consistent
with the results for real numbers. Comparing the magnitude is therefore
obviously a bad idea...
I see that CL doesn't define < for complex numbers. Dylan does but says
the results are implementation-dependent.
> E.g., even though we most probably test only (< a b), (< b c), and
> (< c d), a true return value implies that (< a c), (< a d), and
> (< b d) are also true, and we are free to exploit this knowledge.
> To make sure this holds for a user-defined type, it may be necessary
> to make those tests explicit, meaning that < becomes as expensive as
> /=.
< should be a total ordering. If you can't make it a total ordering for
your type then don't define it at all.
> We also know that (< a b) and (not (< b a)) is true for numbers, but
> because of generic function dispatch, (< a b) and (< b a) may be
> implemented by different methods, and it may no longer hold.
It's the programmer's responsibility to ensure that it holds. The
compiler can't check it, but it is allowed to assume that it holds.
There are plenty of parallel situations in any programming language.
> | 2) what if your class is a new representation for numbers? Continued
> | fractions, say. Surely it is useful to be able to add a method to
> | the < GF in that case?
>
> It may not be. For instance, it may make sense to create a set of
> functions specialized for comparing the lengths of sequences such that
> no
> more cdr operations are needed on lists than absolutely necessary to
> determine the correct result. (length< a b c) is then different from
> (and (length< a b) (length< b c)), not in value, of course, but the
> latter would defeat the whole purpose of this function. A generic
> function that accepted any number of arguments would have to dispatch
> on the type of one or two arguments
You want to define < on lists to mean "shorter than"? Well, OK. At
least you'll agree it's a total ordering.
Dylan side-steps the issue of generic function dispatch on multiple
arguments, because < takes only two arguments in the first place. If
you want the CL operation then you need to use reduce().
Efficiently checking that a set of lists are ordering from shortest to
longest strikes me as such a specialized thing that you really can't
avoid a specially written function to do that.
You appear to be thinking that the best way to do it is to iterate
through all the lists in parallel, and return false if the first list to
be exhausted is not the first one (and then drop the first list and
repeat...). That would be true if you're expecting a list somewhere in
the middle or towards the end to be dramatically shorter than it
"should" be, but it's not the best if it turns out that there's a
problem with an early list.
> I think the notion of adding methods to a generic function for a purely
> mathematical function like < stems from a lack of reasonable builtin
> support for the necessary numeric types. I mean, how often _should_
> you need to add a new kind of number class to a system?
That depends on what type of work you're doing.
Dylan comes with much the same numeric "tower" as CL or Scheme, so I
hardly think it's suffering from a lack of reasonable builtin support
for the necessary numeric types. Well, not unless they are as well.
C++ of course is a different matter.
> Rather than optimize for this extremely unlikely need, optmizing for
> the most likely need, i.e., using the existing number classes, seems
> like good engineering.
There is no incompatability between the two.
-- Bruce
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214959235586413@naggum.net>
* Bruce Hoult
| I see that CL doesn't define < for complex numbers. Dylan does but says
| the results are implementation-dependent.
Why? Are there any other parts of mathematics that are implementation-
dependent? One of C's really bad implementation-dependent features is
the return value of some form of integer division by negative numbers.
It is so obscure that most C programmers are completely unaware of it,
but it bites hard when it bites. The same applies to the sign of char,
which is extremely annoying when it suddenly changes on you just because
you port to a new machine. I think a language specification should try
to limit the freedom of implementations in these areas, not increase it
just because of some rinkytink hardware that gets it wrong.
| < should be a total ordering. If you can't make it a total ordering for
| your type then don't define it at all.
It is not "your type" I am concerned about, but the interaction of all
types in the system, the complexity of which increases very quickly as
you add types. If (< a b) is well-defined, and (< b c) is well-defined,
is (< a b c) and (< a c) also well-defined? They may not be. The key to
the genericity of < in CL is that it works on _all_ (real) numbers, mixed
and matched however you want. I expect this to apply to user-defined
number types, too, but that is precisely where there be dragons.
| It's the programmer's responsibility to ensure that it holds. The
| compiler can't check it, but it is allowed to assume that it holds.
This is simply a cheap cop-out. If a language gives programmers tools
that affect fundamental invariants, it is flat out irresponsible if it
does not give the programmers tools to ascertain that those invariants
are not violated.
| There are plenty of parallel situations in any programming language.
True, but that is not a good reason to create more of them.
| You want to define < on lists to mean "shorter than"? Well, OK. At
| least you'll agree it's a total ordering.
I think I may have to find some neon-sign-like fonts and have the word
"EXAMPLE" made out of it and then make it flash. Please get the point of
the example, and drop the specifics of the example. They work just like
analogies: At some point or another, they become irrelevant to the point
being communicated.
In this case, I wanted to point out that there are convenience reasons to
make certain things _equally_ hard. Adding a new method on < seems to be
easy, but it is in fact extremely hard, because the programmer needs to
keep the fundamental invariants of all the types involved intact, and
that requires a lot more computer science than you get from example code
in books on OO. In my view, real programmers will not _want_ to add a
method on < for a user-defined types because it causes many more problems
than it solves, and is actually much harder than writing type-specialized
functions.
| Dylan side-steps the issue of generic function dispatch on multiple
| arguments, because < takes only two arguments in the first place. If
| you want the CL operation then you need to use reduce().
Huh? As far as I can see, the return value of the function will be used
as one of its arguments for the next element in the sequence for reduce
to work. (reduce #'< '(1 2 3)) would cause cause reduce to make the call
equivalent to (< t 3). This is true for both both Common Lisp and Dylan,
so I wonder what you had in mind.
| Efficiently checking that a set of lists are ordering from shortest to
| longest strikes me as such a specialized thing that you really can't
| avoid a specially written function to do that.
You make assumptions at break-neck speed and crash into things. Please
be more careful. The intention of bringing up this *EXAMPLE* was to show
that multiple types of arguments in the same function call would pose
problems. Remember that Common Lisp does not use a binary <, only. With
just a little effort, you should have seen (length< 2 foo 4) as an
application of this function, where foo is some sequence and 2 and 4 are
the regular integers. And it is obviously not just < that goes into this
set of length-comparing functions. (length= foo bar zot) is a lot more
useful than you might think if you stare yourself blind at length<.
| You appear to be thinking that the best way to do it is to iterate
| through all the lists in parallel, and return false if the first list to
| be exhausted is not the first one (and then drop the first list and
| repeat...). That would be true if you're expecting a list somewhere in
| the middle or towards the end to be dramatically shorter than it "should"
| be, but it's not the best if it turns out that there's a problem with an
| early list.
This is completely beside the point, but a "problem"? What "problem"?
> I think the notion of adding methods to a generic function for a purely
> mathematical function like < stems from a lack of reasonable builtin
> support for the necessary numeric types. I mean, how often _should_ you
> need to add a new kind of number class to a system?
| That depends on what type of work you're doing.
No, that is backwards. Since we are talking about language design, it
depends on what the language specification should require of the
implementation, hence the "should". The language should not impose on
the _application_ to make these kinds of type additions _unnecessarily_.
It should also not impose on every application that does not need this
infrastructure the cost of having it available. In a dynamically typed
language, there are significant costs associated with the mere existence
of user-defined methods on primitive mathematical function. Moreover,
the language does in fact provide you with the means to get a more
elaborate dynamism, but it would be _much_ harder to get the efficient
implementation of a non- generic < operator, especially if the problem is
that all the callers of this function would call the generic version.
> Rather than optimize for this extremely unlikely need, optmizing for the
> most likely need, i.e., using the existing number classes, seems like
> good engineering.
| There is no incompatability between the two.
So generic dispatch is cost-free? Sorry, this flies in the face of facts.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
You might want to add some kind of new numeric type for which < is
well-defined mathematically, and implement that definition in code, so
you can use < on that type. Okay, that's all well and good. But this
gets into a dangerous area. You've now got a gf that you might be
tempted to hang a sorting function from. < is a mathematical concept.
I want it to stay that way; I think overloaded operators are *horrid*
ideas. Polymorphism is good; overloading is confusing and prone to
errors. Now, I might avoid overloading <, but I can't be sure that
someone else won't overload it, and do something stupid, like make it
a sorting function. Because < would be a gf in the CL function, my
code could end out accidentally using their stupid sorting function
when it thought it was using a mathematical idea. So, it wouldn't
just be giving me the rope to hang myself (I'm fine with that, I try
to be responsible enough to not hang myself), but it would be giving
*others* the rope to hang me with, too.
This is very much in the same domain as a generic EQUAL. There can be
more than one legitimate sorting order for many things. The numbers
for which < is defined have a nice, single, defined sorting order <
that no one's going to mistake for another. Allowing < to have
methods defined on it would open it up to be overloaded. This is
something that I am consistently horrified with C++ about. The
language (and Stroustrup, too, the no good &··@) *encourages* people
to overload < and == and so on. There are legitimate reasons to make
those type specific, and in C++, since they're binary, and you always
know what type you have your hands on, I don't think other people can
hang you with it. But CL is more flexible, and unless you want to
check all your types constantly, you wouldn't be able to avoid it.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Bruce Hoult
> | I see that CL doesn't define < for complex numbers. Dylan does but
> | says the results are implementation-dependent.
>
> Why?
I don't know, I wasn't there.
Perhaps it is sometimes useful to know that something has a total
ordering, even if you don't know exactly what that ordering is?
> Are there any other parts of mathematics that are implementation-
> dependent?
So what would you suggest as the true mathematical implementation of <
for complex numbers?
> One of C's really bad implementation-dependent features is
> the return value of some form of integer division by negative numbers.
Dylan shares it. The results of / of negative numbers is undefined.
There are however truncate/, floor/, ceiling/ and round/, which product
appropriate precisely-defined results for those times when you care.
> It is so obscure that most C programmers are completely unaware of it,
> but it bites hard when it bites.
Most C programmers are idiots. I'll go further than that: most C++
programmers are bloody idiots. I've lost track of the number of
contract jobs I've had where they say they use C++, and then it's only
later that they tell me not to use templates, or exceptions, or multiple
inheritance, or the STL, or ... you name it. Generally speaking, you're
often in effect asked to limit yourself to using C++ circa 1990, and
maybe not even quite that.
This happened to me mostly recently ... last month.
> | < should be a total ordering. If you can't make it a total ordering
> | for your type then don't define it at all.
>
> It is not "your type" I am concerned about, but the interaction of all
> types in the system, the complexity of which increases very quickly as
> you add types. If (< a b) is well-defined, and (< b c) is
> well-defined, is (< a b c) and (< a c) also well-defined?
I'm sorry. Are you implying that a, b, c are different types, rather
than different numbers?
> | It's the programmer's responsibility to ensure that it holds. The
> | compiler can't check it, but it is allowed to assume that it holds.
>
> This is simply a cheap cop-out. If a language gives programmers tools
> that affect fundamental invariants, it is flat out irresponsible if it
> does not give the programmers tools to ascertain that those invariants
> are not violated.
Let's get the compiler to check that the program halts while we're at
it, eh?
> | There are plenty of parallel situations in any programming language.
>
> True, but that is not a good reason to create more of them.
Why? Every powerful tool has the potential for misuse. Even the ones
in the CL standard.
> | You want to define < on lists to mean "shorter than"? Well, OK. At
> | least you'll agree it's a total ordering.
>
> I think I may have to find some neon-sign-like fonts and have the word
> "EXAMPLE" made out of it and then make it flash. Please get the point
> of the example, and drop the specifics of the example. They work just
> like analogies: At some point or another, they become irrelevant to the
> point being communicated.
Then I suggest you provide several examples, so that the point you're
trying to make can be abstracted out of them. Either that, or actually
*make* your point.
> In this case, I wanted to point out that there are convenience
> reasons to make certain things _equally_ hard. Adding a new
> method on < seems to be easy, but it is in fact extremely hard,
> because the programmer needs to keep the fundamental invariants
> of all the types involved intact, and that requires a lot more
> computer science than you get from example code in books on OO.
> In my view, real programmers will not _want_ to add a method on
> < for a user-defined types because it causes many more problems
> than it solves, and is actually much harder than writing
> type-specialized functions.
I think that where I lose you is when you want to draw an artificial
distinction between language implementors and language users.
After many years of professional programming, I find that the languages
I value the most are those in which there is the least possible
distinction between facilities provided by the language and those
provided by an experienced programmer working *within* the language.
This applies to uniformity of syntax, to generality, and to runtime
performance.
> | Dylan side-steps the issue of generic function dispatch on multiple
> | arguments, because < takes only two arguments in the first place. If
> | you want the CL operation then you need to use reduce().
>
> Huh? As far as I can see, the return value of the function will be
> used as one of its arguments for the next element in the sequence
> for reduce to work. (reduce #'< '(1 2 3)) would cause cause reduce
> to make the call equivalent to (< t 3). This is true for both both
> Common Lisp and Dylan, so I wonder what you had in mind.
Something like:
define method ascending(args :: <list>)
reduce(method (a, b) a & b end, #t,
map(\<, args, tail(args)))
end;
Not that that's the best way to do it -- using "every?" would be better,
and using a loop would be better still.
> | That depends on what type of work you're doing.
>
> No, that is backwards. Since we are talking about language design, it
> depends on what the language specification should require of the
> implementation, hence the "should". The language should not impose on
> the _application_ to make these kinds of type additions
> _unnecessarily_.
> It should also not impose on every application that does not need this
> infrastructure the cost of having it available. In a dynamically typed
> language, there are significant costs associated with the mere
> existence of user-defined methods on primitive mathematical function.
Since we are talking about language design, it is possible to add
"sealing" declarations to the portion of the GF that deals with built-in
types, in which case the existance of user defined methods on other
types has no effect on code that confines itself to built in types.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> So what would you suggest as the true mathematical implementation of <
> for complex numbers?
There is none! To be of any use, it should be a continuation of the
ordering of the reals, but there is - provably - no such thing.
So I think it is better, not to define '<' for complex numbers, lest
you would be surprised it you used it. And what, by the way, is the
use of an implementation defined '<'?
Andreas
--
Wherever I lay my .emacs, there�s my $HOME.
Andreas Eder <············@t-online.de> writes:
> Bruce Hoult <·····@hoult.org> writes:
>
> > So what would you suggest as the true mathematical implementation of <
> > for complex numbers?
>
> There is none! To be of any use, it should be a continuation of the
> ordering of the reals, but there is - provably - no such thing.
^^^^^^^^
Is there some topological constraint you're not telling us about?
What's wrong with a dictionary ordering?
--
Joe Schaefer
Joe Schaefer <··········@sunstarsys.com> writes:
> Andreas Eder <············@t-online.de> writes:
>
> > Bruce Hoult <·····@hoult.org> writes:
> >
> > > So what would you suggest as the true mathematical implementation of <
> > > for complex numbers?
> >
> > There is none! To be of any use, it should be a continuation of the
> > ordering of the reals, but there is - provably - no such thing.
> ^^^^^^^^
>
> Is there some topological constraint you're not telling us about?
> What's wrong with a dictionary ordering?
There are off course a lot of ways to define an order on the set of
complex numbers. But when mathematicians talk about ordering the
complex numbers, they mean an ordering consistent with the field
operations.
For a field F with operations + and . we want to find a set P (of
positive numbers) such that 1 (the multiplicative unity) is in P and
that whenever x and y are in P, so are x+y and x.y.
Then we can define an ordering for the field by defining x > y iff x-y
is in P.
There is no such set for the complex numbers.
--
Lieven Marchand <···@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
Lieven Marchand <···@wyrd.be> writes:
> Joe Schaefer <··········@sunstarsys.com> writes:
>
> > Andreas Eder <············@t-online.de> writes:
> >
> > > Bruce Hoult <·····@hoult.org> writes:
> > >
> > > > So what would you suggest as the true mathematical implementation of <
> > > > for complex numbers?
> > >
> > > There is none! To be of any use, it should be a continuation of the
> > > ordering of the reals, but there is - provably - no such thing.
> > ^^^^^^^^
> >
> > Is there some topological constraint you're not telling us about?
> > What's wrong with a dictionary ordering?
>
> There are off course a lot of ways to define an order on the set of
> complex numbers. But when mathematicians talk about ordering the
> complex numbers, they mean an ordering consistent with the field
> operations.
That's absurd in more ways than I could possibly hope to count.
Here I'll just stick to three:
1) There is no such animal (which I think we're all in agreement
about), and therefore I suspect mathematicians don't spend any
time talking about it at all.
2) Who said anything about mathematicians being the ultimate
arbiters of what is and isn't _useful_? Thank goodness math-
ematicians don't referee scientific publications: it took
*twenty years* for them to figure out what Dirac was talking
about; and they still haven't quite deciphered Feynman.
Under such regal auspices, Ed Witten would surely be better
off if he remained in journalism.
3) When mathematicians talk about anything, they try to flesh out
the universe of discourse *beforehand*. Retrofitting a ``natural''
category in order to promote a specious argument to the level of
proof is hardly how I'd want to describe mathematics, especially
when it's being discussed (off-topically) in an open forum like
this.
> For a field F with operations + and . we want to find a set P (of
> positive numbers) such that 1 (the multiplicative unity) is in P and
> that whenever x and y are in P, so are x+y and x.y. Then we can
> define an ordering for the field by defining x > y iff x-y is in P.
Most texts in financial mathematics start with a similar concept;
there F is a (topological) vector space over an ordered field with
a preference relation R on it, and your "." above is scalar
multiplication (P is called the positive cone of (F,R)). At least
3 Nobel prizes in economics in recent years were awarded to people
that pursued this branch of mathematics. Declaring it _useless_ to
employ the complex plane in such areas doesn't even pass the laugh
test; and AFAICT that is exactly the POV you are defending.
> There is no such set for the complex numbers.
And of course, the dictionary ordering is precisely what is used in
Perl. But the author of Math::Complex (a core package in the
perl distribution) did have the good sense to reserve a special
symbol for it, lest it confuse any stuffy algebraists out there who
might be foolish enough to actually use it in some sort of "proof".
--
Joe Schaefer
Clemens Heitzinger <········@rainbow.studorg.tuwien.ac.at> writes:
> Maybe it helps to think about the ordering problem as follows. When
> we talk about the complex numbers, we don't talk about RxR alone, but
> about C=(RxR,0,1,+,-,*,inv), i.e., we have a set plus the field
> operations defined on it. If we want to turn this into an ordered
> field (RxR,0,1,+,-,*,inv,<), it is obvious that we will require that <
> is compatible with the field operations. But no such ordering exists,
> and that's what we mean when we say that C can't be turned into an
> ordered field.
In fact, I wouldn't even represent C as equal to RxR. C has one point
at infinity and gets compactified as the Riemann sphere, whilst RxR
has a line at infinity and gets a projective space as
compactification.
--
Lieven Marchand <···@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
Lieven Marchand <···@wyrd.be> writes:
> Clemens Heitzinger <········@rainbow.studorg.tuwien.ac.at> writes:
>
> > Maybe it helps to think about the ordering problem as follows. When
> > we talk about the complex numbers, we don't talk about RxR alone, but
> > about C=(RxR,0,1,+,-,*,inv), i.e., we have a set plus the field
> > operations defined on it. If we want to turn this into an ordered
> > field (RxR,0,1,+,-,*,inv,<), it is obvious that we will require that <
> > is compatible with the field operations. But no such ordering exists,
> > and that's what we mean when we say that C can't be turned into an
> > ordered field.
>
> In fact, I wouldn't even represent C as equal to RxR. C has one point
> at infinity and gets compactified as the Riemann sphere, whilst RxR
> has a line at infinity and gets a projective space as
> compactification.
But then it's not C anymore, but rather ``C hat'', or ``CP^1''. Or do
you object whenever somebody says ``C is a field''?
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Joe Schaefer <··········@sunstarsys.com> writes:
> Andreas Eder <············@t-online.de> writes:
>
>> Bruce Hoult <·····@hoult.org> writes:
>>
>> > So what would you suggest as the true mathematical implementation
>> > of < for complex numbers?
>>
>> There is none! To be of any use, it should be a continuation of the
>> ordering of the reals, but there is - provably - no such thing.
> ^^^^^^^^
>
> Is there some topological constraint you're not telling us about?
> What's wrong with a dictionary ordering?
The proof (as shown by Clemens Heitzinger in a follow-up to this
posting) implies that you want the complex numbers (together with this
ordering and the usual operations) to be an ordered ring (like the
reals are). Everything else (i.e. an ordering that doesn't have a
meaningful connection to addition and multiplication) wouldn't make
much sense to a mathematician.
Edi.
···@agharta.de (Dr. Edmund Weitz) writes:
> Joe Schaefer <··········@sunstarsys.com> writes:
>
> > Andreas Eder <············@t-online.de> writes:
> >
> >> Bruce Hoult <·····@hoult.org> writes:
> >>
> >> > So what would you suggest as the true mathematical implementation
> >> > of < for complex numbers?
> >>
> >> There is none! To be of any use, it should be a continuation of the
> >> ordering of the reals, but there is - provably - no such thing.
> > ^^^^^^^^
> >
> > Is there some topological constraint you're not telling us about?
> > What's wrong with a dictionary ordering?
>
> The proof (as shown by Clemens Heitzinger in a follow-up to this
> posting) implies that you want the complex numbers (together with this
> ordering and the usual operations) to be an ordered ring (like the
> reals are). Everything else (i.e. an ordering that doesn't have a
> meaningful connection to addition and multiplication) wouldn't make
> much sense to a mathematician.
From this am I to conclude that mathematicians never discuss
complex numbers within the categories of ordered groups, vector
spaces over the reals, or simply as a product of two (ordered)
topological spaces?
Jordan and Brouwer might disagree with you about that.
--
Joe Schaefer
Joe Schaefer <··········@sunstarsys.com> writes:
> ···@agharta.de (Dr. Edmund Weitz) writes:
>
>> The proof (as shown by Clemens Heitzinger in a follow-up to this
>> posting) implies that you want the complex numbers (together with
>> this ordering and the usual operations) to be an ordered ring (like
>> the reals are). Everything else (i.e. an ordering that doesn't have
>> a meaningful connection to addition and multiplication) wouldn't
>> make much sense to a mathematician.
>
> From this am I to conclude that mathematicians never discuss complex
> numbers within the categories of ordered groups, vector spaces over
> the reals, or simply as a product of two (ordered) topological
> spaces?
>
> Jordan and Brouwer might disagree with you about that.
:)
I've been a mathematician for more than ten years and I know (having
dealt mainly with logic and set theory) that almost anything 'makes
sense' as long as you can base it on a consistent axiom system. My
posting was meant to further clarify Clemens Heitzinger's proof in the
context of the original question. I still think that an implementation
of < for complex numbers in any programming language would only 'make
sense' if it resulted in an ordered ring (and I think Jordan and
Brouwer would agree with that). No such ordering exists and this is
why (AFAIK) no programming language comes with an implementation of <
for complex numbers.
You're free to define any ordering of your liking if it fits your
special needs (i.e. if you want to work with ordered groups, vector
spaces over the reals or whatever) but it would be bad language design
IMHO if any such ordering would be presented as THE ordering of the
complex numbers to the programmer.
Best regards,
Edi.
···@agharta.de (Dr. Edmund Weitz) writes:
> :)
>
> I've been a mathematician for more than ten years and I know (having
> dealt mainly with logic and set theory) ...
Somehow I had a feeling about that :)
> My posting was meant to further clarify Clemens Heitzinger's proof in
> the context of the original question. I still think that an
> implementation of < for complex numbers in any programming language
> would only 'make sense' if it resulted in an ordered ring (and I think
> Jordan and Brouwer would agree with that). No such ordering exists and
> this is why (AFAIK) no programming language comes with an
> implementation of < for complex numbers.
Agreed. Thanks for the clarification.
--
Joe Schaefer
"Joe Schaefer" <··········@sunstarsys.com> wrote in message ···················@mumonkan.sunstarsys.com...
> Andreas Eder <············@t-online.de> writes:
>
> > Bruce Hoult <·····@hoult.org> writes:
> >
> > > So what would you suggest as the true mathematical implementation of <
> > > for complex numbers?
> >
> > There is none! To be of any use, it should be a continuation of the
> > ordering of the reals, but there is - provably - no such thing.
> ^^^^^^^^
>
> Is there some topological constraint you're not telling us about?
> What's wrong with a dictionary ordering?
The ordering < on the reals have these properties:
i) If a<b and c>0 then ac < bc
ii) If a<b and c<0 then ac > bc
Andreas is saying that you cannot have properties i) and ii) satisfied
if you demand that 0>-1.
Suppose namely that < is such an ordering. There is now two possibilities
either i>0 or i<0.
Case i>0
-----------
Property i) gives
0<i and i>0 => 0i <ii => 0<-1,
which contradict 0>-1
Case i<0
-----------
Property ii) gives
i<0 and i<0 => ii>0 => -1>0
which contradicts 0>-1.
--
Jens Axel S�gaard
In article <·························@dspool01.news.tele.dk>, "Jens
Axel S�gaard" <············@jasoegaard.dk> wrote:
> "Joe Schaefer" <··········@sunstarsys.com> wrote in message
> ···················@mumonkan.sunstarsys.com...
> > Andreas Eder <············@t-online.de> writes:
> >
> > > Bruce Hoult <·····@hoult.org> writes:
> > >
> > > > So what would you suggest as the true mathematical implementation
> > > > of <
> > > > for complex numbers?
> > >
> > > There is none! To be of any use, it should be a continuation of the
> > > ordering of the reals, but there is - provably - no such thing.
> > ^^^^^^^^
> >
> > Is there some topological constraint you're not telling us about?
> > What's wrong with a dictionary ordering?
>
> The ordering < on the reals have these properties:
>
> i) If a<b and c>0 then ac < bc
> ii) If a<b and c<0 then ac > bc
>
> Andreas is saying that you cannot have properties i) and ii) satisfied
> if you demand that 0>-1.
>
> Suppose namely that < is such an ordering. There is now two possibilities
> either i>0 or i<0.
No, there is a third possibility: i and 0 compare equal using "<"
e.g. you can define (a + bi) < (c + di) to be a < c.
For the purposes of computerized sorting & searching it may even be
reasonable to define:
(a + bi) < (c + di) =
a != c => a < c
a == c => b < d
i) If a<b and c>0 then ac < bc
ii) If a<b and c<0 then ac > bc
These will still hold, for real values of c. Which is all you need for
consistency with real arithmetic.
-- Bruce
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3215132108468905@naggum.net>
* Bruce Hoult <·····@hoult.org>
| No, there is a third possibility: i and 0 compare equal using "<"
|
| e.g. you can define (a + bi) < (c + di) to be a < c.
It may make sense to allow < to work on complex numbers whose imaginary
part is zero. Some implementations of complex numbers do not turn these
into or consider them reals, but for all relevant purposes, they are. If
this is the case, then specifying that < is implementation-dependent is
simply the wrong place to do it, because the implementation-dependency
lies in whether a complex number with a zero imaginary part _is_ a real.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
In article <··············@elgin.eder.de>, Andreas Eder
<············@t-online.de> wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > So what would you suggest as the true mathematical implementation of <
> > for complex numbers?
>
> There is none! To be of any use, it should be a continuation of the
> ordering of the reals, but there is - provably - no such thing.
> So I think it is better, not to define '<' for complex numbers, lest
> you would be surprised it you used it. And what, by the way, is the
> use of an implementation defined '<'?
It allows you to insert and find objects of that type in a library
collection that relies on a total ordering property, such as a sorted
list or an AVL-tree.
You might as well ask what is the use of an implementation-defined hash
key function.
-- Bruce
Frode Vatvedt Fjeld <······@acm.org> writes:
> I'm not saying if* is immoral. I find it anti-social, somewhat like a
> child refusing to wear clothes in public, unwilling to relinquish that
In fact, even mathematicians rely on established social norms in order
to prove theorems. Whether a proof is acceptable in its style and
level of detail or not is to a large extent a question about the
social norms of the mathematical community.
--
(espen)
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214858356435965@naggum.net>
* John Foderaro
| So the ANSI spec is out of this.
Your claim is that the standard if, when, and unless should not be used.
This is the crux of the matter, not if*. If they could be used freely,
then if* has no merit whatsoever. The only merit of if* is if it should
replace the standard conditionals. This is defintely your point, since
you are even telling people that code will be converted from standard to
Foderaro style if submitted to you, because you cannot, supposedly, read
standard code. Since you are quite hysterical about having your freedom
threatened in any way, please try to understand that you are threatening
the freedom of those who want to exercise their freedom to employ the
standard to its fullest. Apparently, you ignore this aspect of your if*
stunt completely, because you want to exercise _your_ freedom, and do not
give a flying fuck about others. That others have _repeatedly_ and very
strongly objected to your anti-standard attitude has never registered
with you as far as your lines of defense can provide information, because
you only talk about _your_ freedom to create new macros, never about the
freedom you seek to take away from those who like the standard. Those
who want the standard to be our common point of agreement are labeled
"religious" and worse things by you in your fight for if*. This is very
clear evidence that there is a fight between conflicting freedoms, here.
Now, this does not normally happen among freedom-loving people. It does
happen quite frequently among people who want to control others. I have
objected to your stupid, stupid if* stunt on the grounds that you forbid
if, when, unless, and (let us not forget) cond. You have not grasped it.
Now, we have a word for people who disregard other people's freedom and
rights and everything in their zeal to exercise their "freedom" to do
something that is frowned upon by other people because it curtails the
freedom of others. That word is: CRIMINAL.
The reason people object so strongly to what you do is that you have
abused the freedom you have to create macros and the like to create one
that you have married to a political agenda to destroy and deprecate the
standard conditionals, and the open source activity of Franz Inc looks
like it has no other purpose than to destroy the standard by creating a
community around that requires your if* stunt and your lower-case
nonsense to work, and which you ensure will _not_ work without changes to
the core Lisp system and patches will not be accepted back into the
source with standard conditionals or extended loop. Whether you accept
it or not, this is a pretty pathetic case of intimidation of those who
want to follow the standard, on par with the "religious" crap you do.
If you argue that people should accept your if* stunt because it is
within the limits of conformance to add new macros, why do you at the
same time argue that people should not use if, when, unless, cond, and
extended loop, which are _also_ within the limits of conformance? If I
say that people should not use if*, how the hell is that different from
_you_ saying they should not use if, when, unless, cond, etc? Why do you
invoke "relinquish our freedom" when I tell people not to use if*, but do
not even understand that you specifically want to order people around?
This does not make sense to me. In fact, it provides me with sufficient
information to suspect _seriously_ foul play. Why do you want to take
away other people's freedom to use the standard constructs? Do you not
_understand_ that this is what people object to in your very political
agenda? Why do you fight for if* based on _freedom_ when what you really
want is to control what other people can and should do? You _have_ told
us that you will even rewrite the code of your colleagues to remove the
standard conditionals. What kind of work environment does this create?
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
John Foderaro <···@xspammerx.franz.com> writes:
> There has never been any question that an otherwise ANSI
> compliant program using the if* macro along with the source for
> the if* macro results in a 100% ANSI compliant common lisp program.
Provided if* is included in the program. Otherwise, it is an ANSI-compliant
program fragment. It is really written in Allegro or whatever, which may
itself be complian.
People would think it misleading to merely say "I've written an
ANSI-compliant library that draws pie charts". I think you have to
add "and it's written in CLIM [or CAPI or GOMMON-GRAPHICS or
whatever]" or else you are being, at best, highly misleading. And
people *do* routinely make such disclaimers/disclosures.
| 1.5.2 Conforming Programs
|
| Code conforming with the requirements of this standard shall adhere
| to the following:
|
| Conforming code shall use only those features of the language syntax
| and semantics that are either specified in this standard or defined
| using the extension mechanisms specified in the standard.
Note that this does nto say "possible to define" but "defined".
Certainly nothing precludes such definition
| Conforming code may use implementation-dependent features and
| values, but shall not rely upon any particular interpretation of
| these features and values other than those that are discovered by
| the execution of code.
I think this allows you to do things like
#-Franz (load "franz-if")
*if* (pardon the abuse of if and *'s here) you provide the franz-if
library as part of or in conjunction with the program. If you simply
observe its existence, I think you're on shakier grounds for a conformance
claim unless you advertise that you have a program whose conformance
is contingent on the consumer of your product doing this.
| Conforming code shall not depend on the consequences of undefined or
| unspecified situations.
|
| Conforming code does not use any constructions that are prohibited
| by the standard.
|
| Conforming code does not depend on extensions included in an
| implementation.
I think this says that conformance does not happen by accident.
It happens by careful design to assure that the dependencies you create
are not left to be resolved by accidental use of a particular implementation
that agrees with your discretion, but are resolved by intentional and
explicit use of conforming code that bridges the gap between any (not just
a selected) processor and the program in question.
Certainly nothing precludes the packaging of this into separate libraries.
But if A is conforming and B depends on A to be conforming, then these are
conforming: A, B+A; and these are not, a priori, conforming: B.
====
Of further relevance is the following, from the Better Business Bureau's
"BBB Code of Advertising", which all members of the Better Business Bureau
(don't know if that's you)
| 20. Unassembled Merchandise
[By this, I assume they mean source code that has not been through a
compiler and assembler. Heh... No, really, I think source code *does*
count as a product that requires assembly in the classical business
sense. It does not work out of the box without special setup actions
required by the user. -kmp]
| When advertised merchandise requires partial or complete assembly by
| the purchaser, the advertising should disclose that fact, e.g.,
| "unassembled," "partial assembly required."
This is only a "for example" list, and I personally infer it to mean
"parts obtained from other sources required". I'd be VERY surprised
if the BBB complaint resolution division would think otherwise.
This follows from item 3 of their basic principles:
| 3. An advertisement as a whole may be misleading although every
| sentence separately considered is literally
| true. Misrepresentation may result not only from direct
| statements but by omitting or obscuring a material fact.
http://www.bbb.org/advertising/adcode.asp
I have the right to express my opinion, haven't I?
(I'll write a real reply not involving a ton of your strategies
tomorrow.)
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
John Foderaro <···@unspamx.franz.com> writes:
> In article <··············@asaka.latnet.lv>, ·····@latnet.lv says...
> >
> > And if it is not still clear, I think the if* macro is bad exactly for
> > the reason Erik speaks about -- complete disrespect for community.
> >
>
> I've got a few questions:
It is pretty funny you found this statament of my own opinion the only
thing worth discussing. (Oh, wait a minute -- you are not discussing
anything here, just pushing your ultimate point of view, aren't you?)
> 1. how many members of the community did you poll for their
> opinions before drawing this conclusion in their name?
Ok, I should have been more specific -- I was talking about Common
Lisp community not your community. Live in peace now because I'm not
invading your community.
Now a simple scenario: Imagine a person walking on the street,
spitting all around, eating something and dropping leftovors on the
street, bumping into people and not excusing (not to mention the
person is dirty and stinks). Now I tell you this person has no respect
for society. You feel very astonished and ask: how many members of the
society did you poll for their opinions before drawing this conclusion
in their name?
And now the answer to your question: None. Does it change the fact?
> 2. are you in favor of removing all macros from the Common Lisp
> language?
Oh how smart of you -- leaving me so many clever alternatives to me I
feel lost. Now which one should I choose? Oh, ok. I give up. Satisfied
now? Is that what you want?
> If the answer is no, then do you have a
> algorithm for determining if the use of a given macro
> shows disrespect for the Common Lisp community?
It has been told you _many_ times what the issue is. I guess it will
not help any bit to repeat it again here so I won't.
> If there is no algorithm would you advocate appointing
> a Pope of Common Lisp to decide if a given macro
> respects or disrespects the community?
Do you really think some kind of Pope is the only and true way to have
a judgement on things? I woudn't trust any Popes because all they do
is push religion on people, and the less people resist the better Pope
feels. This works only on people who accept the religion because they
are promised great things nobody has ever seen in afterlife. People
who think don't need any Popes to show them a way -- they are equipped
with everything they need to find it themselves -- a [working] brain.
Oh, maybe you mean: "If you can't find a Pope of Common Lisp I'll be
the authority meanwhile?" That would not surprise me.
No wonder you can't learn anything from what people tell you since you
have so hard time figuring out even such a simple thing as extended
loop. I know people are wasting time with you here, but maybe that's
because they feel that there is still hope in you?
And how about the use of single semicolon comments -- will we see a
description of their use in your "Coding Standards" any time soon?
I'm really interested to learn new things -- maybe the Common Lisp
community convention was wrong all the time until the John "if*"
Foderaro came along to teach us of "better" ways of doing things?
(I'm really sarcastc here so if you have nothing of substance to tell
then you are free to not reply.)
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214942272929982@naggum.net>
* Janis Dzerins
| Now a simple scenario: Imagine a person walking on the street, spitting
| all around, eating something and dropping leftovors on the street,
| bumping into people and not excusing (not to mention the person is dirty
| and stinks). Now I tell you this person has no respect for society. You
| feel very astonished and ask: how many members of the society did you
| poll for their opinions before drawing this conclusion in their name?
However, it _would_ be a likely question shot back from the derelict you
had just described, because the question itself shows disrespect for the
community, not to mention each offended individual. The question is only
an attempt to control critics of anti-social behavior by intimidation,
which is really the only way our perpetrator thought he could "win", but
you never really win by intimidation, you just get rid of the critics who
can be intimidated, which are those without substance to their criticism.
Suppose for a second it was an honest question: How many people need to
be "polled" to satisfy him? However many you ask, you would always find
a substantial number of other anti-social individuals if you took a poll
(just look at what happens when one anti-social bastard has been shot
down on USENET -- they come crawling out of the woodwork) such that the
anti-social can always claim that any critic never had the full force of
the community come down on them? In other words, it is a pretty stupid
way to intimidate people -- better use an intimidation technique without
inherent contradictions, so it at least looks legit. Even the stupid
"prove things" stunt rests on people taking things for granted that
should not be -- and watch how he ran out of arguments immediately when
that line of intimidation was challenged, and tried stupidly to argue
that someone had challenged all of science. I only wish such people were
a lot smarter about what they do, but stupid intimidation and anti-social
go hand in hand, however, so this is no surprise. Advanced and complex
social structures depend on really clever intimidation, such as having a
whole bunch of smart people sit down and define a standard that other
people feel obliged to accept as an authority. Smart people figure out
that this kind of authority makes a great deal of sense. Anti-social
people people reject any and all authority not of their own making, but
if they are really dumb, think that since it is based on intimidation in
a sense, they, too, can play the intimidation game. It really is quite
pathetic to watch, but most of the "fights" on USENET can probably be
summed up as "who died and elected _you_ the authority", just like our
perpetrator rambles about a Pope of Common Lisp. Watch out for people
who cannot accept any authority but themselves, they _will_ be trouble.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
On Fri, 16 Nov 2001 23:31:15 GMT, Erik Naggum wrote:
> perpetrator rambles about a Pope of Common Lisp. Watch out for people
> who cannot accept any authority but themselves, they _will_ be trouble.
Watch out for people who accept any authority but themselves; they
_are_ trouble. Only a fool accepts someone else's judgement above his
own.
--
Don't worry about people stealing your ideas. If your ideas are any good,
you'll have to ram them down people's throats.
-- Howard Aiken
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
Paul Foley <·······@actrix.gen.nz> writes:
> On Fri, 16 Nov 2001 23:31:15 GMT, Erik Naggum wrote:
>
> > perpetrator rambles about a Pope of Common Lisp. Watch out for people
> > who cannot accept any authority but themselves, they _will_ be trouble.
>
> Watch out for people who accept any authority but themselves; they
> _are_ trouble. Only a fool accepts someone else's judgement above
> his own.
That last sentance is patently absurd. "My doctor told me not do do
X, but I trust no judgement above my own; I don't see how X could be
harmful." :-P
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On 16 Nov 2001 20:20:14 -0800, Thomas F Burdick wrote:
> Paul Foley <·······@actrix.gen.nz> writes:
>> On Fri, 16 Nov 2001 23:31:15 GMT, Erik Naggum wrote:
>>
>> > perpetrator rambles about a Pope of Common Lisp. Watch out for people
>> > who cannot accept any authority but themselves, they _will_ be trouble.
>>
>> Watch out for people who accept any authority but themselves; they
>> _are_ trouble. Only a fool accepts someone else's judgement above
>> his own.
> That last sentance is patently absurd. "My doctor told me not do do
> X, but I trust no judgement above my own; I don't see how X could be
> harmful." :-P
Right. So ignore the doctor if you like. _You_ have to make the
judgement about whether or not you should trust the doctor, not just
say "Oh, well, he's a doctor, what do I know?" If you think he's
wrong, try another doctor. That's not absurd; claiming it's absurd is
the absurdity.
Do you think you[1] should be _required_ to followed the doctor's
recommendation? After all, only an anti-social criminal bastard would
refuse, right? :-)
[1] of course, "you" in this sentence is really code for "everyone but
you", since if you actually believed that _you'd_ do it anyway,
without any use of force.
--
C++ is a siren song. It *looks* like a HLL in which you ought to be able
to write an application, but it really isn't.
-- Alain Picard
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214959519738716@naggum.net>
* Paul Foley
| Watch out for people who accept any authority but themselves; they _are_
| trouble. Only a fool accepts someone else's judgement above his own.
There is no evidence of this problem anywhere on this planet as of yet,
but thank you for your warning to any visiting extra-terrestials.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
In article <··············@mycroft.actrix.gen.nz>, Paul Foley wrote:
>On Fri, 16 Nov 2001 23:31:15 GMT, Erik Naggum wrote:
>
>> perpetrator rambles about a Pope of Common Lisp. Watch out for people
>> who cannot accept any authority but themselves, they _will_ be trouble.
>
>Watch out for people who accept any authority but themselves; they
>_are_ trouble. Only a fool accepts someone else's judgement above his
>own.
If he a fool, he *ought* to accept the judgment of others, for
his own judgment is that of a fool!
But fools do not realize that, so they reject the judgment of others.
A wise man falls somewhere in between; he has an accurate view of the
limits of his own judgment and competence, and can recognize good judgment
and competence in others. He doesn't place a blind trust in either.
On Fri, 09 Nov 2001 21:14:57 GMT, "Coby Beck" <·····@mercury.bc.ca> wrote:
> I truly belive that Franz has a
>business plan similar to MS - gain marketshare --> dominate --> ignore
>community standards to damage competitors --> monopolize. This is not the only
>way to be successful in business.
Comparing Franz to Microsoft! This surely is a high point of my day.
(Picking myself off the floor...)
I guess Franz has not been quite as successful at implementing that strategy.
They've been around about as long.
In any case, this is not at all fair. The only thing those companies share,
in my opinion, is longevity, which is a tribute to both. Most of us would prefer
to see the market penetration difference between Franz and Microsoft diminish.
One way to help is to support Franz.
Regarding John Foderaro's work, I much appreciate that Allegroserve was
written and freely distributed with source. Chris Double ported it to Corman
Lisp. I know it took some time to port it, but I assume downloading the 49-line
IF* macro was the easiest part. Anybody who is objective about this would
clearly see that the value offered for free, by distributing Allegroserve and
the IF* macro, far exceeds the inconvenience of having to download them
separately. IF* is included with Corman Lisp now (thanks to John for putting it
in the public domain and encouraging vendors to include it).
Lisp is still here today, and will still be here when C++ is a historic
footnote, because it can evolve so easily. Just like English.
People in power, or the media, invent new words all the time. Nobody cares that
they aren't in the dictionary (which makes no claim to be authoritative). Nobody
says they are making up a new language. If all the smart people working in lisp
develop new macros, and we toss them into a package that all the vendors can
distribute, the language would probably benefit. The good ones would get used
more than the others, and provide obvious candidates for future standardization.
>What about 2(a). Do 2 and include the code for if* and any other logically
>significant macros and functions you use?
I agree wholeheartedly with this. It would only cost John about 5 minutes of
work, and would have saved each person who had to port Allegroserve at least 5
minutes to download it and insert it. Overall, probably a good 10 minutes more
productivity.
Yes--I am being somewhat sarcastic, but I still think including it makes sense.
It would save countless hours of debate on this newsgroup if nothing else.
Roger
From: Sam Steingold
Subject: (SETF ASSOC) was Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <u668jq1u7.fsf_-_@xchange.com>
> * In message <···············@shell01.TheWorld.com>
> * On the subject of "Re: MD5 in LISP and abstraction inversions"
> * Sent on Fri, 9 Nov 2001 16:51:44 GMT
> * Honorable Kent M Pitman <······@world.std.com> writes:
>
> SETF of ASSOC
could you please elaborate?
--
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Someone has changed your life. Save? (y/n)
Sam Steingold <···@gnu.org> writes:
> > * In message <···············@shell01.TheWorld.com>
> > * On the subject of "Re: MD5 in LISP and abstraction inversions"
> > * Sent on Fri, 9 Nov 2001 16:51:44 GMT
> > * Honorable Kent M Pitman <······@world.std.com> writes:
> >
> > SETF of ASSOC
>
> could you please elaborate?
I was just giving an example of a function one might want to redefine.
One is not allowed to extend definitions of CL symbols, so you have to
shadow them. I did this for ASSOC. It's not extraordinarily useful
in practice, but people often ask why it's not there since the PLIST
setters are present, so I figured why not add it. It is, by the way,
an annoying pain to write correctly if you DO want it:
(setq x '()) => ()
(setf (assoc 'a x) (cons 'a 4)) => (a . 4)
x => ((a . 4))
(setf (assoc 'a x) (cons 'a 5)) => (a . 5)
x => ((a . 5))
(setf (assoc 'a x) (cons 'b 1)) => (b . 1)
x => ((b . 1) (a . 5))
I also add the more useful functions, like this one:
(association 'a x) => 5
(setf (association 'a x) 6) => 6
(association 'a x) => 6
x => ((b . 1) (a . 6))
(setf (association 'c x) 0) => 0
x => ((c . 0) (b . 1) (a . 6))
(decf (association 'c x) 3) => -3
x => ((c . -3) (b . 1) (a . 6))
Getting the value and not the cell makes things like INCF/DECF more useful.
I have functions for the other-style ALIST, too. But then, the point
is that I spent a bit over six months full-time just writing all kinds
of support for things I was tired of not having... (So you'll forgive
me if I don't just post the lot of it on some free software site, btw;
I've burned through that many months' salary worth of savings and credit
card buildup, and now have to figure out how to make some money back on
all that investment. I promise it's not all as trivial as SETF of ASSOC,
though...)
Anyway, is that what you wanted to know?
From: Sam Steingold
Subject: Re: (SETF ASSOC) was Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <uitcjocaa.fsf@xchange.com>
> * In message <···············@shell01.TheWorld.com>
> * On the subject of "Re: (SETF ASSOC) was Re: MD5 in LISP and abstraction inversions"
> * Sent on Fri, 9 Nov 2001 21:08:52 GMT
> * Honorable Kent M Pitman <······@world.std.com> writes:
>
> Sam Steingold <···@gnu.org> writes:
> > > SETF of ASSOC
> > could you please elaborate?
>
> I was just giving an example of a function one might want to redefine.
> One is not allowed to extend definitions of CL symbols, so you have to
> shadow them. I did this for ASSOC. It's not extraordinarily useful
> in practice, but people often ask why it's not there since the PLIST
> setters are present, so I figured why not add it. It is, by the way,
> an annoying pain to write correctly if you DO want it:
>
> (setq x '()) => ()
> (setf (assoc 'a x) (cons 'a 4)) => (a . 4)
> x => ((a . 4))
> (setf (assoc 'a x) (cons 'a 5)) => (a . 5)
> x => ((a . 5))
> (setf (assoc 'a x) (cons 'b 1)) => (b . 1)
> x => ((b . 1) (a . 5))
this last looks weird to me.
I would expect an error.
> I also add the more useful functions, like this one:
>
> (association 'a x) => 5
> (setf (association 'a x) 6) => 6
> (association 'a x) => 6
> x => ((b . 1) (a . 6))
> (setf (association 'c x) 0) => 0
> x => ((c . 0) (b . 1) (a . 6))
> (decf (association 'c x) 3) => -3
> x => ((c . -3) (b . 1) (a . 6))
>
> Getting the value and not the cell makes things like INCF/DECF more useful.
this looks more natural to me.
do you mind if something like this finds its way into CLISP and/or CLOCC?
> I have functions for the other-style ALIST, too.
what's that? "RASSOC"?
> (So you'll forgive me if I don't just post the lot of it on some free
> software site, btw; I've burned through that many months' salary worth
> of savings and credit card buildup, and now have to figure out how to
> make some money back on all that investment. I promise it's not all
> as trivial as SETF of ASSOC, though...)
Sure. Your freedom is yours, and I quite understand you.
Good luck with your company.
(You are aware that you _can_ use CLISP commercially, aren't you?
Paul Graham did!)
> Anyway, is that what you wanted to know?
yep.
thanks.
--
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
The only time you have too much fuel is when you're on fire.
Sam Steingold <···@gnu.org> writes:
> > * In message <···············@shell01.TheWorld.com>
> > * On the subject of "Re: (SETF ASSOC) was Re: MD5 in LISP and abstraction inversions"
> > * Sent on Fri, 9 Nov 2001 21:08:52 GMT
> > * Honorable Kent M Pitman <······@world.std.com> writes:
> >
> > Sam Steingold <···@gnu.org> writes:
> > > > SETF of ASSOC
> > > could you please elaborate?
> >
> > I was just giving an example of a function one might want to redefine.
> > One is not allowed to extend definitions of CL symbols, so you have to
> > shadow them. I did this for ASSOC. It's not extraordinarily useful
> > in practice, but people often ask why it's not there since the PLIST
> > setters are present, so I figured why not add it. It is, by the way,
> > an annoying pain to write correctly if you DO want it:
> >
> > (setq x '()) => ()
> > (setf (assoc 'a x) (cons 'a 4)) => (a . 4)
> > x => ((a . 4))
> > (setf (assoc 'a x) (cons 'a 5)) => (a . 5)
> > x => ((a . 5))
> > (setf (assoc 'a x) (cons 'b 1)) => (b . 1)
> > x => ((b . 1) (a . 5))
>
> this last looks weird to me.
> I would expect an error.
I wrote it here by hand, didn't paste it in. Yes, it signals an
error. I meant (setf (assoc 'b x) (cons 'b 1)). Sorry.
In fact, the code error-checks for this specific case--you can only
set a value whose car is the indicator. [Just noticed a bug, tho; I
use EQ for the test, but obviously should use the supplied test. I'll
fix that...]
> > I also add the more useful functions, like this one:
> >
> > (association 'a x) => 5
> > (setf (association 'a x) 6) => 6
> > (association 'a x) => 6
> > x => ((b . 1) (a . 6))
> > (setf (association 'c x) 0) => 0
> > x => ((c . 0) (b . 1) (a . 6))
> > (decf (association 'c x) 3) => -3
> > x => ((c . -3) (b . 1) (a . 6))
> >
> > Getting the value and not the cell makes things like INCF/DECF more useful.
>
> this looks more natural to me.
> do you mind if something like this finds its way into CLISP and/or CLOCC?
Not really. One can't copyright ideas, and it probably isn't even my
idea. But you might want to wait until I post my list.
I hope to separate the issue of "spec" from the issue of "implementation".
> > I have functions for the other-style ALIST, too.
>
> what's that? "RASSOC"?
No, I meant the dot-free alists a lot of people use.
(alist-ref '((a 1) (b 2)) 'a) => 1
[I turned the args around because all my ref functions take
aggregate first and index-object second.]
> > (So you'll forgive me if I don't just post the lot of it on some free
> > software site, btw; I've burned through that many months' salary worth
> > of savings and credit card buildup, and now have to figure out how to
> > make some money back on all that investment. I promise it's not all
> > as trivial as SETF of ASSOC, though...)
>
> Sure. Your freedom is yours, and I quite understand you.
> Good luck with your company.
> (You are aware that you _can_ use CLISP commercially, aren't you?
> Paul Graham did!)
(Yes, I'm aware. :-)
Kent M Pitman <······@world.std.com> writes:
> Sam Steingold <···@gnu.org> writes:
>
> > > * In message <···············@shell01.TheWorld.com>
> > > * On the subject of "Re: MD5 in LISP and abstraction inversions"
> > > * Sent on Fri, 9 Nov 2001 16:51:44 GMT
> > > * Honorable Kent M Pitman <······@world.std.com> writes:
> > >
> > > SETF of ASSOC
> >
> > could you please elaborate?
>
> I was just giving an example of a function one might want to redefine.
> One is not allowed to extend definitions of CL symbols, so you have to
> shadow them. I did this for ASSOC. It's not extraordinarily useful
> in practice, but people often ask why it's not there since the PLIST
> setters are present, so I figured why not add it. It is, by the way,
> an annoying pain to write correctly if you DO want it:
No kidding. I tried to write it once, and decided that it was too
high of a pain-to-usefulness ratio.
> (setq x '()) => ()
> (setf (assoc 'a x) (cons 'a 4)) => (a . 4)
> x => ((a . 4))
> (setf (assoc 'a x) (cons 'a 5)) => (a . 5)
> x => ((a . 5))
> (setf (assoc 'a x) (cons 'b 1)) => (b . 1)
> x => ((b . 1) (a . 5))
Particularly for something like this (I know you fixed the example
later). Should the last x have been
((b . 1) (a . 5))
or
((b . 1))
or have signaled an error, or what? I figured that if the rest of the
lisp world was getting along fine without it, I could too.
> I also add the more useful functions, like this one:
>
> (association 'a x) => 5
> (setf (association 'a x) 6) => 6
> (association 'a x) => 6
> x => ((b . 1) (a . 6))
> (setf (association 'c x) 0) => 0
> x => ((c . 0) (b . 1) (a . 6))
> (decf (association 'c x) 3) => -3
> x => ((c . -3) (b . 1) (a . 6))
>
> Getting the value and not the cell makes things like INCF/DECF more useful.
Oooh, yes, this is one of my favorites. I was so happy when I got it
to work (though I think your name is a lot better than the assocd I
chose)
> I have functions for the other-style ALIST, too. But then, the point
> is that I spent a bit over six months full-time just writing all kinds
> of support for things I was tired of not having... (So you'll forgive
> me if I don't just post the lot of it on some free software site, btw;
> I've burned through that many months' salary worth of savings and credit
> card buildup, and now have to figure out how to make some money back on
> all that investment. I promise it's not all as trivial as SETF of ASSOC,
> though...)
If you spent 6 months on it, I'd hope not ;-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3213742805450255@naggum.net>
* Francois-Rene Rideau
| With such an attitude, I think it is useless for you to wonder why
| people do not ask you anything.
I see. You think this all a game of insulting eachother the most.
| > | [Skipped ad-hominem attacks]
| > Well, gee, your own are apparently OK, while you have a problem with
| > mine. That kind of double standard _really_ annoys me.
| I have tried hard not to make any such attack in the current thread.
| I apologize if there is anything that could be construed as such in
| my messages.
Oh, for crying out loud, please quit the pathetic lying, you numbnut.
| If you are only ready to help people better than yourself,
Geez. Where did _this_ crap come from, numbnut?
| you'll find that the only people whom you accept to help are those who
| don't need your help.
Precisely. People who _need_ help should not get it for free. They
should pay for it. In an exchange of helpfulness where each party gives
help for free, the only "payment" one may get is that of having saved
someone else a little time who might save oneself a little time later on
in return. If you help people who _need_ to be helped, you do them a
major disservice -- you rob them of their only opportunity to learn by
working through some problem, you make them jump further than they should
and then they fill in the gaps with guesswork and assumptions that take a
lot of time to untangle, and they will keep asking for the same kind of
help over and over. Like that "ab talebi" numbnut.
| You seem to me to react like you take perfection as a granted ideal
| such that ethical behaviour consists in destroying whatever is imperfect.
Wrong. Striving for perfection I do take for granted. There are people
who do not want this and who strive for imperfection, instead.
| I think that that on the contrary, perfection is an unreached ideal
| such that ethical behaviour consists in building more perfect things.
You are too unware of your thinking processes to realize how it is _you_
who fail to live up to this.
| I do not feel "betrayed" - nobody owes me anything.
_Really_? Who do you think you are kidding? If the language is flawed
and other people should implement the things you "want", you spell it out
as betrayal and being owed something. It is pretty damn obvious.
| I feel like there is a room for improvement,
Yeah, right. "Flawed" means it is unusable as is, which you are also
quite explicit saying. "Improvement" means it is usable now and could be
more usable. The latter is _not_ your position.
| Whereas you are only very rude and quick to ignore or dismiss arguments
| (rather than actually attack them) once you decided that someone was a
| bad person.
Wrong, but you are both a bad person and incredibly unaware of your
thinking processes, so your arguments are also utter bunk.
| Indeed, if I manage to avoid characters altogether (and thus not use any
| character-based library), or else use non-portable extensions (and lose
| some interoperability) I can avoid double-buffering. This is a worthwhile
| engineering tradeoff to consider. But I argue that this is a current flaw
| in the language.
You keep saying that, and refuse to back it up with anything that has
been requested of you. I find this interesting. You also managed to
answer almost every paragraph in what I wrote, _except_ this one:
So if I understand you right, you think it is perfectly OK for a vendor
to use internal, implementation-specific features to implement a common
or standard specification (or, in case you are not quite up that level of
quality, just fix things your way), that is perfectly OK, but if you do
it yourself, it is _not_ OK? Just _why_ is it that you cannot do this
yourself? What makes it so important to you that somebody else do the
dirty work that you do not want to do yourself?
Why did you not respond this? Would it be too revealing if you did?
| I didn't say you did. I tried to clarify and argue my opinion, which from
| your post I construed to be opposite to yours.
Oh, cut the crap! What is an "opposite opinion"? Are you really such a
numbnut that you cannot even see that there are many axes along which to
construe opposite positions here? All I say is that your stupid line
about the language being flawed is a load of crap and that your use of
characters in the MD5 algorithm is fantastically misguided, so you just
_have_ to run into problems, which you blame on the language instead of
your sorry excuse for a brain and your own incompetence at your task.
| I do not want to access implementation-dependent aspects of the
| character. I want to access protocol-dependent aspects of the character,
| in an implementation-independent way.
Numbnut.
| Sometimes, the protocol and the implementation agree, and then I like to
| be able to take advantage of it; sometimes they do not, and I find it a
| pity that it makes reuse of code designed to manipulate characters a
| nuisance.
So use the _bytes_, you insufferable numbnut.
| I know many flaws in my code (it notably does much more consing ...
Oh, christ! Are you really so stupid? Do you not even understand that
the issue here is the character type you complain about? Do you again
think that there is only one axis along which to move from worse to
better? How annoyingly stupid is it possible for somebody to be? Geez,
some people! Look, numbnut, it is your attitude that your use of the
character type for something it is clearly not suited for is perfect and
that the language is flawed because your code certainly cannot take any
improvement that is the problem, here. Your code is bogus, crappy, a
load of shit, a misconceptualization, an abstraction inversion, what have
you, and you are too incredibly incompetent to realize it. That is all.
| Well, the fact that something implementation-dependent has to be done for
| efficiency is precisely what an "abstraction inversion" is about when you
| try to do it portably.
Efficiency _is_ implementation-dependent, you insufferable numbnut.
| I argue it's a flaw in a language;
Yeah, you and that other doofus, whatshisname tail-call "elimination",
think the language is flawed because you numbnuts cannot figure out how
to write better code and have deeply rooted psychological problems with
doing what it takes to get what you want.
| A lot of useful code is written in LISP, C, C++, Java, OCAML, SML,
| Python, Perl, etc., that is written in a portable way and provide
| portable interfaces efficiently.
This is really, _really_ wrong, numbnut. These languages are only
portable across a very specific platform type: 32-bit machines. Give
them something else and they are no longer "portable" at all. Of course,
_you_ live in a world of only 32-bit hardware, but Common Lisp does not.
| Indeed. *Having to do it* is the wrong, and *doing it* is the right that
| hopefully fixes that wrong.
You do not _have_to_ do it, you numbnut. You choose to do it because you
want better efficiency, and you choose to do it your way because you are
incompetent and much too arrogant.
| > Have you ever wondered how all these implementations sprung into
| > being from nowhere when people like you do not want to implement
| > things they say they want?
| Uh? My post was precisely about code I was publishing.
Grow a brain, numbnut. Lots of people have done lots of implemenation-
specific work to make the world of supremely usable _portable_ Common
Lisp possible for you to complain about.
| I admit I should be back to coding -- wasted more than enough time
| posting on USENET.
Another stupid choice of yours.
| > It is not a question of picking one implementation and sticking with it,
| > but of actually using an implementation to get what you want.
| Maybe you should explain the difference.
Oh, please do not play worse of an idiot than you are! You can use
multiple implementations to their fullest without choosing one and
stikcing with it. How hard can this be to grasp, numbnut?
| > interface that does not expose the implementation-dependent features
| In the case of modular integers that's easy.
| In the case of doing the Right Thing(tm) with characters, that's difficult.
You are only seriously confused about what the Right Thing is, numbnut.
| For other flaws in CL (modularity, concurrency, etc.),
| I doubt it is possible.
Of course you do. You cannot even get simple type choices right.
| > You seem to believe that as soon as it is necessary to do something
| > like this, you have found a flaw in the language.
| Yes. It might not be a big flaw (depending on what it is),
| but it is a flaw nonetheless.
The flaw is located in your pathetic excuse for a brain, numbnut. It is
not in the language.
| In as much as I might not always be precise enough in what I say,
| you read everything with negative prejudice and then become rude.
A numbnut who resorts to "always", "never", "nothing" and "everything"
has lost his touch with reality and prefers a vastly simplified, hugely
exaggerated world which is much simpler for this limited brain capacity
to deal with. You are _obviously_ wrong. Stupid exaggerations always
are. I am rude to idiots, numbnuts, and arrogant ignorants like you.
| It's still a flaw.
Are you going to put that on yout tombstone when you leave us alone? It
seems that numbnuts like you who have to defend themselves when they are
wrong about something will go into a mental state where they will never
admit to being wrong and will continue to spout some idiotic nonsense
just to keep from admitting it. This seems to be a pretty common trait
in the entire "tunes" project, by the way.
Some people want so badly to be "right" that they never change their mind
once they have found something to believe and it is challenged. You are
of that type, it seems. Other people want so badly to be _right_ that
they change their mind as soon as what they believe is challenged and
proven wrong. Since you do not recognize that I am of that type, but
think I am just as stupid and narrow-minded as yourself, you have missed
every opportunity to learn from what I have told you, and that makes you
a fucking numbnut. Now, go away and keep believing your wrong things so
you can save face of whatever you numbnut types need to keep smiling.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
In article <················@naggum.net>, ····@naggum.net says...
[multiple insults]
While I may not agree with Francois-Rene Rideau's statements,
he definitely know how to argue his points like an adult.
Your response is childish however and is an embarrassment
to this forum.
Why do I even bring this up? Well I asked readers a
month or so ago that if they wanted to raise the
intellectual level of this forum that they should
speak up when something clearly anti-intellectual was
posted. Since this is not a moderated forum this is
the only way for posters to get feedback. Feedback
is important.
So I simply state that in my opinion that post
went overboard. Yes, this isn't the first such
post in the last month but I've been too busy lately
to stay current enough with this newsgroup to
give timely feedback on some of the other posts.
In article <··························@news.dnai.com>, John Foderaro wrote:
> In article <················@naggum.net>, ····@naggum.net says...
> [multiple insults]
>
>
> While I may not agree with Francois-Rene Rideau's statements,
> he definitely know how to argue his points like an adult.
>
> Your response is childish however and is an embarrassment
> to this forum.
>
> Why do I even bring this up? Well I asked readers a
> month or so ago that if they wanted to raise the
> intellectual level of this forum that they should
> speak up when something clearly anti-intellectual was
> posted. Since this is not a moderated forum this is
> the only way for posters to get feedback. Feedback
> is important.
>
> So I simply state that in my opinion that post
> went overboard. Yes, this isn't the first such
> post in the last month but I've been too busy lately
> to stay current enough with this newsgroup to
> give timely feedback on some of the other posts.
>
>
>
I have one question, when were you elected the group censor? I did
not vote for you or even see a ballot with your name on it.
If you have been reading this news group for a while one thing you
should relize by now is that Erik follows through. I do not know if
Erik will respond to this, but if he does he will finish it. I do not
think you will get your desired end you will not muzzle anybody who is
worth a dam with this junk. In fact this is an invatation to a
responce from Erik that you are preaching against. Then you will
respond and he will respond ... and you have a lot more of the
behavior that you preach against because of your direct action. This
is not what I consider smart. It almost looks like you are setting
your self up to set your self up as the innocent victim in this so you
can claim some false moral high ground in this.
In the worse case when you have a choice between assholes and censors
you should always choose assholes, they make better neighbors. I am
not saying Erik is an asshole, just to be clear.
marc
In article <···················@oscar.eng.cv.net>, ····@oscar.eng.cv.net says...
> I have one question, when were you elected the group censor? I did
> not vote for you or even see a ballot with your name on it.
If you study how usenet works you'll learn that there are no
censors for an unmoderated newsgroup so your statement makes
no sense.
I'm sure that there exist postings that you would consider
unacceptable. For example someone might start posting
multi-megabyte CMU CL distributions. You might speak up
and say "hey, this is not the place for that kind of
posting". You would not be a censor. Nothing you could do
could stop the postings. You would merely be stating your opinion.
*Your* opinion is that I should not state my opinion about
posts I find juvenile. Fine. I accept that is your opinion.
Just don't bring up censorship. That makes no sense.
In article <··························@news.dnai.com>, John Foderaro wrote:
> In article <···················@oscar.eng.cv.net>, ····@oscar.eng.cv.net says...
>> I have one question, when were you elected the group censor? I did
>> not vote for you or even see a ballot with your name on it.
>
> If you study how usenet works you'll learn that there are no
> censors for an unmoderated newsgroup so your statement makes
> no sense.
then why did you attempt to set your self up as a tin pot censor with
your moralistic garbage post? And you were trying to censor through
the applacation of social pressure. By posting your message you were
fisshing for support and trying to polarize comp.lang.lisp into the
"good guys" and the "bad guys", and you get to "lead" the "good guys"
against the "bad guys" in a moral crusade to cleans CLL, for the
greater good of course. And trying this tactic against Erik is just
moronic, yes this goes beyond stupid, unless you are just picking a
fight so you can form your group and chastise us offensive heathens
into line. That is still pretty stupid.
>
> I'm sure that there exist postings that you would consider
> unacceptable. For example someone might start posting
> multi-megabyte CMU CL distributions. You might speak up
> and say "hey, this is not the place for that kind of
> posting". You would not be a censor. Nothing you could do
> could stop the postings. You would merely be stating your opinion.
>
binaries go against the charter of this grouo, as far as I know
anyway and responces to posted messages do not. Again you amaze me
with your wonderful ability to compair apples to dog dropping. I am
sure *you* see the link, wether it is there or not.
> *Your* opinion is that I should not state my opinion about
> posts I find juvenile. Fine. I accept that is your opinion.
> Just don't bring up censorship. That makes no sense.
>
no my opinion is that I do not like assocating with liars and cheats
so will you please go away. If anybody is curious here is the archive
from google( sorry about the line break):
http://groups.google.com/groups?q=g:thl1251669294d&hl=en&selm=
87itf1a2fh.fsf_-_%40piracy.red-bean.com
marc
In article <···················@oscar.eng.cv.net>,
····@oscar.eng.cv.net (Marc Spitzer) wrote:
>then why did you attempt to set your self up as a tin pot censor with
>your moralistic garbage post?
You don't understand what the word "censor" means. A censor has the
power to edit, or prevent the publication of something he doesn't
approve of. John Foderaro has no such power, that's why he's telling you
that talk of "censorship" makes no sense. He's only expressing his
views. He thinks people should be less abusive. That's his opinion, but
it has no binding force, so it can't possibly be considered "censorship."
In article <···················@oscar.eng.cv.net>,
····@oscar.eng.cv.net (Marc Spitzer) wrote:
>In the worse case when you have a choice between assholes and censors
>you should always choose assholes, they make better neighbors. I am
>not saying Erik is an asshole, just to be clear.
Well this is damning with faint praise if I ever saw it.
Raf
--
Raffael Cavallaro, Ph.D.
·······@mediaone.net
Well I have been looking at this since yesterday trying to figure out
a properly designed responce to this deliberate edit for content of
what I said
In article <·····························@lrnws01.ne.mediaone.net>,
Raffael Cavallaro wrote:
> In article <···················@oscar.eng.cv.net>,
> ····@oscar.eng.cv.net (Marc Spitzer) wrote:
>
>>then why did you attempt to set your self up as a tin pot censor with
>>your moralistic garbage post?
>
> You don't understand what the word "censor" means. A censor has the
> power to edit, or prevent the publication of something he doesn't
> approve of. John Foderaro has no such power, that's why he's telling you
> that talk of "censorship" makes no sense. He's only expressing his
> views. He thinks people should be less abusive. That's his opinion, but
> it has no binding force, so it can't possibly be considered "censorship."
>
first "tin pot" when used as I did means not realy there, ie tin pot
dictator. This is the orignal unedited paragraph:
then why did you attempt to set your self up as a tin pot censor with
your moralistic garbage post? And you were trying to censor through
the applacation of social pressure. By posting your message you were
fisshing for support and trying to polarize comp.lang.lisp into the
"good guys" and the "bad guys", and you get to "lead" the "good guys"
against the "bad guys" in a moral crusade to cleans CLL, for the
greater good of course. And trying this tactic against Erik is just
moronic, yes this goes beyond stupid, unless you are just picking a
fight so you can form your group and chastise us offensive heathens
into line. That is still pretty stupid.
Now in this paragraph I think I did demonstrate a grasp of the fact
that John F. lacks the authority to be a "real" censor even though he
was trying to get there by other means. At least until you edited out
all the supporting text.
>
>
> In article <···················@oscar.eng.cv.net>,
> ····@oscar.eng.cv.net (Marc Spitzer) wrote:
>
>>In the worse case when you have a choice between assholes and censors
>>you should always choose assholes, they make better neighbors. I am
>>not saying Erik is an asshole, just to be clear.
>
> Well this is damning with faint praise if I ever saw it.
no That was just a statement of fact for the anti Erik club that is
all.
>
> Raf
>
> --
>
> Raffael Cavallaro, Ph.D.
> ·······@mediaone.net
Well now lets move on to some comments on the quality of your work
here. It realy is substandard in my opinion. Since you have a phd
according to your sig I can only assume you have some formal training
in using the written word to prove a point, your dissertation. Now
with all this training and experience, 4+ years, could you not do a
better job with this post of your? Could you not respond to the
points raised in the paragraph instead of just cutting them out as
something you did not have an answer for? You are trained to do so
much better then this. Why not use this training and raise the bar of
this discussion. At least in the future do better then an above
average college freashman. I much prefer discussing things, friendly
or otherwise, with people who make me work hard and learn to make and
defend my point. I prefer this for the simple reason that win, loose
or draw I will always learn something and/or improve some skill with
the exchange. This makes me a better educated person and I like
that.
marc
····@oscar.eng.cv.net (Marc Spitzer) wrote in message news:<····················@oscar.eng.cv.net>...
> Well I have been looking at this since yesterday trying to figure out
> a properly designed responce to this deliberate edit for content of
> what I said
Which is pretty clearly your way of saying that it took you a day come
up with a post that blithely ignores your original use of the word
"censor." But let's refresh your memory:
In article <···················@oscar.eng.cv.net>,
····@oscar.eng.cv.net (Marc Spitzer) wrote:
>I have one question, when were you elected the group censor? I did
>not vote for you or even see a ballot with your name on it.
No use of the colorful "tin-pot." You called John Foderaro a "censor."
Later, after he correctly stated that he was just expressing his
views, and not censoring anyone, you wrote a second post, in which you
called him a "tin-pot censor."
>Could you not respond to the points raised in the paragraph instead
>of just cutting them out as something you did not have an answer for?
Or even better still, just ingnore an entire post altogether. So much
easier than a "deliberate edit for content."
Raf
In article <····························@posting.google.com>,
Raffael Cavallaro wrote:
> ····@oscar.eng.cv.net (Marc Spitzer) wrote in message
> news:<····················@oscar.eng.cv.net>...
>> Well I have been looking at this since yesterday trying to figure out
>> a properly designed responce to this deliberate edit for content of
>> what I said
>
> Which is pretty clearly your way of saying that it took you a day come
> up with a post that blithely ignores your original use of the word
> "censor." But let's refresh your memory:
No I was kinda busy so I was thinking about it when I did my other
stuff and you are quoting a different post of mine, not the one we
were discussing. Now I am going to repost a chunk of the last post I
posted in this thread:
here is the mesage id: ····················@oscar.eng.cv.net
###start
In article <·····························@lrnws01.ne.mediaone.net>,
Raffael Cavallaro wrote:
> In article <···················@oscar.eng.cv.net>,
> ····@oscar.eng.cv.net (Marc Spitzer) wrote:
>
>>then why did you attempt to set your self up as a tin pot censor
with
>>your moralistic garbage post?
>
> You don't understand what the word "censor" means. A censor has the
> power to edit, or prevent the publication of something he doesn't
> approve of. John Foderaro has no such power, that's why he's telling
you
> that talk of "censorship" makes no sense. He's only expressing his
> views. He thinks people should be less abusive. That's his opinion,
but
> it has no binding force, so it can't possibly be considered
"censorship."
>
first "tin pot" when used as I did means not realy there, ie tin pot
dictator. This is the orignal unedited paragraph:
then why did you attempt to set your self up as a tin pot censor with
your moralistic garbage post? And you were trying to censor through
the applacation of social pressure. By posting your message you were
fisshing for support and trying to polarize comp.lang.lisp into the
"good guys" and the "bad guys", and you get to "lead" the "good guys"
against the "bad guys" in a moral crusade to cleans CLL, for the
greater good of course. And trying this tactic against Erik is just
moronic, yes this goes beyond stupid, unless you are just picking a
fight so you can form your group and chastise us offensive heathens
into line. That is still pretty stupid.
Now in this paragraph I think I did demonstrate a grasp of the fact
that John F. lacks the authority to be a "real" censor even though he
was trying to get there by other means. At least until you edited out
all the supporting text.
###end
so that is where tin-pot came from, for the purposes of this
discussion, you brought it in by quoting an old post of mine. I realy
have to hand it to you. You are putting me in my place with your well
formed arguments and your perfect grasp of logic.
>
> In article <···················@oscar.eng.cv.net>,
> ····@oscar.eng.cv.net (Marc Spitzer) wrote:
>
>>I have one question, when were you elected the group censor? I did
>>not vote for you or even see a ballot with your name on it.
>
> No use of the colorful "tin-pot." You called John Foderaro a "censor."
> Later, after he correctly stated that he was just expressing his
> views, and not censoring anyone, you wrote a second post, in which you
> called him a "tin-pot censor."
>
no I did not, I posed a question to him because he was acting as if he
was granted some kind of licence to behave as some kind of censor.
eather through some real licence or grant or as voice of some kind of
"moral force". In previous posts John F. got caught making clames
that were not true. Because of this repeated moralless behavior on
his part I have much less tolerance for him then I would have for
someone who has not *earned* such a reputation. I am old fashioned, I
considder dishonesty a choice not a mistake. And I have acted as I
feel proper in responce to John F.'s choice to be a dishonest person.
I am not making any comment on his code just his choices.
>>Could you not respond to the points raised in the paragraph instead
>>of just cutting them out as something you did not have an answer for?
>
> Or even better still, just ingnore an entire post altogether. So much
> easier than a "deliberate edit for content."
>
> Raf
Now why should I be silent when you are engageing dishonest behavior
that could damage my reputation in this group? I am perfectly capable
of damaging my own reputatoin with out the help of some dishonest
asshole. The thing is I try not to, I try to do what I think is the
right thing. Now I have been wrong and have been mistaken and have
been held accountable by the people I have damaged unintentionally and
promptly appoligized where I agree the mistake was mine.
One question, if I may? Where did you get your PHD? based on your
skill arguing things it may be a place best avoided if I ever go back
to school for an advanced degree.
marc
Alright, enough's enough.
When you repeated the word censor after I'd explained clearly
that I couldn't do that, I realized that you either didn't have
the ability to reason or were just trying to make trouble,
so I didn't respond to your post.
I was amused by the hypocrisy in your letter when you ended it
with:
no my opinion is that I do not like associating with liars and cheats
so will you please go away. If anybody is curious here is the archive
from google( sorry about the line break):
Telling someone to leave (I.e never post again) is a priori censorship.
You hate censorship yet you practice it in a big way.
And the link you gave was totally irrelevant, it was some discussion
between Craig Brozefsky, Erik Naggum and Erann Gatt.
http://groups.google.com/groups?q=g:thl1251669294d&hl=en&selm=87itf1a2fh.fsf_-_%
40piracy.red-bean.com
But it was your recent libel that caused me to post:
>> In previous posts John F. got caught making clames
>> that were not true. Because of this repeated moralless behavior on
>> his part I have much less tolerance for him then I would have for
>> someone who has not *earned* such a reputation. I am old fashioned, I
>> considder dishonesty a choice not a mistake. And I have acted as I
>> feel proper in responce to John F.'s choice to be a dishonest person.
>> I am not making any comment on his code just his choices.
Ok I'm going to now ask you to back up that claim that I posted lies.
We will then see that *you* are the liar.
Go to groups.google.com and find the postings. Post the text
snippets here along with links to the whole articles.
And who is Marc Spitzer anyway? There seems to be no record of you
on the net before the year 2000. In the past Erik Naggum has
deceived the members of this newsgroup by posting under aliases
(one we know for sure about was something like "GI Gunmaker").
You come out of nowhere and make all these moralistic claims
while posting lies and hypocrisy to stir up trouble. This is the
same writing style used by Erik Naggum. I believe that you are either
another Naggum pseudonym or are posting messages on behalf of him.
But whatever you are, you've been given your assignment above.
You better get working.
In article <··························@news.dnai.com>, John Foderaro wrote:
> Alright, enough's enough.
> When you repeated the word censor after I'd explained clearly
> that I couldn't do that, I realized that you either didn't have
> the ability to reason or were just trying to make trouble,
> so I didn't respond to your post.
>
> I was amused by the hypocrisy in your letter when you ended it
> with:
>
> no my opinion is that I do not like associating with liars and cheats
> so will you please go away. If anybody is curious here is the archive
> from google( sorry about the line break):
>
> Telling someone to leave (I.e never post again) is a priori censorship.
> You hate censorship yet you practice it in a big way.
Yes I said that because you asked me what I want in the previous post
so I answered. Now this is different because in this case, you
hypocrite, I was responding to your direct request for that information
so what is your problem, asked and answered. And thank you for not
posting the artacle id or any attempt to accuratly identify the source
of the quote other then your good word. I may have got the link wrong
but at least I tried to be accurate, aparently you cant be bothered
with accuracy or even the atempt.
marc
>
> And the link you gave was totally irrelevant, it was some discussion
> between Craig Brozefsky, Erik Naggum and Erann Gatt.
>
>
> http://groups.google.com/groups?q=g:thl1251669294d&hl=en&selm=87itf1a2fh.fsf_-_%
> 40piracy.red-bean.com
>
>
>
> But it was your recent libel that caused me to post:
>
>>> In previous posts John F. got caught making clames
>>> that were not true. Because of this repeated moralless behavior on
>>> his part I have much less tolerance for him then I would have for
>>> someone who has not *earned* such a reputation. I am old fashioned, I
>>> considder dishonesty a choice not a mistake. And I have acted as I
>>> feel proper in responce to John F.'s choice to be a dishonest person.
>>> I am not making any comment on his code just his choices.
>
>
> Ok I'm going to now ask you to back up that claim that I posted lies.
> We will then see that *you* are the liar.
>
> Go to groups.google.com and find the postings. Post the text
> snippets here along with links to the whole articles.
>
>
>
>
> And who is Marc Spitzer anyway? There seems to be no record of you
> on the net before the year 2000. In the past Erik Naggum has
> deceived the members of this newsgroup by posting under aliases
> (one we know for sure about was something like "GI Gunmaker").
> You come out of nowhere and make all these moralistic claims
> while posting lies and hypocrisy to stir up trouble. This is the
> same writing style used by Erik Naggum. I believe that you are either
> another Naggum pseudonym or are posting messages on behalf of him.
>
> But whatever you are, you've been given your assignment above.
> You better get working.
>
In article <··················@oscar.eng.cv.net>, Marc Spitzer wrote:
> In article <··························@news.dnai.com>, John Foderaro wrote:
>> Alright, enough's enough.
>> When you repeated the word censor after I'd explained clearly
>> that I couldn't do that, I realized that you either didn't have
>> the ability to reason or were just trying to make trouble,
>> so I didn't respond to your post.
>>
>> I was amused by the hypocrisy in your letter when you ended it
>> with:
>>
>> no my opinion is that I do not like associating with liars and cheats
>> so will you please go away. If anybody is curious here is the archive
>> from google( sorry about the line break):
>>
>> Telling someone to leave (I.e never post again) is a priori censorship.
>> You hate censorship yet you practice it in a big way.
>
> Yes I said that because you asked me what I want in the previous post
> so I answered. Now this is different because in this case, you
> hypocrite, I was responding to your direct request for that information
> so what is your problem, asked and answered. And thank you for not
> posting the artacle id or any attempt to accuratly identify the source
> of the quote other then your good word. I may have got the link wrong
> but at least I tried to be accurate, aparently you cant be bothered
> with accuracy or even the atempt.
>
> marc
I misstated it was not a reply to a question of yours, but a
correction of what you said my oppinion was:
###start quote
Message-ID: <···················@oscar.eng.cv.net>
> *Your* opinion is that I should not state my opinion about
> posts I find juvenile. Fine. I accept that is your opinion.
> Just don't bring up censorship. That makes no sense.
>
no my opinion is that I do not like assocating with liars and cheats
so will you please go away. If anybody is curious here is the archive
from google( sorry about the line break):
http://groups.google.com/groups?q=g:thl1251669294d&hl=en&selm=
87itf1a2fh.fsf_-_%40piracy.red-bean.com
###end quote
We start our chat at around article
Message-ID: <···················@oscar.eng.cv.net>
(this is around 40 posts into the thread)
so my orignal post was accurate. I took you at your word, my mistake
sorry.
marc
In article <··················@oscar.eng.cv.net>, ····@oscar.eng.cv.net says...
>> Yes I said that because you asked me what I want in the previous post
>> so I answered. Now this is different because in this case, you
>> hypocrite, I was responding to your direct request for that information
>> so what is your problem, asked and answered. And thank you for not
You're digging yourself in deeper and deeper.
First, here's the link to the article we're talking about:
http://groups.google.com/groups?hl=en&threadm=MPG.164d0f8c7fc7594498971b%
40news.dnai.com&rnum=1&prev=/groups%3Fas_umsgid%3DMPG.164d0f8c7fc7594498971b%
40news.dnai.com%26hl%3Den
Let's see if I asked a question of you for which the response is
"go away":
Here's the snipped from that above mentioned post
[I said}
> *Your* opinion is that I should not state my opinion about
> posts I find juvenile. Fine. I accept that is your opinion.
> Just don't bring up censorship. That makes no sense.
>
[you replied]
no my opinion is that I do not like associating with liars and cheats
so will you please go away. If anybody is curious here is the archive
from google( sorry about the line break):
nope, there's no excuse for trying to convince me to leave so that
I'll never post again. You are still a hypocrite.
Also you bring up the term liar and cheat in this snippet.
I'll remind you that in a previous post I challenged you to
come up with a post to substantiate that libel.
In another post yesterday you offered this vague hint as to
what you're talking about:
We start our chat at around article
Message-ID: <···················@oscar.eng.cv.net>
(this is around 40 posts into the thread)
so my original post was accurate. I took you at your word, my mistake
sorry.
Why didn't you say specifically what you were referring to.
Are you referring to the fact that I used the phrase "I donated AllegroServe"
when in fact the company I worked for donated it?
You were then chastised about even complaining about that, such
as in:
http://groups.google.com/groups?q=g:thl2054931052d&hl=en&selm=9n3cnc%24c98%240%
40216.39.145.192
Now I can't tell if you're an idiot or a liar. Then again maybe you're just
not a native speaker of English and don't understand the nuances of
the language and thus don't know how to interpret the
phrase "I donated AllegroServe".
In any event Marc (or whoever you really are) if you libel someone
in the future be sure to back up your statements. Say
"I think you're a liar because you said 'I donated AllegroServe' in
post <link>"
Then the other readers will simply dismiss you as someone who doesn't
understand English very well.
In article <··························@news.dnai.com>, John Foderaro wrote:
> In article <··················@oscar.eng.cv.net>,
> ····@oscar.eng.cv.net says...
>>> Yes I said that because you asked me what I want in the previous post
>>> so I answered. Now this is different because in this case, you
>>> hypocrite, I was responding to your direct request for that information
>>> so what is your problem, asked and answered. And thank you for not
>
> You're digging yourself in deeper and deeper.
>
Here is the correction I posted when I relized I made a mistake, about
2am EST:
###start
Message-ID: <··················@oscar.eng.cv.net>
> Yes I said that because you asked me what I want in the previous post
> so I answered. Now this is different because in this case, you
> hypocrite, I was responding to your direct request for that information
> so what is your problem, asked and answered. And thank you for not
> posting the artacle id or any attempt to accuratly identify the source
> of the quote other then your good word. I may have got the link wrong
> but at least I tried to be accurate, aparently you cant be bothered
> with accuracy or even the atempt.
> > marc
I misstated it was not a reply to a question of yours, but a
correction of what you said my oppinion was:
###end
> First, here's the link to the article we're talking about:
> http://groups.google.com/groups?hl=en&threadm=MPG.164d0f8c7fc7594498971b%
> 40news.dnai.com&rnum=1&prev=/groups%3Fas_umsgid%3DMPG.164d0f8c7fc7594498971b%
> 40news.dnai.com%26hl%3Den
>
> Let's see if I asked a question of you for which the response is
> "go away":
>
> Here's the snipped from that above mentioned post
>
> [I said}
> > *Your* opinion is that I should not state my opinion about
> > posts I find juvenile. Fine. I accept that is your opinion.
> > Just don't bring up censorship. That makes no sense.
> >
>
> [you replied]
> no my opinion is that I do not like associating with liars and cheats
> so will you please go away. If anybody is curious here is the archive
> from google( sorry about the line break):
>
>
>
> nope, there's no excuse for trying to convince me to leave so that
> I'll never post again. You are still a hypocrite.
first of all I do not make excuses, I take responability for my
actions. You make excuses for what you do, I do not. And I had no
real hope that you would take my wishs to heart and go away forever.
I was just correcting your misinformation, what you *thought* my
oppinion was, with fact, what my oppinion was, that is all. You do
have problems with facts.
>
> Also you bring up the term liar and cheat in this snippet.
>
from your demonstrated actions and posts here you are both of those
and more.
> I'll remind you that in a previous post I challenged you to
> come up with a post to substantiate that libel.
>
Remember you claimed to have donated alegroserve when you were paid by
your employer to write it, that is a lie and in that lie you stole the
credit that your employer is entitled to by funding and probably
asigning the work to you.
> In another post yesterday you offered this vague hint as to
> what you're talking about:
>
> We start our chat at around article
> Message-ID: <···················@oscar.eng.cv.net>
> (this is around 40 posts into the thread)
>
> so my original post was accurate. I took you at your word, my mistake
> sorry.
>
>
> Why didn't you say specifically what you were referring to.
> Are you referring to the fact that I used the phrase "I donated AllegroServe"
> when in fact the company I worked for donated it?
>
because you made that clame that you did donate it.
> You were then chastised about even complaining about that, such
> as in:
>
> http://groups.google.com/groups?q=g:thl2054931052d&hl=en&selm=9n3cnc%24c98%240%
> 40216.39.145.192
>
>
>
> Now I can't tell if you're an idiot or a liar. Then again maybe you're just
> not a native speaker of English and don't understand the nuances of
> the language and thus don't know how to interpret the
> phrase "I donated AllegroServe".
donate has a meaning, codified in a dictionary, and your bullshit
claim that after it was proved by your own admision that you did not
donate anything, franz did. Except that you had a special definition
of donate that was only avalable between your ears and that was the
definition that you used, is krap.
>
> In any event Marc (or whoever you really are) if you libel someone
that is who I am, please provide any evadence that I am someone else.
> in the future be sure to back up your statements. Say
> "I think you're a liar because you said 'I donated AllegroServe' in
> post <link>"
> Then the other readers will simply dismiss you as someone who doesn't
> understand English very well.
>
it is all in google, the whole mess
marc
>
>
Ok so it all comes down to my use of the word
'donate' to describe a piece of software that everyone
who knew about the software knew it came from Franz.
Everyone who posted except *two* people understood completely
what was meant by donate and didn't consider it to be
an attempt by me to claim that I funded the work.
Those two people are Marc Spitzer (see the current thread)
and Erik Naggum:
http://groups.google.com/groups?q=donated+group:comp.lang.lisp&hl=en&rnum=1
&selm=3208634224537825%40naggum.net
Is that a coincidence or what?
Look Erik, your Marc Spitzer alias has now succeeded in making
a complete fool of itself. Time to retire it. If you have something
to say, say it under your own name.
John Foderaro <···@xspammerx.franz.com> writes:
> Look Erik, your Marc Spitzer alias has now succeeded in making a
> complete fool of itself. Time to retire it. If you have something
> to say, say it under your own name.
I think you're so paranoid delusional that you actually have the
impression that anyone that disagrees with you has to be an alias for
#Erik.
G.I. Gunmaker may have been an alias; Marc Spitzer sure seems to have
his own distinctive personality, primarily doing FreeBSD-related
stuff.
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://www.ntlug.org/~cbbrowne/unix.html
"But what....is it good for?" -- Engineer at the Advanced Computing
Systems Division of IBM about the microchip. 1968
In article <·······················@news20.bellglobal.com>, ········@acm.org
says...
> I think you're so paranoid delusional that you actually have the
> impression that anyone that disagrees with you has to be an alias for
> #Erik.
Not at all. What makes me suspicious is his style and word
choice and the fact that he came out of nowhere, acts like
he knows me and has a grudge against me.
Maybe he idolizes Erik so much that he tries to copy
him in every way. Maybe he is Erik. It wouldn't
be the first time Erik did this.
In article <··························@news.dnai.com>, "John Foderaro"
<···@xspammerx.franz.com> wrote:
> In article <·······················@news20.bellglobal.com>,
> ········@acm.org says...
>> I think you're so paranoid delusional that you actually have the
>> impression that anyone that disagrees with you has to be an alias for
>> #Erik.
>
> Not at all. What makes me suspicious is his style and word
> choice and the fact that he came out of nowhere, acts like he knows me
> and has a grudge against me.
> Maybe he idolizes Erik so much that he tries to copy
> him in every way. Maybe he is Erik. It wouldn't be the first time
> Erik did this.
A few seconds with Google shows that this is not the case.
So will the two of you please just stop or take it to email? Jesus! If I want
paranoia and bad grammar I can go to alt.flame! I use the fruits of Foderaro's
labors (ACL and AServe) every day and I really don't care what different
semantics people attach to "donate."
Tim
John Foderaro <···@xspammerx.franz.com> writes:
[ Marc Spitzer ]
> Maybe he idolizes Erik so much that he tries to copy
> him in every way.
I wish he would, actually. Erik's posts also include some accurate,
informative and entertaining articles about Common Lisp, which are
written in good English and correctly spelled.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
In article <··············@noetbook.telent.net>, Daniel Barlow wrote:
> John Foderaro <···@xspammerx.franz.com> writes:
>
> [ Marc Spitzer ]
>> Maybe he idolizes Erik so much that he tries to copy
>> him in every way.
>
> I wish he would, actually. Erik's posts also include some accurate,
> informative and entertaining articles about Common Lisp, which are
> written in good English and correctly spelled.
>
>
> -dan
I am working on it, its just slow going. Some of the stuff I come up
with ispell tells me to go away. Or better yet I manage to misspell
the word into another different word.
marc
>
> --
>
> http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
In article <··························@news.dnai.com>, John Foderaro wrote:
> In article <·······················@news20.bellglobal.com>, ········@acm.org
> says...
>> I think you're so paranoid delusional that you actually have the
>> impression that anyone that disagrees with you has to be an alias for
>> #Erik.
>
> Not at all. What makes me suspicious is his style and word
> choice and the fact that he came out of nowhere, acts like
> he knows me and has a grudge against me.
> Maybe he idolizes Erik so much that he tries to copy
> him in every way. Maybe he is Erik. It wouldn't
> be the first time Erik did this.
>
>
First I do not idolize Erik, I never met him. Well I have read a lot
of Erik's posts and I am capable of recognizing technical merit when I
see it. Erik's posts have a great style of argument, better then the
one I used to use, so I tried to incorporate it in my writtings.
How do you know how long I was here before my first post? I do not know
you well, only from what I see here, and from what I have seen I do
not want to know you any better then I already do.
marc
From: Brian P Templeton
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <87snb4c8q9.fsf@tunes.org>
This is absurd! Do you really believe that, just because Marc Spitzer
only recently started posting to c.l.l and strongly disagrees with
you, he must be Erik, or *at least* copying Erik, and that it is
impossible to disagree with you just because you post stupid comments
(this one being a good example)?
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
In article <·······················@news20.bellglobal.com>,
········@acm.org wrote:
> John Foderaro <···@xspammerx.franz.com> writes:
>> Look Erik, your Marc Spitzer alias has now succeeded in making a
>> complete fool of itself. Time to retire it. If you have something
>> to say, say it under your own name.
>
> I think you're so paranoid delusional that you actually have the
> impression that anyone that disagrees with you has to be an alias for
> #Erik.
>
> G.I. Gunmaker may have been an alias; Marc Spitzer sure seems to have
> his own distinctive personality, primarily doing FreeBSD-related
> stuff.
one point G.I. Gunmaker and Erik Naggum are spelled from the same
group of letters, ie a smart alias. There is no way to get marc
spitzer from erik naggum.
marc
> --
> (concatenate 'string "cbbrowne" ·@ntlug.org")
> http://www.ntlug.org/~cbbrowne/unix.html
> "But what....is it good for?" -- Engineer at the Advanced Computing
> Systems Division of IBM about the microchip. 1968
In article <··························@news.dnai.com>, John Foderaro wrote:
> Ok so it all comes down to my use of the word
> 'donate' to describe a piece of software that everyone
> who knew about the software knew it came from Franz.
you just claimed otherwise, there is the rub.
>
> Everyone who posted except *two* people understood completely
> what was meant by donate and didn't consider it to be
> an attempt by me to claim that I funded the work.
perhaps most people who read this just were unwilling to expend the
time on you nessasary to disagree with you, a lot of them are smarter
then me and I guess it this case it shows. You are a monumental
waste of time
>
> Those two people are Marc Spitzer (see the current thread)
> and Erik Naggum:
>
> http://groups.google.com/groups?q=donated+group:comp.lang.lisp&hl=en&rnum=1
> &selm=3208634224537825%40naggum.net
>
>
> Is that a coincidence or what?
Well I have to get back in my black helicopter now and fly to norway
for my next post.
>
>
> Look Erik, your Marc Spitzer alias has now succeeded in making
> a complete fool of itself. Time to retire it. If you have something
> to say, say it under your own name.
>
marc
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214776889576961@naggum.net>
* John Foderaro
| Look Erik, your Marc Spitzer alias has now succeeded in making a complete
| fool of itself. Time to retire it. If you have something to say, say it
| under your own name.
Consult a psychiatrist, John Foderaro. This is not a support group for
fucked-up mental cases like you who refuse to seek help, but bother a lot
people with what could be easily cured. Behaving the way you keep doing
is like a moron who refuses to visit a dentist for his tooth-aches and
blames someone else for his pains and then takes it out on them at random.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214770837469323@naggum.net>
* John Foderaro -> Marc Spitzer
| Ok I'm going to now ask you to back up that claim that I posted lies.
You post lies all the time, but you give us a clue to understand how your
mind has deteriorated: You believe what is untrue and have become so
deeply entrenched in your own view of things that you are disconnected
from reality, and so you draw one insane conclusion after another from
your own beliefs, not from anything you observe, any longer. It is hard
to see when you are _not_ lying, when you do not have ulterior motives,
when anything you say actually _is_ true, and not something that you only
say because you hope it will cause people to feel something you want them
to feel. This dishonesty and manipulativeness is pandemic. _Respecting_
the opinions of anyone else is completely foreign to you: you call people
"religious" as soon as you are unable to argue against them; you pretend
that the amazingly idiotic nonsense you keep saying about me or any other
person who simply want you to respect the standard and cut the crap is
not personal, but there is _nothing_ technical in your increasingly
pathetic ranting and raving, and nothing to make you stop posting this
crap. Nobody believes you, nor should they. The problem is that you are
such a pathologically _dishonest_ person that you have become unable to
distinguish what you want to believe from reality as you and others see
it. There is no truth to you, there is only John Foderaro's _personal_
"reality", with a significant population of monsters under your bed.
Pointing out to you that something you said is _wrong_ and misrepresents
someone does not work the same way it does on normal people, because you
will (1) never grasp that it was wrong, and (2) never admit to it even if
you do. You have been caught lying and misrepresenting several times,
yet you keep clamoring for "evidence", just like a person who knows he is
guilty as hell yet hopes nobody can prove it in court. When you get the
evidence you ask for, you just shut up for a while. Several people have
pointed this out in this very newsgroup, yet nothing happens from your
end when they do. This is _extremely_ suspicious. It is if the _only_
thing you are actually upset about is that your lies are being exposed,
your destructiveness towards the standard upon which you and your company
have decided to build your business. Many _really_ bad guys react the
same way when their criminal ways threaten to cease to pay off: They get
really angry and blame those who exposed them, not themselves for having
done something wrong all this time. I am unfortunate enough to expose
bad guys and frauds like you, so a lot of you think that it helps to
attack me. It probably would in real life, which is why some of the bad
guys clearly think in terms of _physical_ bullies. But that is not it,
and you guys know it: You cannot avoid knowing that all that happens here
is that I post my opinions and you get really, seriously mad with rage.
Why do you guys not figure it out? You expose yourself by getting mad,
not by what I say. Let me give you an example of how this stark insanity
of yours works:
| And who is Marc Spitzer anyway? There seems to be no record of you on
| the net before the year 2000. In the past Erik Naggum has deceived the
| members of this newsgroup by posting under aliases (one we know for sure
| about was something like "GI Gunmaker"). You come out of nowhere and
| make all these moralistic claims while posting lies and hypocrisy to stir
| up trouble. This is the same writing style used by Erik Naggum. I
| believe that you are either another Naggum pseudonym or are posting
| messages on behalf of him.
It is now clear that John K. Foderaro has become completely insane.
The observant reader will also notice that this _amazing_ paragraph just
happened to be in the same posting as his call for claims that he lies.
That is so ... _unexpected_ from him. Who could have seen this coming?
Well, I could, because I no longer expect him to be able to distinguish
between what goes on within his deranged mind and what he observes from
the outside world. Such psychotic episodes have been increasing in rate
lately, but people close to him have already suggested he gets committed
to a mental hospital and somebody who cares about him should help him.
The above quoted paragraph makes it evident that he has finally lost his
mind, or, with his own wording about people he disagrees with: "you
either didn't have the ability to reason or were just trying to make
trouble". And I thought he was critical of such "language", but he is
evidently exempt from his own moralistic rules of polite behavior. But
why the exclusive choice? In his case, it is clearly inclusive. It was
clear to me that he was irrational and had a dysfunctional brain the
first time I heard him ranting and raving about upper-case symbol names,
the _conspiracy_ in the committee against him, and his strong disrespect
for central members of the committee, not to mention the whole political
process, which a selfish, short-sighted person would fail to understand
is necessary. I mean, just make the problems go away as far as you see
it. After all, this is a technical problem, right? E.g., Allegro CL has
a :case-insensitive argument to apropos, which defaults to nil -- which
is pretty silly considering the intensity he feels about the case issue;
it is as if he _wants_ to be enraged about this upper-case symbol names,
instead of actually solving it, like a rebel without a clue.
<technical
As for the case-sensitive-lower issue, a readtable-case value of :invert
_actually_ works for those who are able to deal with _technical_ issues,
and as for the return-value of symbol-name, the solution is quite simple:
new, improved versions of the functions that interact with symbol-names.
E.g., in a parody of the if* stunt, we could have intern*, find-symbol*,
and symbol-name*, which would maintain and return a lower-case version of
the all-upper-case symbols and vice versa. This could be accomplished
within a conforming Common Lisp system, it would be transparent to those
who still want conforming behavior, and lower-case and upper-case code
can coexist in the same system without needing to convert code to only
one mode. The whole "mode" and conversion business is a way of locking
people into a bogus and gratuitous deviation from the standard, to give
them something that on the surface looks desirable (especially since the
stuff that was necessary to make standard solutions work were left buggy
for more than a decade) in exchange for dropping _standard_ Common Lisp.
>
When I wanted to get rid of the annoying "modern _mode_", I spent only a
couple days tinkering with variations on the theme of coexistence, and
came up with several working solutions, whereas John Foderaro has spent,
what, 15 years?, being _enraged_ about this issue. So I do not think
this solution will placate him, either, since he is so upset that the
_standard_ does not agree with him that this is no longer an engineering
problem to him: It is a _psychological_ problem, just like if* is. So,
since the standard does not agree with John Foderaro, it must be fought
and made more difficult to use than necessary. (Whoever wants to type in
(apropos "foobar" nil :case-insensitive t) interactively, no matter how
much support you get from the environment to expand abbreviated forms?)
Sane people figure out technical ways to deal with technical problems and
obstructions, and just move on. Insanity lies in neither solving nor
getting over things.
Standards _should_ be followed, but _only_ if they are written by John
Foderaro. The same patholocal egocentricism is present in most of what
you do -- when I argue Franz Inc should not publish your crufty code, you
take it to mean that _you_ should not _use_ your silly if* stunt, even
claim that that is what I _said_. This world is all about John Foderaro,
and whatever he does is right, even if he is so critical of others who do
something much less vile than he does that he calls on the community to
denounce their behavior in his typical mistargeted moralism. I should be
lambasted for being rude and to disrespect John Foderaro, but John
Foderaro is free to misbehave without lower bounds towards me and to
other people. It is no wonder that this pathological liar usually only
finds hypocrisy to criticize others for, if only by stretching the facts
so much they would have snapped, at least in a mind that had not itself
snapped.
Please understand that _you_ are the aggressor, John Foderaro. _You_ are
the bad guy, here. You have lost your moral high ground, if you ever had
any, with the above stunt, if not several times previously when you do
things that you want the whole community to denounce when others do it.
You keep doing worse things than anybody else, just like those moralists
who suspend their own morality when fighting what they always mistakenly
believe is evil -- the evil they really fight is their own, and so too
with you, John Foderaro. Nobody in their right mind will believe you are
morally justified in "defending" yourself, anymore, since you are in fact
only attacking, not defending _anything_, anymore. Emulating the _worst_
of the USENET retards, indeed being one of them, you have clearly turned
into the derelict I have long thought you would one day show yourself as,
given your evidently criminal mind, your incredible arrogance towards
other people's concerns, and your psychotic episodes where you cannot
even distinguish between the monsters you want to exist and the reality
you share with other people. You are completely out of control, now, and
that is pretty amazing to watch.
On the other hand, I am actually quite _happy_ to see that you need to
engage in these tactics and lose all control over yourself. I tend to
appreciate that the people I think are f*cking nuts are indeed willing to
prove1 to the world, all on their own, that they _are_ stark raving mad.
I do not really need to do anything more with John Foderaro, now. He
will do more harm to himself than I can do, anyway, because this means
that I am a _formidable_ threat to his sense of inflated self-importance,
that he takes this if* stunt _deeply_ personally (as if anyone doubted
that) and also the fact that I have now called his stupid bluff when he
lies about wanting the standard to survive. His duplicity has alarmed
many people, and the more his anti-standard attitude shines through, the
more responsible programmers and other people interested in Common Lisp
must wonder how much they can trust his code or the company that trusts
him. Considering hir rampant irrationality in dealing with technical
matters, it is incumbent upon any user of his code, source or other, to
watch for potentially destructive behavior and "political bugs" because
he does not want to respect the standard, only the parts he "agrees" with
-- and thus takes short-cuts when he thinks he knows better. This is not
unique to John Foderaro, however, Bruno Haible is equally arrogant and
also mistakenly believes that people care what their personal opinions
are when they are implementing something according to a _specification_.
People who hold real jobs get fired if they cannot obey instructions, but
for some reason we are supposed to excuse those who give away their work.
Finally, the difference between a heated (technical) debate (which occurs
quite frequently among people who have ideas worth exploring, especially
in academia) and a personal fight (which occurs quite frequently when a
moron understands that he is wrong but does not want to quit because he
has psyhological or ego problems) is that technical debates has at least
one point of resolution which can be reached no matter how heated the
debate becomes -- _something_ which makes the parties able to _settle_ on
something and move on, still respecting eachother, probably more so
because of their strength of conviction and argumentation skills. What
we know about most of the people who fight me in this newsgroup is that
they do _not_ want to resolve anything at all, fail completely to figure
out what would end all criticism, even tough it is provided to them in
plain text in almost every message I write, and so it is with John
Foderaro, a person whose thinking skills are clearly too limited to be of
use to him when he is in a conflict over a purported "technical" issues
that really is something completely different to him. When the objective
is to fight, the moron will never quit, and will be held back by nothing
when losing without dignity is his only remaining option. Way to go for
a Chief Scientist!
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
When you review papers for a technical conference inevitably you
find one that looks like your last posting: lots of text but
no footnotes or references at the end. The author draws
amazing conclusions based on "facts" stated earlier. Of course
these "facts" are not really facts at all. The paper is really
just the raving of a lunatic.
I have no doubt that in your mind you actually believe all
those things you said about me from and which you drew your conclusions.
I live in what's called the real world though. In my world you
can find references and actually prove things. In the past
I've asked you to back up statements you've claimed I've made
and each and every time you have failed to do so (because you couldn't do
so).
For example:
http://groups.google.com/groups?q=g:thl1251669294d&hl=en&selm=MPG.15fd1848e25b8b1a9897
06%40news.dnai.com
I have no interest in learning about the world inside your head. It looks
like a very dark place.
I'm sure that everyone on this newsgroup is sick of this 'discussion'
between you and me.
Let's just call it over.
You don't mention or make references to me or and I'll do likewise for you.
You can show agreement by simply not replying to this post.
Then the newsgroup can rest easy.
In article <··························@news.dnai.com>, John Foderaro wrote:
> When you review papers for a technical conference inevitably you
> find one that looks like your last posting: lots of text but
> no footnotes or references at the end. The author draws
> amazing conclusions based on "facts" stated earlier. Of course
> these "facts" are not really facts at all. The paper is really
> just the raving of a lunatic.
>
> I have no doubt that in your mind you actually believe all
> those things you said about me from and which you drew your conclusions.
> I live in what's called the real world though. In my world you
> can find references and actually prove things. In the past
> I've asked you to back up statements you've claimed I've made
> and each and every time you have failed to do so (because you couldn't do
> so).
>
> For example:
>
> http://groups.google.com/groups?q=g:thl1251669294d&hl=en&selm=MPG.15fd1848e25b8b1a9897
> 06%40news.dnai.com
>
>
>
> I have no interest in learning about the world inside your head. It looks
> like a very dark place.
>
> I'm sure that everyone on this newsgroup is sick of this 'discussion'
> between you and me.
>
> Let's just call it over.
>
> You don't mention or make references to me or and I'll do likewise for you.
> You can show agreement by simply not replying to this post.
> Then the newsgroup can rest easy.
>
>
Who are you addressing this to Marc Spitzer or Erik Naggum? Or the
one that is both of us?
John is the manager at Franz who is responable for seeing that you
don't fuck up in comp.lang.lisp and make the company look stupid to its
customers current and future on vacation this week? If he is sick I
hope he gets well real soon and shut you up again. You are most
assuredly best when quite.
marc
John Foderaro <···@unspamx.franz.com> writes:
> When you review papers for a technical conference inevitably you
> find one that looks like your last posting: lots of text but no
> footnotes or references at the end. The author draws amazing
> conclusions based on "facts" stated earlier. Of course these "facts"
> are not really facts at all. The paper is really just the raving of
> a lunatic.
There must be a whole lot of "raving lunacy" around here, then...
> You don't mention or make references to me or and I'll do likewise
> for you. You can show agreement by simply not replying to this
> post. Then the newsgroup can rest easy.
So long as the "IF* advocacy" is out there, that's going to be pretty
problematic.
Any time someone comes by with some code contribution where the "IF*
issue" comes up, the party responsible for encouraging making up such
variant "wanna-be-standards" will continue to be you, and any relevant
controversy will _obviously_ have to swirl around you.
It's all definitely _not_ reflecting well on Franz...
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://www.cbbrowne.com/info/x.html
"never post anything you don't want to see on your resume..."
-- Martin Minow <·····@pobox.com>
I keep trying to close down this thread but you keep bringing
me back in.
Let me make two more comments about if* to counter recent
ludicrous arguments against it.
1. One thing we can tell Java programmers that Lisp has they don't
are macros. We can tell them that they will forever be stuck
programming in simple Java statments whereas we Lispers are free to
build the Lisp language into whatever form we find best allows
us to write the program we wish to write.
This certainly impresses the Java programmer who then asks; "please
show me some examples form your code repositiories of how you've
use this powerful macro facility to build on the Lisp language."
At this point you must reply, "well...err.. we've decided that
it's antisocial to use this feature of Lisp. We resign ourselves
to writing only using the forms given in the Common Lisp spec."
The Java guys says,"so you're actually no better off than us."
Given the sentiment *against* using the Common Lisp as it was
designed (as as the Lisps before it were designed), I'm proud
to be able to put out code that demonstrates the very important
language extension features of Lisp. Maybe someone will
realize "hey, I can do that too" and find Lisp to be a much
better tool for the application than Java.
2. I read all this about "publishing code" as being analogous
to publishing a book and it only convinces me that the writer
has never published code.
Books are static things. They are written, painstakingly
edited, then printed and they sit on the shelf for years.
Code on the other hand is often an example of a work in progress.
The AllegroServe code I publish doesn't go through a
month long review by an editor before it's put on the ftp site.
It is simply a snapshot of the current version of the source
probably less than a week old.
It's critical that the code be reliable and I will use every
tool Lisp has to offer to make it so, including ***macros****.
I am not going to lower the reliabilty by making it less
readable to the person doing the development on it (namely me).
>> It's all definitely _not_ reflecting well on Franz...
This is *your* opinion and based on the feedback I've gotten
it's thankfully a small minority opinion.
In article <··························@news.dnai.com>, John Foderaro wrote:
> I keep trying to close down this thread but you keep bringing
> me back in.
Mr Browne,
Soon you too shall be called Erik Naggum.
[some krap removed]
>
>>> It's all definitely _not_ reflecting well on Franz...
>
> This is *your* opinion and based on the feedback I've gotten
> it's thankfully a small minority opinion.
>
that is correct *everyone* who disagrees with you is Erik Naggum. So
there is only 1 person, if he really exists that is, who disagrees
with you in the *whole* world
marc
>
>
>
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214794312426399@naggum.net>
* John Foderaro -> Christpher Brown (uncredited in original message)
| I keep trying to close down this thread but you keep bringing
| me back in.
It is not his fault that you keep replying, you dork. Just shut up if
you think that is what you should have been doing. I happen to agree
violently, but do not let that stop you. The world does not become any
better just because you feel you need to post something. It does in fact
become a lot worse when you keep posting your drivel. _My_ drivel is of
course so valuable to mankind that it will be included in future editions
of the Encyclopaedia Galactica. All of it. But nono of yours. Hint.�
| This is *your* opinion and based on the feedback I've gotten it's
| thankfully a small minority opinion.
Every lunatic on USENET uses the volume of received e-mail to establish
his popularity or that of his views. It has become the most used proof
of popularity, sanity, whatever: It matters a great deal what people you
have no idea who might be have said in e-mail you have not seen. Of
course it does, come one! Random customer endorsement on TV works, so
why not on USENET, too? Really!
Why would _anyone_ subject themselves to mailing you any form of
critical, insightful comments about your moronic macro? Just look at
what you do to people who try to make you _think_ in this newsgroup!
Man, for someone who makes a moronic point about "proving things", you
sure lack the basics in thinking skills when it comes to evaluating the
evidence. I wonder if the huge volume of positive feedback is what keeps
you going. I wonder if those who mailed you positive feedback feel a
little responsible for what you keep doing and now regret it vehemently.
Oh, _I_ got a wonderful letter from an author whose book I recommended on
USENET not too long ago, and the auhtor said I understood the book.
Woohoo! Am I great or what? Of course, I could be lying. In fact, you
have _no_ way to know if this is true or not. As such, it has absolutely
_no_ value as an argument or even supporting evidence for anything
whatsoever -- the author could be misled by the way I expressed myself
and it just looked like I had understood the book, or the author could
just be overly happy that _somebody_ looked like they understood the book
and entice me to into a discussion. But suppose I take it at face value,
and suppose it is true, does it have _anything_ but strictly personal
value for me? No. Had the author gone public with the comment, it could
have. Am I now entitled to speak for the author? No. Can I drop names
and impress people with it? No. It has _no_ public value whatsoever.
That is the nature of an undisclosed personal mail. Even referring to
personal mail must be considered unethical because it carries absolutely
_no_ weight in a public forum, but some unthinking people may not see
that what such an argument says is _only_ that he who utters it is a jerk
with an ego problem.
Instead of being remembered as the "prove things" guy, John Foderaro is
on his way to becoming known as the "backfire" guy. No wonder he wants
this to be over. But did that work? No. This time, it was not _his_
fault that he was "brought back in". Other people will "keep bringing
him back in" all the time. Never will he grasp that _he_ needs to sit
still and take the abuse like he wants other people to do. But it will
be fun, for a couple days or so, to see if he needs to "defend" himself.
Now for a scary thought: Maybe he meant all the _positive_ feedback he
has received here in comp.lang.lisp? I mean, if he lives in the "real
world" where he can "prove things", as opposed to the only one the rest
of us live in, who knows what the public disdain for if* translates to.
Another scary thought: If people send him positive feedback, does he
request that they prove it? If he does _not_ accept negative feedback
without accompanying evidence and proof and everything, but _does_ accept
positive feedback without any such thing, somebody could simply mail him
what looks like positive feedback and just be playing mind games with
him. I would do that. I would rattle off a mail like "Yo, dude, I love
your if* macro!" and laugh my ass off. This probably accounts for half
of the positive messages he has received.
Yet another scary thought: For a person who has accused other people of
flaming everybody who disagrees with him, let us look at how he sorts his
mail: Those who agree with him are considered valuable feedback and are
carefully counted. Those who do _not_ agree with him are discarded as
"that is *your* opinion". That this arroagnt response does not apply to
the feedback that supports his demented view is rather alarming. Of
course, those who have provided him with "feedback", real or imagined,
deserve a "that is *your* opinion" and be counted at least as carefully
as all the Al Gore votes in Florida, like, not.
Finally, the last scary thought: John Foderaro _actually_ believes that
it helps his case to refer to "feedback" he has received without proof of
any kind. For all we know, it just another stupid tactic by the
dishonest manipulator to make people who express disagreement with him
_feel_ bad, for being in a "small minority". Since he was in a _very_
"small minority" when the ANSI standard was hammered out and his stupid
little if* stunt, not to mention the upper-case names issue, was voted
on, we can visualize the pain he intends to inflict on people who are in
"small minorities": John Foderaro knows how much it hurts to be alone
with the world's most brilliant invention, and now it is your turn to
feel the pain of being _alone_ with *your* opinion. Ouch, indeed.
///
-------
� If you did not understand that this was a joke, get yourself committed TODAY.
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
In article <··························@news.dnai.com>, John Foderaro
<···@unspamx.franz.com> wrote:
> I keep trying to close down this thread but you keep bringing
> me back in.
> Let me make two more comments about if* to counter recent
> ludicrous arguments against it.
>
> 1. One thing we can tell Java programmers that Lisp has they don't
> are macros. We can tell them that they will forever be stuck
> programming in simple Java statments whereas we Lispers are free to
> build the Lisp language into whatever form we find best allows
> us to write the program we wish to write.
> This certainly impresses the Java programmer who then asks; "please
> show me some examples form your code repositiories of how you've
> use this powerful macro facility to build on the Lisp language."
> At this point you must reply, "well...err.. we've decided that
> it's antisocial to use this feature of Lisp. We resign ourselves
> to writing only using the forms given in the Common Lisp spec."
>
> The Java guys says,"so you're actually no better off than us."
I'm just playing with CL, but I use Dylan for real work. In Dylan
programs, I find that i use marcos a lot, but usually the use of them is
really localized and you can see the definition from where you use it.
As a publicly available example, in the ICFP2000 contest Ray Tracer
program, viewable at...
http://berlin.ccc.de/cgi-bin/cvsweb/ICFP2000/src
... we wrote code like this:
define unary-primitive acos(<fp>,
method(f :: <fp>) rad2deg * acos(f) end) end;
define unary-primitive asin(<fp>,
method(f :: <fp>) rad2deg * asin(f) end) end;
define unary-primitive cos (<fp>,
method(f :: <fp>) cos(f * deg2rad) end) end;
define unary-primitive sin (<fp>,
method(f :: <fp>) sin(f * deg2rad) end) end;
define unary-primitive clampf(<fp>,
method(f :: <fp>) min(1.0, max(0.0, f)) end) end;
define unary-primitive floor(<fp>) end;
define unary-primitive frac(<fp>,
method(f :: <fp>) f - f.truncate end method) end;
define unary-primitive real(<integer>, �curry(as, <fp>)) end;
define unary-primitive sqrt(<fp>) end;
Each "define unary-primitive" is a macro that adds three different
methods to two generic functions for compiling and optimizing those
opertions in the compiler for a toy language. We also had ...
define numeric-binary-primitive add(\+) end;
define numeric-binary-primitive eq(\==) end;
define numeric-binary-primitive less(\<) end;
define numeric-binary-primitive mul(\*) end;
define numeric-binary-primitive sub(\-) end;
... where each line defined both integer and floating-point primitives,
and each of those consisted of five methods added to three different
Generic Functions.
Elsewhere in the same program we used a macro to build a lexer from a
very readable description format.
This was in a contest entry written to a 72-hour deadline. We didn't
use macros to be funny or clever. We used them to save us time in
writing the program, understanding it, and debugging it.
I sympathize with the lack of acceptance of your IF* macro, which I
think may well be better than what is standard in CL, but at the same
time I'm not sure that it's *enough* better (or enough different) to
what is already there that it is worth people changing.
-- Bruce
In article <················@hotmail.com>, Will Deakin
<···········@hotmail.com> wrote:
> Bruce Hoult wrote:
>
> > ...In Dylan programs, I find that i use marcos a lot...
> Does he know?
I also use tyops a lot.
-- Bruce
1000 [(Must proofread posts better) show] repeat
From: Dorai Sitaram
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <9t0jf3$n16$1@news.gte.com>
In article <···························@news.paradise.net.nz>,
Bruce Hoult <·····@hoult.org> wrote:
>In article <················@hotmail.com>, Will Deakin
><···········@hotmail.com> wrote:
>
>> Bruce Hoult wrote:
>>
>> > ...In Dylan programs, I find that i use marcos a lot...
>> Does he know?
>
>I also use tyops a lot.
You ty him op when you use him?
Shocked,
--d
In article <············@news.gte.com>, ····@gte.com wrote:
> In article <···························@news.paradise.net.nz>,
> Bruce Hoult <·····@hoult.org> wrote:
> >In article <················@hotmail.com>, Will Deakin
> ><···········@hotmail.com> wrote:
> >
> >> Bruce Hoult wrote:
> >>
> >> > ...In Dylan programs, I find that i use marcos a lot...
> >> Does he know?
> >
> >I also use tyops a lot.
>
> You ty him op when you use him?
I don't like to needlessly objectify such a nice package, but you can
make a real hash of one if you tie it.
-- Bruce
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214791267021923@naggum.net>
* John Foderaro
| I live in what's called the real world though.
Yes, this is indeed every psychotic's favorite line. People who need to
point out the dichotomy between the "real world" and somebody else's line
of arguments has already established that _they_ believe in the dichotomy
to begin with. People who actually share the same reality with everybody
else know that such a dichotomy is prima facie evidence of a psychosis.
So when a person invokes the "real world" argument, you know a few things
about that person: He has _personal_ experience with "non-real worlds"
_and_ he is either so stupid that he thinks such an argument will hurt
anyone but himself _or_ he thinks that his audience is so stupid they
will not see through his pathetic attempt at an insult. All in all, a
fantastically _idiotic_ thing to say.
| In my world you can find references and actually prove things.
Yes, I am quite sure that your world is like that. This admirable "real
world" of yours looks like a term paper. It probably only consists of
that which can be proven, and that which cannot be proven from "first
principles", i.e., John Foderaro's personal belief system, does _not_
exist. In other words, the "real world" you live in is a figment of your
imagination because it only consists of things you can prove within it
from things you believe to be true _without_ evidence. This desire for
"proving things" is _also_ quite pathological. Lots of nutcases have
become that way because they can prove all _sorts_ of weird things.
The set of truths that cannot be "proved" is vastly more interesting than
those that can. The desire to "prove" certain claims is simply a desire
to move the point of trust to something else, a process that terminates
at something that people agree to take for granted. However, they do not
agree to a whole lot of things when push comes to shove, and most people
are generally unaware of their thinking processes to such an extent that
they do not recognize fairly obvious idiocy. Some are even so goddamn
stupid that they think invoking the "real world" argument helps them. In
our particular case, my several years of philosophy studies will beat you
into a pulp before we get to these first principles, because you are so
unaware of yourself that your desire for proof and evidence looks lika a
joke you play on people for effect, if it is not evidence of arrested
development, but I am generous today and do not think so. I mean, people
who are not trained in philosophical thinking will probably regard your
statement above as pretty clever. To "prove things" has such high merit
in our scientific society that many people tend to think of it as an
unconditional value. However, human _understanding_ does not go by way
of proofs, but by way of things making _sense_. Only a very small number
of fields are subject to lines of argumentation that can look like they
"prove things". In fact, the biggest problem we have is that the most
important fields of human endeavor are _not_ subject to such proofs, like
what and how we _value_. If I understand your previous rantings and
ravings correctly, you consider such things to be "religion". This is,
again, an _amazingly_ stupid attitude.
Only a nutcase will think reducing _everything_ to the point where
proving things is of value in a _discussion_. Now, can I _prove_ this?
Or is it sufficient to argue for it so people believe it makes sense? To
most intelligent people, proving things like that means showing that it
follows from more fundamental findings and principles. The problem is
that those are usually _more_ contentious than the conclusion, because
the people who are into this kind of stuff are _professional_ quibblers
and this stuff is actually tremendously hard. There is no point at all
in formalizing the process. It is _only_ used by people who think that
they will not be exposed as nutcases for "requiring" proof of everything,
but instead succeed in bullying people into shutting up if the cannot
cough up the "proof". The way to deal with such nutcases is to point out
that a proof means exactly _nothing_, and lacking a proof means exactly
as much, in a debate, that is. Reducing a particular argument to its
most fundamental premises is a useful exercise, but it has absolutely
nothing to do on a USENET newsgroup. This is evidenced by the fact that
Mr. Proof himself, John Foderaro, never proves anything of importance,
and especially not why proving things is so valuable -- that is just
taken for granted. Well, I disagree, so where does that leave us? Oh,
John Foderaro has the answer: Either I am "religious" or I do not live in
the "real world" or something like that. Only nutcases argue that way.
| In the past I've asked you to back up statements you've claimed I've made
| and each and every time you have failed to do so (because you couldn't do
| so).
But curiously, you are not backing up your own statements. This claim is
in fact false -- and people do remember it. It is fascinating that you
set yourself up to be shot down so easily by using one of the incompetent
rethorician's favorite words: "every". A single counter-example, and you
are _dead_ as far as your "proofs" and arguments go. The counter-example
is when you claimed that I had said that you could not use if*. I have
pointed out that I had in fact asked _Franz_Inc_ not to _publish_ code
with if*. You go find it, who are so good at googling.
Incidentally, there are a number of really wacky people out there. They
read google like the Devil reads the Bible, and love every minute of it:
If you are sufficiently insane, you can "prove" anything by picking news
articles. One of the most interesting things about people who argue with
other people is that if they actually are able to learn from the debates
they engage in, they will change their views. Amazingly, to the google-
lovers, this is considered "proof" that they are inconsistent! Can you
even _imagine_ a worse abuse of logic than this? The whole _purpose_ of
a discussion is to change people's minds, to impart information to people
who use it to form and reform their opinions and conclusions. The only
reason someone does _not_ change their views is if they do not _listen_.
_This_ is the hallmark of the nutcases: Their minds are closed, fixed,
frozen. Now, add to this point how difficult it is to "prove things".
For something to be proven, you have to have a solid chain of arguments
that each are proven valid and true _all_ the way down. If you change
your mind, that means your previous conclusions were wrong, because your
previous conclusions were not fuzzy opinions that could be "uncertain",
but _proven_. To revise an opinion thus proven means that something far
more important must be revised, and that has serious repercussions for a
lot of other things, so "proof people" are much harder to convince than
people who argue by the seat of their pants, as it were. A person who
lives by proofs, will die by proofs. The more you prove, the less
freedom you have to be wrong. The less freedom you have to be wrong, the
less you can hold in limbo and allow to be _uncertain_ and "for further
study", yet still treat as valid enough to base hypotheses on that can be
tested. The problem for people who think that "to prove things" is a
value is that _if_ they are wrong, it has far-reaching consequences for
their belief systems. Therefore, a person who believes that "to prove
things" in an open discussion is a value is a person who is willing to
_bet_ a very large part of his belief system on being right. This is
dangerous, because whatever you _have_ believed in the past was based on
what you knew then. The more you know, the less likely it it that your
old conclusions will continue to hold. It should be obvious that this
translates to a psychological dilemma: Shut down your brain and protect
your sanity, or keep accepting new information from the outside world and
see your proofs crumble and need to be rebuilt over and over, going
insane sooner or later. The most common solution to this problem is not
what you would expect: To drop the silly notion that everything be proved
or at least provable, but to deny new information that challenges one's
existing conclusions. At one point or another, "proof people" will make
the mistake of valuing past conclusions higher than future conclusions.
In our case, we have a certifiable nutcase who invokes the "real world"
and who calls those who disagree with him "religious", who also needs to
"prove things", but who does not _accept_ any of the proof he receives.
We have a person who is in deep denial of his own wrongdoing, of the fact
that he really _is_ a very, very bad guy, and of the fact that if he
really is concerned about good behavior, he has a lot of cleaning up to
do at home before he can dole out credible advice about it.
| I have no interest in learning about the world inside your head. It
| looks like a very dark place.
You obviously speak from personal experience, but listen to people close
to you who tell you that your experience is not usable for extrapolation
about any other person without further justification. Just because you
experienced it does not mean it was not _because_ of you and therefore
not valid for anyone else -- that part has to be established separately
and independently, especially if you are serious about "proving things".
| I'm sure that everyone on this newsgroup is sick of this 'discussion'
| between you and me.
If you _really_ thought so, you should simply have avoided replying. But
you never seem to grasp that anything you say applies to yourself, as if
you are a mindless cretin who just has to respond and can blame someone
else for everything you do. This is actually one of the reasons it is
hard to believe you are not mentally ill. Part of the problem is that
you cannot accept that you do bad things. Tell you what: Only really bad
people have a problem with that. Good people _know_ that they do bad
things now and then. Several religions have this notion of "forgiveness"
(not just Christianity, as Christians believe), and it has a reason:
People who insist on doing only good things, will destroy themselves from
within if they do something bad and cannot rationalize it away or deny it
or somehow come to grips with it. Repentence and forgiveness are very
important for people to stay good, because they would _become_ bad if
they could not "let the air out". Bad people do not admit to their
wrongdoing, because they think it gives away that they are bad people,
but, ironically, they _become_ bad people because they keep it all inside
and _defend_ their bad deeds as good in a sick and warped ethical system
that acts like quicksand: the more people struggle to "always be good",
the quicker and deeper they sink.
| Let's just call it over.
No, no, John, _you_ call it over. Just practice what you preach, for
once. I would really like to see you being able to take an insult and
refrain from replying, because that is what you ask of everybody who
disagrees with you when you insult them and apply that stupid, stupid,
stupid moralistic pressure of yours to other people. It is _so_ stupid
that I wonder if you have actually succumbed to it yourself and think
anyone else is obliged to emulate your spinelessness.
But lest anyone actually be fooled this time: When a person who is down
for the count suggests that the fight be over, he is _still_ the loser.
Anyone who even suggests this, tries to end as an equal because he knows
he would be blown to smithereens if he opened his mouth again. There is
nothing worthwhile in letting pathetic losers who start their articles
with a lot of really stupid insults get away with such a despicable
stunt. They are losers, and they know it. As should everybody else.
| You don't mention or make references to me or and I'll do likewise for
| you.
What an incredibly idiotic "request"! What are you, a fucking retard?
If you want to stop making references to me, that's fine, I guess -- you
seem to enjoy underhanded references that you believe anybody other than
yourself will not see as transparent -- but if you conditionalize this
upon my doing your bidding, you are a psychopath, the worst kind of bully
around, the kind who makes his _victims_ responsible for his evil. Tell
you what, in capital letters just to annoy you: JOHN FODERARO AND ONLY
JOHN FODERARO IS RESPONSIBLE FOR JOHN FODERARO'S ACTIONS. There is
nobody to blame, you irresponsible shithead. But nothing _is_ your fault
in the "real world" you live in, is it? That is why you have defended
yourself with lies and misrepresentations so often, why _you_ need to
point out hypocrisy in others when it would have been a whole lot more
important for everyone involved if you could consider how your _own_
ethics works, and why you need to blame someone else all the time.
If you want to shut up and start behaving like you have a brain, just do
it! No conditions, no announcements, no moralizing, no halos, no heroes.
As long as you try to recover the moral high ground by making it look as
if you tried your best, you have in fact failed to do your best, because
your _best_ is to start behaving as you only say _others_ should, and do
it _right_away_. But what could the satisfaction be in _that_ for a
pathological liar and a hypocritical moralist? Such a person would want
to control only _other_ people's behavior, while he reserves whatever he
desires for himself. Bad guys behave this way. Good guys do not.
| You can show agreement by simply not replying to this post.
Such moronic attempts at bullying! I am led to wonder what the hell kind
of spineless creatures you are used to succeed in bullying around with
this line of argumentation. Who do you think you are dealing with? Or
has this crap _worked_ on you? If so, I _really_ feel sorry for you.
| Then the newsgroup can rest easy.
No, the newsgroup can rest easy when John Foderaro takes his medication
and stops being a fucking retarded moralist on a mission from his deity
to point out hypocrisy and things that are bloody obvious to anything
with a central nervous system, but nobody _cares_ whether anyone is not
100% pure, becauase none of us are! In the "real" world, "real" _people_
are hard to figure out. In your world, they are very easy to figure out,
just like _actions_ are in the real world. This is a clue to people who
have read a little criminology that you _are_ a bad guy. Not caring
about people as _people_ is a core feature of the arrogance that says "my
will is the the only will to consider", which you have _almost_ said in
plain text several times, already.
So you can show agreement with your _own_ views by not replying to this.
That is what I suspect that you simply cannot do. But let me continue
your line of "reasoning" and bullying argumentation a bit, since you seem
to think it works: By replying to this post, you acknowledge that you are
mentally ill and have a severe need for self-affirmation that you do not
get from anyone around you because you regard yourself as the single most
brilliant person to inhabit the entire West coast of the United States.
(If we included the East coast, you would have to think yourself smarter
than Kent Pitman, and even _you_ could not do that. Everybody else will
of course understand that I say this only to test you, since you have
such a penchant for insulting Kent behind his back, another of your least
valuable personality traits.)
Now, let us _really_ see whether this newsgroup can rest easy, or whether
John Foderaro needs help from his remaining friends to avoid embarrassing
himself further. We all understood that your stupid "call for peace" was
a pathetic cop-out after you had run out of arguments, and that you did
not really mean it, you only tried to pretend it was my fault that you
"had to" post yet another idiot response.
What a waste you are, John Foderaro. Once you were worth listening to.
Nowadays it is more important to you to keep publishing if*-infested code
than to help ensure that your credibility is restored, and much more
important to tell the world you have gone postal than to behave well.
The single most important thing you can do is to stop defending yourself.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
To all readers except Erik:
Wow. that was some post wasn't it? Now he's
arguing against proofs, the foundation of science.
>> The desire to "prove" certain claims is simply a desire
>> to move the point of trust to something else, a process that terminates
>> at something that people agree to take for granted
I don't care what Erik thinks. I haven't cared for
a long time but I've made the mistake of trying to
reason with him since I thought that I could get through
to him. With each message he gets further and further
away from reality so that was a bad strategy.
When I asked him for proof of things I wasn't asking
that he turn his messages into some mathematical proof.
I was only asking one simple thing: If he stated
that I said something that he show via a link to
an article on Google where I did that. I only made
that request because he started repeatedly telling
you that I said things that I didn't say.
The link in my last message was to the cap of the
thread where I'd made that request for proof of
those quotes, which of course Erik failed to then
come up with since he had invented the whole
thing inside his head.
I think that all of us say enough things on this
newsgroup to make into an interesting discussion. There's
no need to invent quotes just to argue against.
It's a great disservice to this newsgroup and
it's pure character assasination to continuously
libel someone. Erik desperately needs an enemy to
fight against and if he gets his wish and convinces me
to leave this newsgroup then he may well go after one
of you,so don't think you're safe.
I was able to shut Erik's liess up a few months
ago when Iasked to to prove that I'd said certain things.
Now like a bacteria that's mutated he is back
in a form that's impervious to my requests for
that he prove the quotes he attributes to me.
Now proofs are worthless. What he has in his
mind is correct whether it happened or not.
So all I'm asking is that you realize that what
he states are fact may well be false (and if the facts
are about me there's a 99% chance that they are false
and simply a rhetorical device he'll use to
draw some crazy conclusion).
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214835893672745@naggum.net>
* John Foderaro
| To all readers except Erik:
Thank you for _proving_ that you had _no_ intention of ceasing your
posting. I knew that, everybody else knew that, but now you know it,
too. But do you remember this paragraph in the article you reply to?
By replying to this post, you acknowledge that you are mentally ill and
have a severe need for self-affirmation that you do not get from anyone
around you because you regard yourself as the single most brilliant
person to inhabit the entire West coast of the United States.
Thank you for following up and acknowledging this. I am happy that I was
right about you, once again.
But, geez, pathetic intimidation actually _is_ part of your psyche. I
actually expect to get a "wuz I talkin to you?" back, now.
| Now he's arguing against proofs, the foundation of science.
USENET is a branch of science? *LAUGH* I am arguing against the
applicability of proofs to "win" arguments on USENET, you idiot. That
"technique" is only used for intimidation by the _really_ insane, here.
| I don't care what Erik thinks.
Oh, you pathetic liar.
| I haven't cared for a long time but I've made the mistake of trying to
| reason with him since I thought that I could get through to him.
How is it possible to reason with someone you do not care what thinks?
How would you _know_ if you got through to anyone if you do not care what
they think? _Why_ would you try to reason with someone you do not care
what thinks? This is _so_ stupid and pathetic.
| With each message he gets further and further away from reality so that
| was a bad strategy.
Yup, John Foderaro is the judge of what reality is and not. The insane
have a strong tendency to want to monopolize what can be considered
"reality". Their _only_ claim to living in reality is that they are able
to create it all on their own. Congratulations, John. Good work.
| I was only asking one simple thing: If he stated that I said something
| that he show via a link to an article on Google where I did that.
This is a pretty fascinating request for a person who does not even cite
which news articles he is responding to.
When you do get such references, you just shut up for a while. Everybody
here knows that. It is very, very annoying.
Incidentally, the way we do references on USENET is with message-IDs.
| I only made that request because he started repeatedly telling you that I
| said things that I didn't say.
Really? Where are all the references to articles where I did that?
Should you not have provided a lengthy list of message-IDs that shows all
of this, yet proves absolutely nothing because you are known to omit all
the evidence that goes against your arguments.
| The link in my last message was to the cap of the thread where I'd made
| that request for proof of those quotes, which of course Erik failed to
| then come up with since he had invented the whole thing inside his head.
I would like some references and some proof of this, please. Can you
_prove_ that it was invented inside my head? If not, it is not only some
false crap, it is a disingenious lie, right? And you wanted proof that
you were lying. So now you can either prove what you claim, or accept
that lack of proof means you lie. Because that is what you think a lack
of "proof" means, is it not? Even though this is astonishingly stupid
and anti-scientific, I think it is fun demonstrating that you are not
able to meet the demands you make of others.
| I think that all of us say enough things on this newsgroup to make into
| an interesting discussion. There's no need to invent quotes just to
| argue against.
Then why do you do it? You made a large number of claims that I said
things that I did in fact not say. What was that? For instanace, you
said that I said _you_ could not use the if* stupidity, but what I have
actually and repeatedly said is that publishing code is done not by you,
but by your company. You never replied to that, did you? Just as you
never reply to anything that demonstrates you are wrong.
| It's a great disservice to this newsgroup and it's pure character
| assasination to continuously libel someone. Erik desperately needs an
| enemy to fight against and if he gets his wish and convinces me to leave
| this newsgroup then he may well go after one of you, so don't think
| you're safe.
Funny you should talk about character assasination in that paragraph. I
am beginning to think you are actually so incredibly unconscious that you
fail to understand what you are doing.
| I was able to shut Erik's liess up a few months ago when I asked to to
| prove that I'd said certain things.
You were? Can we have the message-IDs and some other references for
this? And are you sure _you_ were able to do anything at all? You ask
people to prove things all the time, and nobody does, because it is such
a pathetic stunt, but just like an overly mystical person who prays to
his pet rock every night, whatever he prays for has to come true some
day, but there is no causal link. Taking credit for something like that
without proof is so _unscientific_. And USENET is a science, right?
| Now like a bacteria that's mutated he is back in a form that's impervious
| to my requests for that he prove the quotes he attributes to me.
Yes, I am sure you are the only person on the planet who can use Google.
But we do not engage in such childish behavior on USENET, you moron. The
reason you do not get a response to your intimidation is that it is so
fucking stupid that people look at you and wonder what you are made of.
You see, your style of intimidation is incredibly _unintelligent_. It
would be self-destructive for anyone to take you seriously. That is what
you want, obviously, but you are not the lone genius you think you are.
You are in fact quite stupid and considering that you do not figure even
the simplest things out until it is too late, probably not particularly
intelligent, either, just the smartest among those you could intimidate.
Considering that you are unable to read code that uses when and unless
and loop and normal if, people are free to think you have a very limited
intellect, and that the if* stunt is a necessary counter-measure so you
can deal with code not in the _only_ style you can handle. Everybody
else is able to read and deal with code in a variety of styles, but you
are not. What do you think this says about you? You have never thought
about it, have you?
| What he has in his mind is correct whether it happened or not.
No, that is only yourself, John Foderaro. Other people are not like you.
| So all I'm asking is that you realize that what he states are fact may
| well be false (and if the facts are about me there's a 99% chance that
| they are false and simply a rhetorical device he'll use to draw some
| crazy conclusion).
No, that is only yourself, John Foderaro. Other people are not like you.
Thank you again for proving that you had no intention of quitting unless
you could pretend to be on top of things. It is quite amusing to watch
how you lie about wanting to quit. "Let's call it over" is a direct
quote from you, in an article where you, as always, begin by attempting
to insult me. What, precisely, did you _mean_ by "let's call it over"?
I think it means "Let's let the pathetic loser John Foderaro win, pretty
please!".
Now, please let us see you back up your claims with references and
proofs. If you recognize, as I think you actually do, that this is an
intimidation technique and nothing else, which you will acknowledge by
not providing _any_ message-IDs, the time has come to "out" John Foderaro
as a person who is unable to follow his own advice, simply because it is
not advice, it is _only_ his incredibly stupid bullying.
So let's call it over, John. Do not reply to this message. OK? Good.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
····@oscar.eng.cv.net (Marc Spitzer) wrote in message news:<····················@oscar.eng.cv.net>...
[much apologia mercifully elided]
> One question, if I may? Where did you get your PHD? based on your
> skill arguing things it may be a place best avoided if I ever go back
> to school for an advanced degree.
Harvard. However, that's neither a reason to avoid going there, nor a
reason to attend.
You call into question my skill in arguing. Look at the length and
convolution of your posts, then look at mine. To paraphrase
Shakespeare, since brevity is the soul of wit, and tediousness the
limbs and outward flourishes,...be brief.
In article <··························@posting.google.com>,
Raffael Cavallaro wrote:
> ····@oscar.eng.cv.net (Marc Spitzer) wrote in message news:
> <····················@oscar.eng.cv.net>...
>
> [much apologia mercifully elided]
>> One question, if I may? Where did you get your PHD? based on your
>> skill arguing things it may be a place best avoided if I ever go back
>> to school for an advanced degree.
>
> Harvard. However, that's neither a reason to avoid going there, nor a
> reason to attend.
>
> You call into question my skill in arguing. Look at the length and
> convolution of your posts, then look at mine. To paraphrase
> Shakespeare, since brevity is the soul of wit, and tediousness the
> limbs and outward flourishes,...be brief.
first of all who said I was trying to be funny?
Now the way I was taught in grade school was to use a paragraph as a
unit of thought. make your point in the first sentence then support
your point in the following sentences and restate/summerize your point
in the last sentence. And that is what I try to do when I write. The
idea has not changed much as far as I can tell since grade school.
Message-ID: <···················@oscar.eng.cv.net> is about where you
came into this and in our exchange you have tried to run a shell game
rather then have an exchange of ideas. When I make a point that you
do not like you go dig something else up confuse what I said with what
you wanted to hear and go off on a tangent.
What is the point in doing this?
marc
····@oscar.eng.cv.net (Marc Spitzer) wrote in message news:<···················@oscar.eng.cv.net>...
> In article <··························@posting.google.com>,
> Raffael Cavallaro wrote:
> > To paraphrase
> > Shakespeare, since brevity is the soul of wit, and tediousness the
> > limbs and outward flourishes,...be brief.
> first of all who said I was trying to be funny?
You really need a good dictionary. Wit doesn't only mean humor. It
also means "verbal skill, " or "mental agility."
You tend to ramble on extraneous tangents simply because you
misunderstand words (e.g., "wit") or misuse them (e.g., "censor").
In article <····························@posting.google.com>,
Raffael Cavallaro wrote:
> ····@oscar.eng.cv.net (Marc Spitzer) wrote in message
> news:<···················@oscar.eng.cv.net>...
>> In article <··························@posting.google.com>,
>> Raffael Cavallaro wrote:
>
>> > To paraphrase
>> > Shakespeare, since brevity is the soul of wit, and tediousness the
>> > limbs and outward flourishes,...be brief.
>
>> first of all who said I was trying to be funny?
>
> You really need a good dictionary. Wit doesn't only mean humor. It
> also means "verbal skill, " or "mental agility."
>
> You tend to ramble on extraneous tangents simply because you
> misunderstand words (e.g., "wit") or misuse them (e.g., "censor").
I will give you wit, not censor. But again you have ignored the
points I have raised in my previous post trying to have a reasonable
discussion with you about this with you. So here is my wit orented
responce, you are a twit of a troll. Short enough?
marc
····@oscar.eng.cv.net (Marc Spitzer) wrote in message news:<···················@oscar.eng.cv.net>...
> I will give you wit, not censor.
It is not for you to "give" me. Simply consult a dictionary to learn
what the word "censor" means, and why it's use is inappropriate in a
forum where no person can compel the silence of another.
In article <····························@posting.google.com>,
Raffael Cavallaro wrote:
> ····@oscar.eng.cv.net (Marc Spitzer) wrote in message
> news:<···················@oscar.eng.cv.net>...
>
>
>> I will give you wit, not censor.
>
> It is not for you to "give" me. Simply consult a dictionary to learn
> what the word "censor" means, and why it's use is inappropriate in a
> forum where no person can compel the silence of another.
ok you win, it is just not worth it to wast my time when you
clearly do not wnat to have a discussion about anything on
an adult level. Here is the word I will incorrectly use,
the word is 'cat', "cats bark at the moon". now you can
point out to all the world that I abused the word cat and
confused it with the word dog. This gives you the last
word, enjoy it.
marc
John Foderaro <···@xspammerx.franz.com> writes:
> Telling someone to leave (I.e never post again) is a priori censorship.
John, I really don't want to get involved in this discussion generally, but
the term censorship is being abused in this discussion and not just by you.
Please don't take this reply personally; it's intended to speak to people
generally, on both sides of this debate:
In a free speech forum, where people can only say things but not enforce
things, this does not implement censorship.
Censorship is the implementation of making someone leave, not the use of
langauge to hint, cajole, persuade, encourage, trick, or otherwise make
more likely the voluntary choice by another to stand down.
I'm not saying you shouldn't be annoyed when someone tells someone to shut
up. Just please don't pick words that are terminologically incorrect.
It dilutes the very important meaning of that word and makes it less likely
that anyone will realize it's time to care if outright censorship DOES occur.
If saying someone should go away did amount to censorship, many people
would be guilty of having done this to controversial contributors like
John (on one side of this and other debates) and Erik (often on the other)
long ago. But the fact is that both continue to post, and that isn't by
magic. Such continued posting stands as a counterexample to the claim
that censorship is achieved in this way.
(Even boycotting, a stronger phenomenon than is active in this
discussion is not censorship. It is merely a test of wills involving
an in-bound and reasonable show of will on both sides of an issue in a
free society.)
Telling someone to "go away" may be childish, bullyish, rude. It may also
be good advice, helpful, and constructive in a certain way. And sometimes
it can be both at the same time. But it's not censorship.
Just my opinion.
(If you don't like it, feel free to tell me to go away. ;-)
I was simply making the point that if "marc spitzer"
believes that me telling Erik to not post childish
insults was censorship, then certainly "marc spitzer"
telling me to leave and post nothing was also
censorship and even more so. Thus I was showing hypocrisy in
marc spitzer.
I'm with you in saying that you can't succeed
in censoring anyone on an unmoderated newsgroup
without their consent. That's what I was
trying to explain to marc spitzer.
In article <·························@news.dnai.com>, John Foderaro wrote:
> I was simply making the point that if "marc spitzer"
> believes that me telling Erik to not post childish
> insults was censorship, then certainly "marc spitzer"
> telling me to leave and post nothing was also
> censorship and even more so. Thus I was showing hypocrisy in
> marc spitzer.
>
> I'm with you in saying that you can't succeed
> in censoring anyone on an unmoderated newsgroup
> without their consent. That's what I was
> trying to explain to marc spitzer.
>
>
From what I have observed of your behavior here I think that you are
one of the people who think if they shout loud and long enough they
will win because they are the only one left in the room. Now you are
modifying your methoids to appear reasonable instead of loud and
abusive, time to try a different method of building support for your
self and your non to well thought out ideas?
marc
In article <··················@oscar.eng.cv.net>, ····@oscar.eng.cv.net says...
> From what I have observed of your behavior here I think that you are
> one of the people who think if they shout loud and long enough they
> will win because they are the only one left in the room.
Another unsubstantiated claim. Back it up with references to posting
or portions of postings or once again be shown to be a liar.
In article <··························@news.dnai.com>, John Foderaro wrote:
> In article <··················@oscar.eng.cv.net>, ····@oscar.eng.cv.net says...
>> From what I have observed of your behavior here I think that you are
>> one of the people who think if they shout loud and long enough they
>> will win because they are the only one left in the room.
>
> Another unsubstantiated claim. Back it up with references to posting
> or portions of postings or once again be shown to be a liar.
>
>
its all in google.
marc
In article <··························@news.dnai.com>, John Foderaro wrote:
> So I simply state that in my opinion that post
>went overboard.
No kidding, look who it's from. Basically, you are having a pointless
disagreement with someone on Usenet over his literary style---his highly
consistent and predictable style, I might add, which was probably honed
by years of practice, and as such would require considerable undoing.
For all you know, he could be playing a character in order to deliberately
tick you off, and possibly be deriving pleasure from grating on your
nerves.
Also understand that some people find overboard postings extremely
entertaining, and would miss them dearly if some people's censorship
fantasies were realized.
This is (Ab)Usenet! If you want to read some non-offensive,
censored-to-hell, insipid forum, try AOL.
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3213781004040032@naggum.net>
* John Foderaro
| Your response is childish however and is an embarrassment
| to this forum.
John Foderaro, can you _please_ shut up? Your contributions to this
forum are fantastically predictable, exceptionally boring, utterly
useless, nothing more than childish whining, all of them sorry, pathetic
attempts to take revenge over once having lost a debate over your very
silly IF* macro. If you really want to raise the intellectual level in
this newsgroup, _quit_ the idiotic holier-than-thou act and just _do_
what you profess that only _other_ people should do: Post intelligent
articles. I do not think you actually _can_ do that, anymore, which is
why you keep _whining_ instead of _doing_, and which is why _you_ chose
to become an uintelligent moralistic asshole when you were criticized for
being unable to argue your case properly. Attacking your critics does
not make _you_ more intelligent, any more than any of the other morons on
this newsgroup have come out of such attacks with the face actually
saved. And just like every other pathetic moralistic loser on USENET,
you crawl out of the woodwork when a discussion is basically over.
Grow up, John Foderaro. _You_ are still unable to deal with conflict in
a mature way and there is _nothing_ you can teach anyone in this area,
and your extremely annoying and pathetic attacks on me are getting old.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
From: Juliusz Chroboczek
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <87hes6ur38.fsf@pps.jussieu.fr>
Francois-Rene Rideau:
FR> I purported to support the (maybe illusive) idea that there is a usable
FR> portable Common LISP language.
It is most definitely possible to write portable Common Lisp code that
is efficient in one implementation. It is very difficult, and possibly
impossible, to write Common Lisp code that is portably efficient.
X3J13 have made a few half-hearted attempts to make it more likely
that common idioms will generate efficient code, most notably by
giving some guarantees on the fixnum range and by making it possible
to write array-frobbing code using fixnums.
I don't think there is any portable language that enables the writing
of portably efficient code.
Juliusz
Juliusz Chroboczek <···@pps.jussieu.fr> wrote in message news:<··············@pps.jussieu.fr>...
> It is most definitely possible to write portable Common Lisp code that
> is efficient in one implementation. It is very difficult, and possibly
> impossible, to write Common Lisp code that is portably efficient.
I think this is really misleading.
For certain kinds of code, in particular code that does a lot of
low-level bit-twiddling (such as MD5) or code that does a lot of heavy
numerical computation (such as atomic bomb simulations) it is probably
true. It may also be true for code that is very heavily I/O
dominated.
However for a large amount of code which spends its time doing more
typical pointer-chasing and structure manipulation, I think it is
quite possible to write code which is portably efficient in CL. Code
I write which is of this kind has typically fairly small variations
between implementations - perhaps a factor of two or so, not including
CLISP which can often lose badly to native-compiled implementations
(although it can do surpsigingly well). Profiling (on more than one
implementation) doesn't show any awful bottlenecks, and in human terms
performance is pretty good.
Now of course this could be because I write uniformly dreadful code
but machines are so quick it runs OK, but I think that it's not that
bad.
So I think that with some exceptions (and these exceptions are largely
present in any language: ask someone who writes atomic bomb
simulations for a living aout portability and it's quite informative)
it is very possible to write portable, efficient, CL.
--tim
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214224370524670@naggum.net>
* Juliusz Chroboczek
| It is most definitely possible to write portable Common Lisp code that
| is efficient in one implementation. It is very difficult, and possibly
| impossible, to write Common Lisp code that is portably efficient.
Do you think this is because of the implementations or the language? I
think it is because of the implementations and the lack of pressure from
their users to be (more) efficient.
If you write code that is explicit in all its assumptions, a compiler
_should_ be able to produce optimal machine code.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
Erik Naggum <····@naggum.net> writes:
> * Juliusz Chroboczek
> | It is most definitely possible to write portable Common Lisp code that
> | is efficient in one implementation. It is very difficult, and possibly
> | impossible, to write Common Lisp code that is portably efficient.
>
> Do you think this is because of the implementations or the language? I
> think it is because of the implementations and the lack of pressure from
> their users to be (more) efficient.
I don't think this is always the case.
I'm consulting for a company right now that is using clisp a lot. It
seems to be quite efficient in many ways, but since it's byte
compiled, it's hard for it to be compared apples to apples with
non-byte-compiled implementations. Using a system-defined operator
means jumping to C code, which gets really optimized stuff that a user
just can't write (because whole point of the byte code interpreter is
that you can't get to the C level). So, for example, as nearly as I
can tell, a call to a standard CL string-manipulation operator ends up
enormously faster compared to an open-coded inline loop doing calls to
CHAR on carefully type-declared strings, not because it does anything
gross and awful with those calls but because unless the system
literally recognizes that what you are doing is an idiom for a
system-defined function, it can't go out-of-frame and write C code
(where the optimizations you expect could happen).
I think similar issues come up with cache and prefetch issues that may
make things below the abstraction level not visible. And with
vendor-specific OS-level facilities like threads that may (depending
on shallow/deep binding tradeoffs, just for example) optimize some things
at the expense of others. ("No free lunch.")
I ran into this problem in doing Fortran->Lisp translation
http://world.std.com/~pitman/Papers/Fortran-to-Lisp.html
and it effectively came down to the same: if the compiler is restricted
to working from a certain abstraction level up, anything that tickles
the layer below that is going to sometimes work unoptimally.
I think this is, at its core, the reason for Gabriel's "worse is better"
paper series.
> If you write code that is explicit in all its assumptions, a compiler
> _should_ be able to produce optimal machine code.
Some code is kept from being explicit.
Some virtual machines are kept from exploiting this.
Some facilities use "magic" (by which I mean things like the MP package
for multitasking, which can accomplish multiprocessing in CL but can't be
implemented in CL for lack of core functionality).
From: Juliusz Chroboczek
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <87bsidb2iz.fsf@pps.jussieu.fr>
EN> | It is most definitely possible to write portable Common Lisp code that
EN> | is efficient in one implementation. It is very difficult, and possibly
EN> | impossible, to write Common Lisp code that is portably efficient.
Erik Naggum:
EN> Do you think this is because of the implementations or the language?
To a great extent, it is unavoidable in any portable language.
The difference, however, is that most modern implementations of, say,
C, are pretty much identical from the programmer's point of view. In
most cases, C code that is efficient under both gcc/x86 and
SunPro/Sparc will be efficient on all (modern) platforms.
On the other hand, there is much more variety in implementation
strategies for Common Lisp, which makes it much more difficult to
write code that is efficient ``often enough.'' Let alone the issue of
byte-compiled vs. native implementations (already mentioned by Kent),
there are the issues of (off the top of my head) shallow vs. deep
binding, buffered vs. unbuffered streams, size of fixnums, ability to
work on full-word integers, ability to use a ``known call convention''
for functions with a proclaimed type, implementation of catch/throw,
etc.
I hope we all agree that this liberty of implementation is a good
thing; but it means that, in practice, writing portably efficient CL
code is next to impossible. (I am emphatically not speaking of
portable CL code that is efficient in a single implementation.)
Juliusz
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214249058771407@naggum.net>
* Juliusz Chroboczek
| The difference, however, is that most modern implementations of, say, C,
| are pretty much identical from the programmer's point of view. In most
| cases, C code that is efficient under both gcc/x86 and SunPro/Sparc will
| be efficient on all (modern) platforms.
But it is fairly unlikely that C code compiled for both IA32 and SPARC
will be "efficient" in the same way. If you optimize too much for one of
them, it is no longer "efficient" in the other.
I also wonder what "efficient" means to you, and how you determine when
you have achieved it. It is not an absolute term.
As for the use of byte-compiled implementations or code, I completely
fail to see what their impact on this discussion is. If you want your
code to be "efficient", whatever it means, you choose a natively-compiled
implementation, not a byte-code interpreter, so whatever efficiency
issues may be perturbed by the existence of a such an implementation
appear to me completely irrelevant to those who actually seek efficiency.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
From: Juliusz Chroboczek
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <87r8r6tod9.fsf@pps.jussieu.fr>
Erik Naggum:
EN> I also wonder what "efficient" means to you, and how you determine when
EN> you have achieved it. It is not an absolute term.
Fair point. In the context of the discussion started by F.-R. about
implementing MD5, efficient means ``within a factor of 2 of well-writ-
ten, mostly-portable, unsafe C code compiled with maximum optimisation
using a decent C compiler.'' I think that's a fair target for judging
an implementation of a real programming language (be it Common Lisp,
ML, or something else).
Of course, in practice ``efficient'' often means ``fast enough to be
painless on the slowest machine I currently have access to.'' I am
glad to say that every single native-code Common Lisp implementation
is ``efficient'' in that sense for the type of programs I tend to
write.
(Two exceptions to the above: when doing intensive text I/O (e.g. ge-
nerating complex PostScript figures), or when running into problems
with the interaction between the GC and the underlying VM.)
(And yes, I do bind *PRINT-PRETTY* to NIL.)
Juliusz
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> Erik Naggum:
>
> EN> I also wonder what "efficient" means to you, and how you determine when
> EN> you have achieved it. It is not an absolute term.
>
> Fair point. In the context of the discussion started by F.-R. about
> implementing MD5, efficient means ``within a factor of 2 of well-writ-
> ten, mostly-portable, unsafe C code compiled with maximum optimisation
> using a decent C compiler.'' I think that's a fair target for judging
> an implementation of a real programming language (be it Common Lisp,
> ML, or something else).
I'm not going to quible about the utility of such a definition of
effcient. Prompted by a related query from F.-R. on his MD5
implementation on cmucl-help, I have revived a silly implementation I
had done some time ago, and -- incorporating advice and information
contributed by other developers and users on the mailing-list -- tuned
it for CMU CL in such a way that it runs within a factor of 1.15 (on
an UltraSPARC 10) to 1.5 (on an AMD K6-2/550) to the native md5sum
implementations on files of between 40-60 MB in size. Total invested
time is about 4-6 manhours.
The implementation is available from http://www.pmsf.de/pmai/MD5.html
It consists of around 500 LoC and should work in all conforming CL
implementations. Since it uses arithmetic on (unsigned-byte 32)
values, it will only work efficiently in implementations that support
unboxed operation on such values. It could also be tweaked to work
efficiently on implementations, like ACL, that provide unboxed
operation on (signed-byte 32) values. For other implementations it
would probably be preferable to switch to a 16bit implementation
strategy.
So is CL portably efficient? No, the code uses 18 conditionals to use
special CMU CL features for performance or flexibility reasons, and as
told above, it depends on implementations offering unboxed operation
on (unsigned-byte 32), which not many implementations do.
OTOH, it was possible to write a portable MD5 implementation, that
will work on all compliant CL implementations. The standard C
implementation will _break_ on anything that doesn't offer
a 32bit integer type (it doesn't have to, but who cares about
portability when writing in C? Very, very few, IMHE).
I still think that MD5 as defined in RFC 1321 is not a very good
test-case for the portability of efficiency: It is a very simple
program, that heavily depends on modulo 32bit arithmetic and
bit-diddling, to the exclusion of everything else. Normal
applications, even those with heavy numeric parts, don't do this kind
of stuff...
Just take a look at the huge variation in performance of malloc
implementations of various platforms, to see how unportable dynamic
memory performance is across C implementations, something that is far
less the case with CL implementations, in my humble experience.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
> I have revived a silly implementation [of MD5] I had done some time ago,
Thanks a lot. Hopefully, I'll learn from what you did.
[In my final version, I had a total slowness factor of 2.8 as compared to C;
the MD5 transform was rather bummed, but the file buffering had been left
unoptimized and could be much improved. Macrology could also produce a
(unsigned-byte 16) version, but it was even 4 times slower - CMUCL wouldn't
optimize the multiple-value-bind produced by my straightforward macros].
> The standard C implementation will _break_ on anything that doesn't offer
> a 32bit integer type
Modern C standards standardizes such a type, when available.
In C99, #include <stdint.h> uint32_t foo;
The only C targets that don't have 32-bit integer types
are small embedded systems that don't run CL either.
So, for all that matters, this point is moot.
> Just take a look at the huge variation in performance of malloc
> implementations of various platforms, to see how unportable dynamic
> memory performance is across C implementations, something that is far
> less the case with CL implementations, in my humble experience.
Granted. On the other hand, C has plenty of malloc libraries to choose from,
so you can pick one that fits your needs (including Boehm's GC).
For high-level languages, an interesting approach to memory management,
that seems to give the best of both world, is that of the ML-Kit with regions:
the compiler does efficient static allocation where applicable, dynamic
allocation otherwise, seamlessly. It requires static analysis that isn't
possible in CL, though, unless you add lots of declarations (and I'm not
sure the standard declarations suffice). Maybe some LISP implementation
targetting real-time control will pick up on such technology.
Yours freely,
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
Politicians are like diapers: they must be changed often.
And for the same reasons. [Also, adults don't need either of them. -- Far�]
Francois-Rene Rideau <···········@tunes.org> writes:
...
> Granted. On the other hand, C has plenty of malloc libraries to choose from,
> so you can pick one that fits your needs (including Boehm's GC).
> For high-level languages, an interesting approach to memory management,
> that seems to give the best of both world, is that of the ML-Kit with regions:
> the compiler does efficient static allocation where applicable, dynamic
> allocation otherwise, seamlessly. It requires static analysis that isn't
> possible in CL, though, unless you add lots of declarations (and I'm not
> sure the standard declarations suffice). Maybe some LISP implementation
> targetting real-time control will pick up on such technology.
I do not claim to have properly understood the whole of ML-Kit region
allocations, but if I remember correctly, the type information is not
all that relevant to inferring the amount of memory to be
allocated. After all not even ML-kit can guarantee complete static
allocation of memory beforehand. Finally, Siskind was working on very
similar things for his Scheme Stalin compiler.
I take these as a sign that such schemes could be applied to CL, given
time, interest and people devoted to the work (don't look at me! :) )
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> I do not claim to have properly understood the whole of ML-Kit region
> allocations, but if I remember correctly, the type information is not
> all that relevant to inferring the amount of memory to be allocated.
Well, yes and no. The structural aspect (is it a CONS? an instance of such
or such class?) and the usage-pattern aspect (does its lifetime fit into the
extent of such static allocation area?) are mostly orthogonal,
if that's what you mean, although with a wide enough understanding
of the notion of "type", they are part of the same static "type" analysis.
The keyword here is *static*: you can allocate something in a specific area
because you statically know its usage pattern fits and won't be modified.
It is imaginable for many (but not all) optimizations to invent ways to
dynamically revert them, but this involves complex operations with some
non-trivial compiler complexity and runtime space-time costs;
definitely not for the faint of heart, and something that would probably
require an advanced declarative architecture in the compiler so as to
handle the co-production of what is essentially decompilation metadata
(which can be seen as a debugging information formal and complete enough
to allow for automatic exploitation by a runtime decompiler-recompiler)
together with the code for the static-until-modified case.
If anyone knows of a compiler that makes such things easy,
I'm most interested to learn about it.
> After all not even ML-kit can guarantee complete static
> allocation of memory beforehand.
Not for arbitrary programs, of course, since such thing is impossible.
But it sure can guarantee complete static allocation for a large class
of programs, including all those that you would usually write in C, and
allowing the massive use of higher-order functions (and even SML functors)
in a program (and I don't imagine anyone correctly managing static
allocation in C or even C++ in such cases).
> Finally, Siskind was working on very
> similar things for his Scheme Stalin compiler.
Again, the keyword was "static".
However, I grant you that it requiring a special static compiler to
achieve real-time guarantees and GC avoidance in CL applications wouldn't
make it worse than for other language/implementations that require static
compilation anyway.
ThinLisp might be that thing for a CLish languages; I haven't tried
very hard to use it and compare, but it doesn't seem to me it has as
advanced memory allocation techniques as the ML-Kit -
maybe some path to explore for the implementors?
PS: the ML-Kit and relevant papers can be found on
http://www.it-c.dk/research/mlkit/
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
If the WTO were really for free trade, the WTO Charter would consist of one
sentence: 'Let there be free trade.'
Juliusz Chroboczek <···@pps.jussieu.fr> wrote in message news:<··············@pps.jussieu.fr>...
>
> The difference, however, is that most modern implementations of, say,
> C, are pretty much identical from the programmer's point of view. In
> most cases, C code that is efficient under both gcc/x86 and
> SunPro/Sparc will be efficient on all (modern) platforms.
Again, I have to disagree with this, or at least qualify it. It is
probably
true for the kinds of trivial integer/float benchmarks that are all
people tend to look at (and it probably *isn't* true for the Lisp
equivalents of these same benchmarks, which is why people get so hung
up on this). Sure, C is portably efficient for a program which sums
the integers from 1 to 10^6, or one that does some simple-minded
floating-point computation. But is it portably efficient for, say,
large array-bashing code which represents the kind of things people do
in the real world that can be mapped efficiently onto machine
resources? I suspect it really isn't - you need to know a whole load
of stuff about really low-level details like what floating-point
registers there are and how big cache lines are and all sorts of
really obscure things. In fact I suspect that *no* language is
portably efficient at that level.
And again for the more common kinds of programs (in C as well as Lisp)
that do complex data structure bashing and lots of pointer chasing,
and other operations which don't map trivially onto machine
operations, the performance tends to be dominated by algorithms rather
than by some low level question of implementation.
Of course there are counterexamples - md5 might be one (though I
question its portability in C since it depends very much on integer
sizes and so on). But I've written a fair amount of CL and by *far*
the overwelming problems with my programs are algorithmic deficiencies
and just plain bad design, with the sole exception of I/O. I/O is a
sore point, because it's traditionally been rotten in Lisp, although I
think the situation is much better now. However I would be *really*
surprised if I/O is portably good in any language: this is the kind of
thing that serious people spend a *lot* of time tuning per platform.
For small machines, of course, the problem has mostly gone away (even
in Lisp) since the machine is almost always I/O (and memory-bandwidth)
starved to the extent that it's hard for a program to not beat the
disk. For large machines where I/O is closer to keeping up you have
to tune *extensively* anyway.
--tim
··········@tfeb.org (Tim Bradshaw) writes:
> Juliusz Chroboczek <···@pps.jussieu.fr> wrote in message news:<··············@pps.jussieu.fr>...
>
> > The difference, however, is that most modern implementations of, say,
> > C, are pretty much identical from the programmer's point of view. In
> > most cases, C code that is efficient under both gcc/x86 and
> > SunPro/Sparc will be efficient on all (modern) platforms.
>
> Again, I have to disagree with this, or at least qualify it. It is
> probably
> true for the kinds of trivial integer/float benchmarks that are all
> people tend to look at (and it probably *isn't* true for the Lisp
> equivalents of these same benchmarks, which is why people get so hung
> up on this). Sure, C is portably efficient for a program which sums
> the integers from 1 to 10^6, or one that does some simple-minded
> floating-point computation. But is it portably efficient for, say,
> large array-bashing code which represents the kind of things people do
> in the real world that can be mapped efficiently onto machine
> resources? I suspect it really isn't - you need to know a whole load
> of stuff about really low-level details like what floating-point
> registers there are and how big cache lines are and all sorts of
> really obscure things. In fact I suspect that *no* language is
> portably efficient at that level.
I find it really strange that people claim C to be portable, because
who actually writes portable C code? Sure, I'll sometimes write code
that I intend to be compilable by a wide range of C compilers, but if
I'm at all concerned about efficiency, or representation in memory,
that's pretty much out the window. Many of the C programers I've seen
dig through the compiler documentation, look at disassemblies, poke
around the program in the debugger, etc, looking for ways to make the
program a better fit for the hardware. That's fundamentally
unportable. Some things are written in such a way that they make life
easier for porters, but how many serious C programs can you drop in a
new compiler/OS/architecture, and just compile, unchanged?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Juliusz Chroboczek
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <87n11utlnl.fsf@pps.jussieu.fr>
I've reordered your comments.
Tim Bradshaw:
TB> And again for the more common kinds of programs (in C as well as
TB> Lisp) that do complex data structure bashing and lots of pointer
TB> chasing, and other operations which don't map trivially onto
TB> machine operations, the performance tends to be dominated by
TB> algorithms rather than by some low level question of
TB> implementation.
I think you're changing the domain of discourse here. The original
issue, as raised by F.-R., was whether it is possible to write Common
Lisp code that is in the same ballpark as C, for the particular class
of problems that C is good at. I'm arguing that this is sometimes
difficult.
I am not arguing whether this is significant -- in fact, I am more
than happy with the performance of all of CMU, ACL and LW[1] on the
type of programs that I tend to write, and even CLISP is usually good
enough.
TB> Of course there are counterexamples - md5 might be one (though I
TB> question its portability in C since it depends very much on
TB> integer sizes and so on).
I fully agree -- whence my insistence on ``modern architectures'',
which tend to have pretty uniform integer sizes.
#if (sizeof(unsigned) < 32)
#error "Please buy a new PC"
#endif
TB> But is it portably efficient for, say, large array-bashing code
TB> which represents the kind of things people do in the real world
TB> that can be mapped efficiently onto machine resources? I suspect
TB> it really isn't - you need to know a whole load of stuff about
TB> really low-level details like what floating-point registers there
TB> are and how big cache lines are and all sorts of really obscure
TB> things.
Floating-point code (which I'm not competent to discuss) put aside,
though, on most modern machines micro-optimisation consists in minimi-
sing the number of non-local memory accesses. While the precise defi-
nition of ``non-local'' is hardware-dependent, you won't go wildly
wrong by minimising memory accesses in your code.
In C, I know exactly how an ``unsigned[1024 * 1024]'' is going to be
laid-out, and that accessing an element will cost exactly one memory
access. There is no portable way in Common Lisp to ensure that any
form of array-bashing code will not be doing non-local pointer chasing
-- I have to know whether my implementation is going to specialise for
the type of simple-vector element I happen to be manipulating.
To be fair, though, all the implementations I know do specialise for
BIT, FIXNUM, and (UNSIGNED-BYTE 32), which turns out to be good enough
for the type of code that I tend to write.
Another sore point is that there is simply no way in any Common Lisp
implementation that I know to manipulate an array of structures (as
opposed to an array of references to structures). Thus, you either
pay an extra memory reference per element field access, or use a
structure of specialised arrays (together with some macrology), which
does minimise the number of accesses but perturbs their locality.
Juliusz
[1] One thing that annoys me with both commercial implementations is
the fact that by default they produce incorrect code when SPEED=3 and
SAFETY=0: they silently assume that the result of an arithmetic
operation on fixnums operation is going to be a fixnum. You can turn
this ``feature'' off, of course.
Juliusz Chroboczek wrote:
> The difference, however, is that most modern implementations of, say,
> C, are pretty much identical from the programmer's point of view. In
> most cases, C code that is efficient under both gcc/x86 and
> SunPro/Sparc will be efficient on all (modern) platforms.
Uhhh? If C is so portable, why is there configure, automake,
autoconf and/or makemake and xmake and the whole smeary mess of
bodging make files to work on different platforms?
Even within a single implementation of c, gcc say, to get stuff to
build you need to spend 10 minutes running scripts to ferret around
and find out what is the state of the system (sic).
:)w
From: Friedrich Dominicus
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <87d72o9vat.fsf@frown.here>
Will Deakin <···········@hotmail.com> writes:
> Juliusz Chroboczek wrote:
>
> > The difference, however, is that most modern implementations of, say,
> > C, are pretty much identical from the programmer's point of view. In
> > most cases, C code that is efficient under both gcc/x86 and
> > SunPro/Sparc will be efficient on all (modern) platforms.
>
> Uhhh? If C is so portable, why is there configure, automake, autoconf
> and/or makemake and xmake and the whole smeary mess of bodging make
> files to work on different platforms?
Well I think one can not blame for it. But the bunch of libraries. If
I used e.g GTK+ this is not standardized so it has to be checked. If
you were able to stick to C entirely there won't be the need for such
tools.
>
>
> Even within a single implementation of c, gcc say, to get stuff to
> build you need to spend 10 minutes running scripts to ferret around
> and find out what is the state of the system (sic).
Well isn't it nice that there are such tools? Guess if something
simular would exist for Common Lisp...
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Will Deakin <···········@hotmail.com> writes:
>
> > Uhhh? If C is so portable, why is there configure, automake, autoconf
> > and/or makemake and xmake and the whole smeary mess of bodging make
> > files to work on different platforms?
> Well I think one can not blame for it. But the bunch of libraries. If
> I used e.g GTK+ this is not standardized so it has to be checked. If
> you were able to stick to C entirely there won't be the need for such
> tools.
No one would complain if it was only such inherently problematic
components as GUI toolkits, etc. But autoconf and friends were
invented to solve much more low-level problems, namely the large
differences in C runtime libraries, even within one OS family, namely
Unix and friends.
So yes, if you are able to stick to C entirely (possibly even
excluding standard mandated stuff in the support libs), then you will
be fairly portable, except of course that you still can't write MD5
portably, since you still don't know how to specify that you want to
work on 32bit integers (is it unsigned int, or unsigned long, or both
or neither). And you can't write anything that does more interesting
things than MD5, since that brings you into the land of OS and libc-
dependencies.
At least Common Lisp allows you to write MD5 portably, even if not
portably efficient.
> > Even within a single implementation of c, gcc say, to get stuff to
> > build you need to spend 10 minutes running scripts to ferret around
> > and find out what is the state of the system (sic).
> Well isn't it nice that there are such tools? Guess if something
> simular would exist for Common Lisp...
For most things it does: It is called the vendor or implementor of
your Common Lisp implementation, who has the unenviable task of taking
all the randomized crap that is called an API (implementation) today,
and presenting to you a half-way sane and portable interface to the
underlying functionality, either as part of the ANSI CL part of his
implementation, or as part of extended functionality.
It isn't differences like CAPI vs. Common Graphics that autoconf and
friends were designed to handle (they can't), but differences like
"which libraries are needed to get access to BSD sockets, without
breaking other stuff", "in which order do we need to link those
libaries", "which header contains which of 10 variants for a certain
flag we need", etc. Consider the following very small excerpt from a
real-life configure script:
# ······@skyler.mavd.honeywell.com says without -lsocket,
# socket/setsockopt and other routines are undefined under SCO ODT
# 2.0. But -lsocket is broken on IRIX 5.2 (and is not necessary
# on later versions), says ·····@lia.di.epfl.ch: it contains
# gethostby* variants that don't use the nameserver (or something).
# -lsocket must be given before -lnsl if both are needed.
# We assume that if connect needs -lnsl, so does gethostbyname.
echo $ac_n "checking for connect""... $ac_c" 1>&6
And this is but the comment of one of several tens of tests only to
get access to the correct versions of connect, gethostbyname, etc. on
the various Unices that purport to implement BSD sockets. And that's
just purely syntactical differences on Unix. Then go talk to one of
the Netscape engineers who had to make all of the differences in
semantics and syntax disappear on X versions of Unix and Windows and
the Mac...
Now take a look at the socket interface presented to you by your
vendor, or even the 5 socket interfaces presented to you by all
vendors, and be very happy...
For example our in-house HTTP/1.0+ server code base, which only
comprises HTTP-related functionality[1], no HTML-specific stuff, etc.,
weighs in at 4KLoC, yet it has remained portable to any ANSI CL
implementation that offers access to sockets connections via streams,
and offers some form of MP. Of the 4KLoC code base, only 200 LoC are
implementation dependent, which comes out to around 50 LoC for each
supported implementation.
It should now become apparent that we don't _need_ autoconf and
friends, and lucky we are that we don't.
Regs, Pierre.
Footnotes:
[1] Including full MIME support, including lazy MIME/multipart
handling, but excluding HTML generation or parsing stuff, or
anything else content-related.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Erik Naggum
Subject: Re: MD5 in LISP and abstraction inversions
Date:
Message-ID: <3214573728375953@naggum.net>
* Will Deakin
| Uhhh? If C is so portable, why is there configure, automake, autoconf
| and/or makemake and xmake and the whole smeary mess of bodging make files
| to work on different platforms?
But those tools are precisely what makes C portable. Ironic, eh?
No responsible Open Source programmer fails to take these tools into
account when programming. Writing fully portable code using these tools
is considered the mark of a conscientious, caring, professional C author.
It takes great effort, but in the end, it is worth it because the whole
Open Source world has actually learned to cope with its portability
issues. In the Common Lisp world, however, at least one Open Source
author thinks conscientiousness, caring, and professionality is a waste
of his presumably exceptionally precious time. I find this very sad, but
more, an insult to the community. Caring about one's own values is good,
but when it means not caring about those of others, it becomes bad, and
one has to wonder what the purpose of "sharing" code really is.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
On Thu, 01 Nov 2001 15:30:22 GMT, Erik Naggum wrote:
> | Once again, reading their specification, I happen to like the recent
> | things done by Franz (SIMPLE-STREAM), but it's unhappily not directly
> | applicable to me.
> Well, what makes it impossible for you to take their good ideas and
> implement them on your own?
Oh well, I guess it's a good time to announce that I'm implementing
simple-streams for CMUCL. It's far from usable as yet, but I'll put
something on http://www.actrix.gen.nz/users/mycroft/cl.html over the
weekend. If anyone wants to help out, please let me know.
--
The power of accurate observation is commonly called cynicism by those
who have not got it.
-- George Bernard Shaw
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
From: Duane Rettig
Subject: Re: simple-streams for CMUCL [Re: MD5 in LISP and abstraction inversions]
Date:
Message-ID: <44roern80.fsf@beta.franz.com>
Paul Foley <·······@actrix.gen.nz> writes:
> On Thu, 01 Nov 2001 15:30:22 GMT, Erik Naggum wrote:
>
> > | Once again, reading their specification, I happen to like the recent
> > | things done by Franz (SIMPLE-STREAM), but it's unhappily not directly
> > | applicable to me.
>
> > Well, what makes it impossible for you to take their good ideas and
> > implement them on your own?
>
> Oh well, I guess it's a good time to announce that I'm implementing
> simple-streams for CMUCL. It's far from usable as yet, but I'll put
> something on http://www.actrix.gen.nz/users/mycroft/cl.html over the
> weekend. If anyone wants to help out, please let me know.
Thanks, Paul, for stepping up to this task. Too bad we will just miss each
other while I am on vacation down-under. :-(
(Paul and I have been discussing his implementation over the past month or
so, and he has made very quick progress on it. He has had advance access
to our 6.1 streams document, and that is now available on our website. I
also have a chapter on encapsulation which should become available in
a new version of that document, once it has been massaged by our
docuentation expert. Look for the new version within a week.)
--
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 ·····@Franz.COM (internet)
From: Paul Foley
Subject: Re: simple-streams for CMUCL [Re: MD5 in LISP and abstraction inversions]
Date:
Message-ID: <m2itcrhwma.fsf@mycroft.actrix.gen.nz>
On 02 Nov 2001 13:34:25 +1300, I wrote:
> Oh well, I guess it's a good time to announce that I'm implementing
> simple-streams for CMUCL. It's far from usable as yet, but I'll put
> something on http://www.actrix.gen.nz/users/mycroft/cl.html over the
> weekend. If anyone wants to help out, please let me know.
As promised, this is now available.
--
C/C++/Java/Perl/etc are for people who want to make things that work.
Common Lisp is for people who want to make things that don't break.
-- Erik Naggum
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
In article <··············@Samaris.tunes.org>, Francois-Rene Rideau wrote:
>I was looking for a Common LISP implementation of MD5, but found none.
What a coincidence! It happens that earlier today, I typed ``md5.lisp''
into Google and it came up with this:
http://www.ai.mit.edu/people/naha/ftp/Cryptography/
>So I wrote a silly port of MD5 in CL.
> ftp://Samaris.tunes.org/pub/lang/cl/fare/md5.lisp
>On CMUCL, the result runs about 5.5 times slower than the equivalent optimized
>C code; that said, on CMUCL, it can also call the external md5sum utility
By the way, is this C code maximally portable ISO C? Let's see it.
>for fast processing of large files or streams.
>It purports to abide by (and extend) the MD5 interface defined in ACL6.
>
>Excellent things that helped: CL macros.
>Horrible things that get in the way: CL characters,
>and lack of builtin modular operators.
What modular operators are missing? The standard truncate function returns
an integer quotient and remainder. The logand function can be used
as a means of reduce modulo a power of two: (logand #xABCD #xFF) ==> #xCD
Looking at your code, I think I understand what you mean. In some places
in the computation, it's necessary to reduce a result modulo #x100000000.
This is because the algorithm is defined in terms of machine arithmetic,
specifically to be efficiently impementable in machine languages.
Note that a C program which assumes the presence of a type that is
exactly 32 bits wide is not maximally portable, so if you rely on
the addition of two unsigned longs, for instance, to do the
reduction for you, your code is not portable. In maximally portable
C, you have to do the & 0xFFFFFFFF operation to reduce a result
modulo 32 bits.
···@ashi.footprints.net (Kaz Kylheku) writes:
> What a coincidence! It happens that earlier today, I typed ``md5.lisp''
> into Google and it came up with this:
>
> http://www.ai.mit.edu/people/naha/ftp/Cryptography/
>
Nice. I didn't try this combination in Google.
Anyway, what gives is the MD5 implementation from CL-HTTP.
I had forgotten about that one. Still, I can't use it because of license
problems and prefer to write code than grovel to have licenses changed
(it seems that whatever you do, people will diss you for it).
Thanks for the tip, though.
> By the way, is this C code maximally portable ISO C? Let's see it.
The md5.c file I had, a derivative of the reference implementation,
was the fairly portable one used in Erlang.
I don't remember if ISO C mandates two's complement arithmetics
(the earlier standard didn't; I remember rumors that this one does).
If it does, then it is maximally portable. If not, then indeed
it requires and'ing with 0xFFFFFFF (which in practice is optimized
away by all C compilers that matter).
That said, since the 1980's, 99.99% of the world have standardized
on hardware that does two-complement 8/16/32/64 bit arithmetics.
The only recent exception I know is Chuck Moore's F21
(20/21-bit two-complement architecture). Even an Ivory LISPM
has 32-bit fixnums. (Followup-To: comp.arch ?).
Moreover, various formal and informal standards that extend the ISO C
standard mandate 32-bit types. In other words, the world isn't just
the work of one committee - it's what everyone does.
Well, in the CL world, there is no more committee, and implementations
don't support any standard for modular arithmetics.
> What modular operators are missing? The standard truncate function returns
> an integer quotient and remainder. The logand function can be used
> as a means of reduce modulo a power of two: (logand #xABCD #xFF) ==> #xCD
Yes, and "I could also do the same even with a Turing machine".
The question was one of builtin support for efficient such operators.
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
"Sometimes it is said that man cannot be trusted with the government
of himself. Can he, then, be trusted with the government of others?
Or have we found angels in the forms of kings to govern him?
Let history answer this question."
-- Thomas Jefferson, First Inaugural Address