Brian wrote:
> Ken Tilton wrote:
>
>>Damn language.
>>
>>kenny
>
> Isn't that half the fun?
I just think my damn compiler has an obligation to tell me when I am
reinventing the damn wheel! I bet Lispworks does! Or SBCL for sure,
those yobbos are solving important problems like that all the time!! But
Franz? Noooooooo!
Maybe if they used Cells....
kenny
ps. Hard to believe, but it turns out I found logbitp on the verge of
only the second reinvention, prolly the Franz text search doesn't work
either...which brings me to my point, the Great Flaw in the CLHS:
someone accidentally deleted all the meticulously chosen "see also"
references and no one had a backup. Always back up! Where was I...
k
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton <···········@optonline.net> writes:
> Brian wrote:
>> Ken Tilton wrote:
>>
>>>Damn language.
>>>
>>>kenny
>> Isn't that half the fun?
>
> I just think my damn compiler has an obligation to tell me when I am
> reinventing the damn wheel! I bet Lispworks does! Or SBCL for sure,
> those yobbos are solving important problems like that all the time!!
> But Franz? Noooooooo!
Before you get your pantyhose in a bind, have a little patience; I
finally found a way to use CL's dwim function as a building block to
write the wmpfm function, which will write my program for me. Of
course, once it's released, you may have trouble using it, I haven't
figured out how to extend it to the much more complex wypfy function.
And oh, by the way, I'm taking lessons from pg about naming...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: Why wasn't I told about logbitp?!
Date:
Message-ID: <rem-2008may09-001@yahoo.com>
> From: Ken Tilton <···········@optonline.net>
> I just think my damn compiler has an obligation to tell me when I
> am reinventing the damn wheel!
There's a Web site that recognizes sequences of integers, such as
fibonacci numbers or prime numbers etc. You give it the first
several elements of a sequence and it tells you any sequences it
knows that starts with that initial segment.
There's anotehr Web site that recognizes real numbers, such as pi
or sqrt(2). You give it an approximate value and it shows you all
values it knows about which are similar enough to what you gave.
(Sorry, I didn't bookmark the URLs for them.)
Maybe you would like a Web site that recognizes functions. You feed
it a function definition, and it tries various parameters into it
and compares the results with the results known functions for the
same parameters until it figures out whether there is any function
that matches your function for enough inputs to give high
confidence it's the same function. It then compares your function
definition with the definition of the standard function to try to
prove they are mathematically equivalent or generate a
counterexample.
> I bet Lispworks does! Or SBCL for sure, those yobbos are solving
> important problems like that all the time!! But Franz? Noooooooo!
Maybe you can interface one of those to the Web so that anyone in
the world can submit a function to compare with known functions?
> I found logbitp on the verge of only the second reinvention,
I found logbitp in CLtL1, in the section on "Logical Operations
on Numbers" (pages 220-225). Note the key phrase on page 221:
"This method of using integers to represent bit-vectors ..."
That's an example of an intentional data type,
internally integers but intentionally bit-vectors.
(Actually at the machine level it's the other way around!
RAM has nothing but octets of bits. It's the CPU that has
some instructions that interpret octets of bits as integers,
and other instructions that interpret those same octets of
bits as device control codes, and other instructions that
interpret those same octets of bits as floating point values,
and other instructions that treat each octet as two BCD digits,
and other instructions that really do treat octets as bit-vectors.)
From: Kent M Pitman
Subject: Re: Why wasn't I told about logbitp?!
Date:
Message-ID: <ud4nwax6i.fsf@nhplace.com>
Ken Tilton <···········@optonline.net> writes:
> Brian wrote:
> > Ken Tilton wrote:
> >
> >>Damn language.
> >>
> >>kenny
> > Isn't that half the fun?
>
> I just think my damn compiler has an obligation to tell me when I am
> reinventing the damn wheel! I bet Lispworks does! Or SBCL for sure,
> those yobbos are solving important problems like that all the time!!
> But Franz? Noooooooo!
>
> Maybe if they used Cells....
>
> kenny
>
> ps. Hard to believe, but it turns out I found logbitp on the verge of
> only the second reinvention, prolly the Franz text search doesn't work
> either...which brings me to my point, the Great Flaw in the CLHS:
> someone accidentally deleted all the meticulously chosen "see also"
> references and no one had a backup. Always back up! Where was I...
Oops. Sorry about that.
The Notes on LOGAND (just below the See Also) are full of LOGBITP
tidbits that should be on the LOGBITP page. Can't have everything.
Part of your problem, in CLHS at least, may be that the permuted index
was faked out by the fact that the name wasn't LOG-BIT-P or even
LOGICAL-BIT-P... so if you look under "B" there is not entry for it
under "bit". Then again, I know you like short, incomprehensible
names, so maybe you'd have hated a name like LOG-BIT-P or
LOGICAL-BIT-P, and maybe you count the scrunched name as a victory, and
you should get used to itty bitty names hiding places you don't see them.
Maybe the real bug is that more of the language isn't all mashed
together because then I would have had no choice but to write
heuristics to decipher that kind of silliness, whereas given that most
functions have reasonable names, I was able to mostly indulge the
fiction that I could get away with treating the hyphens as morpheme
breaks.
After all, if the forces of long names were allowed to have their way,
instead of writing THIRD we'd all be writing
CONTENTS-OF-ADDRESS-DECREMENT-DECREMENT-REGISTER.
;)
> Ken Tilton <···········@optonline.net> writes:
> > Brian wrote:
> > > Ken Tilton wrote:
>
> > >>Damn language.
>
> > >>kenny
> > > Isn't that half the fun?
>
> > I just think my damn compiler has an obligation to tell me when I am
> > reinventing the damn wheel! I bet Lispworks does! Or SBCL for sure,
> > those yobbos are solving important problems like that all the time!!
> > But Franz? Noooooooo!
>
> > Maybe if they used Cells....
It was probably a bug in the mind-reading pass of the compiler. It
thought you were writing (not (zerop (ldb (byte ... because typing is
fun; you should report it.
> > ps. Hard to believe, but it turns out I found logbitp on the verge of
> > only the second reinvention, prolly the Franz text search doesn't work
> > either...which brings me to my point, the Great Flaw in the CLHS:
> > someone accidentally deleted all the meticulously chosen "see also"
> > references and no one had a backup. Always back up! Where was I...
You beat me, I only discovered logbitp last year, after zillions (or
crillions, not sure) of binary-parsing and binary-protocol-producing
programs ... writing I don't want to think how many functions named
things like bit-bool.
On May 9, 7:00 am, Kent M Pitman <······@nhplace.com> wrote:
> Oops. Sorry about that.
>
> The Notes on LOGAND (just below the See Also) are full of LOGBITP
> tidbits that should be on the LOGBITP page. Can't have everything.
If you want to see the reference that threw me, check out the page for
ldb. While it's true that logbitp is mentioned there ... oy vey.
Thomas F. Burdick wrote:
>>Ken Tilton <···········@optonline.net> writes:
>>
>
>>>ps. Hard to believe, but it turns out I found logbitp on the verge of
>>>only the second reinvention, prolly the Franz text search doesn't work
>>>either...which brings me to my point, the Great Flaw in the CLHS:
>>>someone accidentally deleted all the meticulously chosen "see also"
>>>references and no one had a backup. Always back up! Where was I...
>
>
> You beat me, I only discovered logbitp last year, after zillions (or
> crillions, not sure) of binary-parsing and binary-protocol-producing
> programs ... writing I don't want to think how many functions named
> things like bit-bool.
The million dollar question being did you then go back and port your
software to the built-ins?
So how was my summary of your Cells application? Last two minutes of the
second vid below.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On 9 mai, 13:12, Ken Tilton <···········@optonline.net> wrote:
> Thomas F. Burdick wrote:
> >>Ken Tilton <···········@optonline.net> writes:
>
> >>>ps. Hard to believe, but it turns out I found logbitp on the verge of
> >>>only the second reinvention, prolly the Franz text search doesn't work
> >>>either...which brings me to my point, the Great Flaw in the CLHS:
> >>>someone accidentally deleted all the meticulously chosen "see also"
> >>>references and no one had a backup. Always back up! Where was I...
>
> > You beat me, I only discovered logbitp last year, after zillions (or
> > crillions, not sure) of binary-parsing and binary-protocol-producing
> > programs ... writing I don't want to think how many functions named
> > things like bit-bool.
>
> The million dollar question being did you then go back and port your
> software to the built-ins?
Yikes, no way! If/when I go back and mess with those apps and need to
change the layer that uses logbitp-equivalents I'd change em.
> So how was my summary of your Cells application? Last two minutes of the
> second vid below.
For rant-level accuracy, not bad, and more entertaining than if I were
to explain it. I'd just note that the type inferencer was but one
pass in throwing things into the graph representing What We Know About
This Program -- it just happened to be the one that ran into Cells-
related problems[*].
Incidentally, only someone who doesn't have much experience with
compiler code or with Cells-like things would think that compiler-like
things[**] would think that compiler writers don't need Cells. A
shocking amount of code is spent either very carefully translating one
data representation into another, translating one representation into
a different version of the same (in the case of functional code) or
carefully editing a representation. All these involve a lot of need
to correctly obey the right conventions and constraints in code that's
scattered everywhere. And guess where a lot of bugs come from? Ever
since KR I couldn't imagine wanting to do that by hand.
[*] which I was able to work around. Incidentally, Cells III, or any
other system using the same concepts, are now *really* well adapted to
problems like type inferencing.
[**] what I was doing wasn't writing a conventional compiler, but it
certainly used compiler techniques en masse
Thomas F. Burdick wrote:
> On 9 mai, 13:12, Ken Tilton <···········@optonline.net> wrote:
>
>>Thomas F. Burdick wrote:
>>
>>>>Ken Tilton <···········@optonline.net> writes:
>>
>>>>>ps. Hard to believe, but it turns out I found logbitp on the verge of
>>>>>only the second reinvention, prolly the Franz text search doesn't work
>>>>>either...which brings me to my point, the Great Flaw in the CLHS:
>>>>>someone accidentally deleted all the meticulously chosen "see also"
>>>>>references and no one had a backup. Always back up! Where was I...
>>
>>>You beat me, I only discovered logbitp last year, after zillions (or
>>>crillions, not sure) of binary-parsing and binary-protocol-producing
>>>programs ... writing I don't want to think how many functions named
>>>things like bit-bool.
>>
>>The million dollar question being did you then go back and port your
>>software to the built-ins?
>
>
> Yikes, no way! If/when I go back and mess with those apps and need to
> change the layer that uses logbitp-equivalents I'd change em.
>
>
>>So how was my summary of your Cells application? Last two minutes of the
>>second vid below.
>
>
> For rant-level accuracy, not bad, and more entertaining than if I were
> to explain it.
Whew!
> I'd just note that the type inferencer was but one
> pass in throwing things into the graph representing What We Know About
> This Program -- it just happened to be the one that ran into Cells-
> related problems[*].
>
> Incidentally, only someone who doesn't have much experience with
> compiler code ...
Hellooooooo Kenny!
....or with Cells-like things would think that compiler-like
> things[**] would think that compiler writers don't need Cells. A
> shocking amount of code is spent either very carefully translating one
> data representation into another, translating one representation into
> a different version of the same (in the case of functional code) or
> carefully editing a representation. All these involve a lot of need
> to correctly obey the right conventions and constraints in code that's
> scattered everywhere. And guess where a lot of bugs come from? Ever
> since KR I couldn't imagine wanting to do that by hand.
>
> [*] which I was able to work around. Incidentally, Cells III, or any
> other system using the same concepts, are now *really* well adapted to
> problems like type inferencing.
>
> [**] what I was doing wasn't writing a conventional compiler, but it
> certainly used compiler techniques en masse
I have struck out twice now on the cloning of an arbitrary problem from
its solution and have fallen back on Just Generating Random practice the
tedious but finite Old-Fashioned Hardcoded Way, but my beach work and
reflecting on your deal had me wondering if a similar "throw in info
until it knows what to do" approach might work. Next time around (I
/really/ want to do what I did as a tutor when the student got stuck
mid-way in their own problem and simple hints did not work, viz., make
up a different problem with all the salient features of the point at
which they got stuck and show them how I solve that.
But Paul Graham's essay rationalizing the crappiness of Arc has
encouraged me to stop sweating perfection and Just Ship Something.
Anyway, I have to get over to #lisp IRC now and tell the SBCL yobbos
about Cells. If you never hear from me again...
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton escribi�:
>
> But Paul Graham's essay rationalizing the crappiness of Arc has
> encouraged me to stop sweating perfection and Just Ship Something.
>
Kenny, would you please post a link (or at least the name) to that essay?
Thanks,
Leandro
Leandro Rios wrote:
> Ken Tilton escribi�:
>
>>
>> But Paul Graham's essay rationalizing the crappiness of Arc has
>> encouraged me to stop sweating perfection and Just Ship Something.
>>
>
> Kenny, would you please post a link (or at least the name) to that essay?
http://www.paulgraham.com/newthings.html
Look for the punch-line mid-way thru:
"Now people are saying the same things about Arc that they said at
first about Viaweb and Y Combinator and most of my essays. Why the
pattern? The answer, I realized, is that my m.o. for all four has been
the same.
"Here it is: I like to find (a) simple solutions (b) to overlooked
problems (c) that actually need to be solved, and (d) deliver them as
informally as possible, (e) starting with a very crude version 1, then
(f) iterating rapidly."
kzo
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton escribi�:
>
>
> Leandro Rios wrote:
>> Ken Tilton escribi�:
>>
>>>
>>> But Paul Graham's essay rationalizing the crappiness of Arc has
>>> encouraged me to stop sweating perfection and Just Ship Something.
>>>
>>
>> Kenny, would you please post a link (or at least the name) to that essay?
>
> http://www.paulgraham.com/newthings.html
>
> Look for the punch-line mid-way thru:
>
> "Now people are saying the same things about Arc that they said at
> first about Viaweb and Y Combinator and most of my essays. Why the
> pattern? The answer, I realized, is that my m.o. for all four has been
> the same.
>
> "Here it is: I like to find (a) simple solutions (b) to overlooked
> problems (c) that actually need to be solved, and (d) deliver them as
> informally as possible, (e) starting with a very crude version 1, then
> (f) iterating rapidly."
>
> kzo
>
Thanks!
Leandro
Ken Tilton wrote:
>
>
> Leandro Rios wrote:
>> Ken Tilton escribi�:
>>
>>>
>>> But Paul Graham's essay rationalizing the crappiness of Arc has
>>> encouraged me to stop sweating perfection and Just Ship Something.
>>>
>>
>> Kenny, would you please post a link (or at least the name) to that essay?
>
> http://www.paulgraham.com/newthings.html
>
> Look for the punch-line mid-way thru:
>
> "Now people are saying the same things about Arc that they said at
> first about Viaweb and Y Combinator and most of my essays. Why the
> pattern? The answer, I realized, is that my m.o. for all four has been
> the same.
>
> "Here it is: I like to find (a) simple solutions (b) to overlooked
> problems (c) that actually need to be solved, and (d) deliver them as
> informally as possible, (e) starting with a very crude version 1, then
> (f) iterating rapidly."
This is Guru speech. "I was right before, so I will _always_ be right
from now on." That's pretty unrealistic.
http://www.amazon.com/Guru-Papers-Masks-Authoritarian-Power/dp/1883319005
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Mon, 12 May 2008 21:25:58 -0400, <···········@optonline.net> wrote:
>
> Leandro Rios wrote:
>>
>> Kenny, would you please post a link (or at least the name) to that essay?
>
> http://www.paulgraham.com/newthings.html
>
> "Here it is: I like to find (a) simple solutions (b) to overlooked
> problems (c) that actually need to be solved, and (d) deliver them as
> informally as possible, (e) starting with a very crude version 1, then
> (f) iterating rapidly."
Hmm, or Ready, Fire, Aim.
ah, that would be 'rfa'
--
One of the strokes of genius from McCarthy
was making lists the center of the language - kt
** Posted from http://www.teranews.com **
Kent M Pitman wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>Brian wrote:
>>
>>>Ken Tilton wrote:
>>>
>>>
>>>>Damn language.
>>>>
>>>>kenny
>>>
>>>Isn't that half the fun?
>>
>>I just think my damn compiler has an obligation to tell me when I am
>>reinventing the damn wheel! I bet Lispworks does! Or SBCL for sure,
>>those yobbos are solving important problems like that all the time!!
>>But Franz? Noooooooo!
>>
>>Maybe if they used Cells....
>>
>>kenny
>>
>>ps. Hard to believe, but it turns out I found logbitp on the verge of
>>only the second reinvention, prolly the Franz text search doesn't work
>>either...which brings me to my point, the Great Flaw in the CLHS:
>>someone accidentally deleted all the meticulously chosen "see also"
>>references and no one had a backup. Always back up! Where was I...
>
>
> Oops. Sorry about that.
>
> The Notes on LOGAND (just below the See Also) are full of LOGBITP
> tidbits that should be on the LOGBITP page. Can't have everything.
What if we made it a Wiki!? Then the vast number of working Lisp
programmers...hang on.
>
> Part of your problem, in CLHS at least, may be that the permuted index
Never use it. Insufficiently hyper.
> was faked out by the fact that the name wasn't LOG-BIT-P or even
> LOGICAL-BIT-P... so if you look under "B" there is not entry for it
> under "bit". Then again, I know you like short,..
Yes!
>.. incomprehensible
No! But everyone knows I love Arc.
> names, so maybe you'd have hated a name like LOG-BIT-P or
> LOGICAL-BIT-P,
You missed the memo: I switched us all to the schemey "?" a few months ago.
> and maybe you count the scrunched name as a victory, and
> you should get used to itty bitty names hiding places you don't see them.
Oh, I am used to it.
>
> Maybe the real bug is that more of the language isn't all mashed
> together because then I would have had no choice but to write
> heuristics to decipher that kind of silliness, whereas given that most
> functions have reasonable names, I was able to mostly indulge the
> fiction that I could get away with treating the hyphens as morpheme
> breaks.
is it too late to consider CamelCase?
>
> After all, if the forces of long names were allowed to have their way,
> instead of writing THIRD we'd all be writing
> CONTENTS-OF-ADDRESS-DECREMENT-DECREMENT-REGISTER.
I like it!
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton <···········@optonline.net> writes:
>> The Notes on LOGAND (just below the See Also) are full of LOGBITP
>> tidbits that should be on the LOGBITP page. Can't have everything.
>
> What if we made it a Wiki!? Then the vast number of working Lisp
> programmers...hang on.
The only aspect of PHP I really love, are the user-contributed comments
in the documentation at php.net...
A HyperSpec with such an user-contribution-area and -extension would
be to wonderful, but likely problematic because of copyright-issues of
the hyperspec?
okflo
learninglisp wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>>The Notes on LOGAND (just below the See Also) are full of LOGBITP
>>>tidbits that should be on the LOGBITP page. Can't have everything.
>>
>>What if we made it a Wiki!? Then the vast number of working Lisp
>>programmers...hang on.
>
>
> The only aspect of PHP I really love, are the user-contributed comments
> in the documentation at php.net...
>
> A HyperSpec with such an user-contribution-area and -extension would
> be to wonderful, but likely problematic because of copyright-issues of
> the hyperspec?
Yep. Also, PHP being a useful web thingy had a kazillion users,
something tells me all these well-intentioned CL efforts that fall flat
on their faces do so because they think they can make the boom happen
but they should actually be the offshoot of a boom which I explain in my
rants below involve people shutting up and producing usable libraries or
jaw-dropping applications so they are doomed otherwise I would suggest
starting a section on the ALU Wiki that folks could mess with while
merely linking to the CLHS.
Speaking of "useful", this from Andy Chambers:
> Hi Everyone,
>
> The openair project has now been setup.
>
> Sign up to the mailing list here:
> http://common-lisp.net/mailman/listinfo/openair-devel
> The (sparse) project home page is here: http://common-lisp.net/project/openair/
>
I think we have in OA and SW two Rails-killers worth watching, the first
for those (five) of us who won't think of coding without Cells.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On Fri, 09 May 2008 06:18:16 -0400, <···········@optonline.net> wrote:
> Kent M Pitman wrote:
>> Ken Tilton <···········@optonline.net> writes:
>>
>> was faked out by the fact that the name wasn't LOG-BIT-P or even
>> LOGICAL-BIT-P... so if you look under "B" there is not entry for it
>> under "bit". Then again, I know you like short,..
>
> Yes!
>
>>.. incomprehensible
>
> No! But everyone knows I love Arc.
For shame! There you are listening to the words of the Prophet and
you don't check his book? Right in the ACL index with the other 'log'
functions.
One of the 5 places I check, and 'no thanks' to a wiki.
--
One of the strokes of genius from McCarthy
was making lists the center of the language - kt
** Posted from http://www.teranews.com **
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: Why wasn't I told about logbitp?!
Date:
Message-ID: <rem-2008may08-008@yahoo.com>
> From: Ken Tilton <···········@optonline.net>
> Damn language.
I'm sorry, but I haven't yet found funding to write my essay on
the intention of primitive data types (such as integers intended
as bitmasks), a companion to KMP's essay on intention of CONS trees.
As a result, I haven't yet incorporated the theme of that essay
into my CookBook/Matrix WebPage.
If that were done, you could look up either the built-in data type
(integer) or the intentional type (bitmask) to learn how one is
used to emulate the other, and then you would see functions that
deal with that intentional datatype, including logbitp.
So like the clich{e'} says, would you help a guy out?
I could really use an extra $70 per month.
Would you be willing to hire me for projects like this which would
be useful to you and the other Lisp newbies?
From: Espen Vestre
Subject: Re: Why wasn't I told about logbitp?!
Date:
Message-ID: <m1wsm49ft4.fsf@vestre.net>
Ken Tilton <···········@optonline.net> writes:
> Damn language.
That's what you get for not reading a chapter of the ANSI standard
every day, to remind you of all the cool things you haven't used yet
:-)
--
(espen)
On May 9, 8:01 am, Espen Vestre <·····@vestre.net> wrote:
> Ken Tilton <···········@optonline.net> writes:
> > Damn language.
>
> That's what you get for not reading a chapter of the ANSI standard
> every day, to remind you of all the cool things you haven't used yet
> :-)
> --
> (espen)
Yes, every day open a random page in the hyperspec, you'll be
surprised how many staff are already there.
Espen Vestre wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>Damn language.
>
>
> That's what you get for not reading a chapter of the ANSI standard
> every day, to remind you of all the cool things you haven't used yet
> :-)
I tried that one day, about a month into CL. Stopped after five minutes.
Remember me ragging on someone recently for wringing their hands about
ever being able to /memorize/ CL? Something like that.
The real problem, it seems from a few searches of my code, is that I do
not write a lot of bit manipulating code, that's how I learn stuff. Use
it or lose it.
Now why the hell isn't logbitp an accessor?!!
(let ((x 40))
(setf (logbitp 1 x) t)
x)
-> 42
? I think it's time for KennyLisp, writing way too much Algebra software
these days...
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
From: Espen Vestre
Subject: Re: Why wasn't I told about logbitp?!
Date:
Message-ID: <m1fxsraheg.fsf@vestre.net>
Ken Tilton <···········@optonline.net> writes:
> The real problem, it seems from a few searches of my code, is that I
> do not write a lot of bit manipulating code, that's how I learn
> stuff. Use it or lose it.
Agreed, I prefer reading newspapers or fiction when commuting...
> Now why the hell isn't logbitp an accessor?!!
That would have been nice...
Not sure about the efficiency of that, but (setf (ldb (byte 1 pos) x) 1)
will do the same as your suggested (setf (logbitp pos x) t).
So:
> (let ((x 40))
> (setf (logbitp 1 x) t)
> x)
> -> 42
translates into (and this is real cut & paste):
CAPI-E 42 > (let ((x 40))
(setf (ldb (byte 1 1) x) 1)
x)
42
--
(espen)
From: Espen Vestre
Subject: Re: Why wasn't I told about logbitp?!
Date:
Message-ID: <m1bq3faea4.fsf@vestre.net>
Espen Vestre <·····@vestre.net> writes:
> Not sure about the efficiency of that, but (setf (ldb (byte 1 pos) x) 1)
It is indeed very efficient, but of course I had forgotten that (setf
ldb) is equivalent to dpb. I actually think (setf ldb) is more
readable, but at least this shows that I should consider reading the
ANSI standard in bed or on the bus myself ;-)
--
(espen)
From: Frank "frgo" a.k.a DG1SBG
Subject: Re: Why wasn't I told about logbitp?!
Date:
Message-ID: <lz63tntd6l.fsf@goenninger.net>
Ken Tilton <···········@optonline.net> writes:
> Now why the hell isn't logbitp an accessor?!!
>
> (let ((x 40))
> (setf (logbitp 1 x) t)
> x)
> -> 42
>
> ? I think it's time for KennyLisp, writing way too much Algebra
> software these days...
That's what I found in CLHS for define-setf-expander:
;;; Setf expander for the form (LDB bytespec int).
;;; Recall that the int form must itself be suitable for SETF.
(define-setf-expander ldb (bytespec int &environment env)
(multiple-value-bind (temps vals stores
store-form access-form)
(get-setf-expansion int env);Get setf expansion for int.
(let ((btemp (gensym)) ;Temp var for byte specifier.
(store (gensym)) ;Temp var for byte to store.
(stemp (first stores))) ;Temp var for int to store.
(if (cdr stores) (error "Can't expand this."))
;;; Return the setf expansion for LDB as five values.
(values (cons btemp temps) ;Temporary variables.
(cons bytespec vals) ;Value forms.
(list store) ;Store variables.
`(let ((,stemp (dpb ,store ,btemp ,access-form)))
,store-form
,store) ;Storing form.
`(ldb ,btemp ,access-form) ;Accessing form.
))))
Now ... would it be possible to write a setf-expander for logbitp?
// frgo
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
thus spoke "Frank \"frgo\" a.k.a DG1SBG" <·············@nomail.org>:
> Now ... would it be possible to write a setf-expander for logbitp?
Not without violating package locks, no.
--
The great peril of our existence lies in the fact that our diet consists
entirely of souls. -- Inuit saying
From: Kent M Pitman
Subject: Re: Why wasn't I told about logbitp?!
Date:
Message-ID: <u63tligyo.fsf@nhplace.com>
Stanisław Halik <··············@tehran.lain.pl> writes:
> thus spoke "Frank \"frgo\" a.k.a DG1SBG" <·············@nomail.org>:
>
> > Now ... would it be possible to write a setf-expander for logbitp?
>
> Not without violating package locks, no.
I suppose it depends on what you mean by the question, but I'd say
only in the most literal reading of the question is this so.
Personally, I'd just say that's what shadowing is for. :) I have packages
that shadow a number of CL symbols that I don't like the definitions of
and I just provide my own definitions. And no one has to care.
After all, there is no value to writing a setf-expander for the sake
of packages other than your own or people who plan to use yours. And
if they do, then they'll generaly be just as happy with a shadowed
symbol. (Well, I can imagine a few situations where that isn't so,
but probably they don't apply to an obscure symbol like this one.)
On May 9, 12:24 pm, Ken Tilton <···········@optonline.net> wrote:
> Now why the hell isn't logbitp an accessor?!!
>
> (let ((x 40))
> (setf (logbitp 1 x) t)
> x)
> -> 42
Coincidentally, I needed to code precisely that today, for Lispworks:
(shadow '(logbitp))
(define-setf-expander logbitp (index integer &environment env)
(multiple-value-bind (%vals-temps %vals %newvals %setter %getter)
(get-setf-expansion integer env)
(let ((index-temp (gensym))
(newval (gensym))
(%newval (first %newvals)))
(values (cons index-temp %vals-temps)
(cons index %vals)
(list newval)
`(let ((,%newval (dpb (if ,newval 1 0)
(byte 1 ,index-temp)
,%getter)))
,%setter ; The %setter form will do the dirty work if
%newval is bound.
,newval)
`(cl:logbitp ,index-temp ,%vals-temps)))))
SBCL's version looks essentially the same, now that I check. They have
it built-in.
Tayssir