The seemingly fragmented development of new versions of Lisp (Arc,
GOO, Otter, you name it) makes me wonder whether ANSI is actively
working on a new version. If so, what have we to look forward to?
Might it do anything to reduce the ugliness of CL?
are wrote:
> The seemingly fragmented development of new versions of Lisp (Arc,
> GOO, Otter, you name it) makes me wonder whether ANSI is actively
> working on a new version. If so, what have we to look forward to?
> Might it do anything to reduce the ugliness of CL?
>
The good news is, yes, we are hard at it and really are just waiting for
the beta Stix fonts before starting our own beta (you would not believe
how hard it is to get a really nice aesthetic Greek lambda character,
and they have a beaut.)
The bad news is that our Prime Directive was to /increase/ the ugliness.
For more information, please direct all traffic to gavino, our
communications director.
hth,kt
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
On Sep 11, 6:13 am, Ken Tilton <···········@optonline.net> wrote:
> The bad news is that our Prime Directive was to /increase/ the ugliness.
What's your idea of ugliness? Since I don't know CL well, my idea of
it is pretty superficial and boils down pretty much to inconsistent,
ugly and unwieldy function names.
> For more information, please direct all traffic to gavino, our
> communications director.
Who's gavino (or am I failing to get a joke here?)?
On 2007-09-20 12:25:15 -0400, are <·········@gmx.net> said:
> Who's gavino (or am I failing to get a joke here?)?
groups.google.com is your friend, especially the advanced search on
author name (gavino) in a particular group (c.l.l).
P� Tue, 11 Sep 2007 11:28:44 +0200, skrev are <·········@gmx.net>:
> The seemingly fragmented development of new versions of Lisp (Arc,
> GOO, Otter, you name it) makes me wonder whether ANSI is actively
> working on a new version. If so, what have we to look forward to?
> Might it do anything to reduce the ugliness of CL?
>
No the ANSI committee that made Common Lisp is disbanded and there is
currently no incentive to create a revised standard.
As for question 2 the point of the ANSI standard was always to maintain
backward compatibility as far as possible so I would not expect the
language to be "cleaned up". There may be warts, but they are our warts.
It is Scheme that is constantly modifying the language and they are, I
believe, coming up with a new spec soon. (comp.lang.scheme)
In article <·················@pandora.upc.no>,
"John Thingstad" <··············@chello.no> wrote:
> P� Tue, 11 Sep 2007 11:28:44 +0200, skrev are <·········@gmx.net>:
>
> > The seemingly fragmented development of new versions of Lisp (Arc,
> > GOO, Otter, you name it) makes me wonder whether ANSI is actively
> > working on a new version. If so, what have we to look forward to?
> > Might it do anything to reduce the ugliness of CL?
> >
>
> No the ANSI committee that made Common Lisp is disbanded and there is
> currently no incentive to create a revised standard.
> As for question 2 the point of the ANSI standard was always to maintain
> backward compatibility as far as possible so I would not expect the
> language to be "cleaned up". There may be warts, but they are our warts.
> It is Scheme that is constantly modifying the language and they are, I
> believe, coming up with a new spec soon. (comp.lang.scheme)
Oh, the new Scheme spec is already ratified: R6RS.
Though I have to say that it would not make me even think about
switching from CL to Scheme for a second. R6RS makes CL
look attractive, if you ask me.
--
http://lispm.dyndns.org
"John Thingstad" <··············@chello.no> writes:
> P� Tue, 11 Sep 2007 11:28:44 +0200, skrev are <·········@gmx.net>:
>
> > The seemingly fragmented development of new versions of Lisp (Arc,
> > GOO, Otter, you name it) makes me wonder whether ANSI is actively
> > working on a new version. If so, what have we to look forward to?
> > Might it do anything to reduce the ugliness of CL?
Well, of course, not all of us think CL is ugly nor that any given other
language is obviously less ugly. So you want to manage your set of what
assumptions are obvious in discussions like this. I suggest to you that
there are very few "obviously true" statements you can make in this arena.
And, indeed, as John points out in his reply to you (quoted here
below), there are some attempts to (subjectively) "clean up" Lisp that
have been ongoing for a long time, such that the solution for some
people is "choose a given extant language" such as Scheme, Dylan, ML,
Haskell, etc. ... many of which are in fact reactions to Lisp in one
way or another. (Again, people's points of view about what they like
vary, and people often select a language as much for their belief of
how it will cater to them as for the specifics of its details. [1])
> No the ANSI committee that made Common Lisp is disbanded and there is
> currently no incentive to create a revised standard.
> As for question 2 the point of the ANSI standard was always to
> maintain backward compatibility as far as possible so I would not
> expect the language to be "cleaned up". There may be warts, but they
> are our warts. It is Scheme that is constantly modifying the language
> and they are, I believe, coming up with a new spec
> soon. (comp.lang.scheme)
A reasonable summary. Let me expand on one detail left out of the above:
The ANSI standard never had as its intent to keep people from making
new dialects. That is, we did not mean to standardize on WHICH lisp
you should use, merely to standardize the meaning of Common Lisp for
people who choose to use it.
There was considerable discussion at the time of the standard that it
might impede new development, and the reassurance offered to those
people even at that time was that the desire of CL was to support
those who needed a stable platform that was NOT frequently broken, not
to define for all time that no one should ever experiment with changes
from some religiously defined standard.
What led to the standard happening at all was the fact that there was
broad de facto agreement that CLTL represented what everyone wanted to
use. That doesn't have to be true for all time, but there is no
reason to suppose that some other definition should be created by fiat
through a standards organization issuing a disruptive proclamation.
Rather, it is the burden of arc or any other such thing that wants to
supplant CL to cause the users to all be using that instead. If such
a dialect were to arise and gain popular use, that wouldn't be bad,
but it isn't a given that ny given dialect will be that dialect, nor
that the right time to do it is now. Experimentation takes time and
acceptance even of the "right thing" (once it becomes apparent) also
takes time.
If you look at
http://en.wikipedia.org/wiki/Consent_of_the_governed#criticism, you
see one traditional argument that can be leveraged against a democratic
process (which ANSI is) is that it cannot allow individuals to individually
sign on. However, the virtue of the free market is that individuals can
individually sign on, which is why it's important that the free market
lead standardization, not try to follow it.
And besides, we made it a standard for Common Lisp, not for Lisp, just as
ISLISP is an international standard for ISLISP, not for Lisp, because it
leaves rooms for there to be other languages, just as C, C++, C#, etc. have
evolved separately as their own identities even though they have a
commonality of origin / syntax / expressional style.
As has been said many times before by many people:
The nice thing about standards is that there are so many of them.
And, btw, going one step meta, just because you might later
want to standardize something else, I wouldn't automatically do
any of the following:
- choose ANSI without looking at other more low-overhead standards
(ANSI is capable of fast tracking the result of other standards bodies)
- choose to standardize a core without asking "is it really just libraries
or OS/file system/etc. bindings that need standardization"
The answer might be you want ANSI or you want a whole language
standard, but it should not be assumed so without due consideration
and study. ANSI is expensive in terms of time and meetings, its
intellectual property issues may not be what one wants, the set of
people it chooses to involve and the ways for them to be involved may
not be right.
And, finally, you should NEVER standardize something before it is
mostly already right, since democratic process is not a good design
process. It's maybe a good tightening up process when things are
mostly right and you want to ensure broad buy-in. Opening design to
democracy is a good way to randomize the design, and it might be better
to go the route CLTL did of getting a language, getting everyone to like
it, then caring about standards. Standards bodies, being expensive, favor
members who are institutional and have institutional needs, probably just
the needs that users wishing there were other-than-ANSI don't want; they
do not tend to favor cool, tight, trendy, innovative solutions that are
not strongly demonstrated. So they can splash cold water on something
that needs to evolve quickly and unfettered among committed folks.
(It is for similar reasons that I think a new constitutional convention
for the US is both strongly desired by people in-the-know and likely to
be a disaster if actually tried... it's so hard to design something right
even as one person, and it'd be nearly impossible as a committee. It would
favor the powerful, not good design. The slowness of the present system,
for all its flaws, is the actual protection itself ... A great deal of the
problems of the world these days are caused by things running faster than
can be easily controlled, adapated to, responded to, etc. by individuals,
such that the process takes on a life of its own. And the safeguards on
time have a considerable good side in maintaining the stability which
supports desired exploration... It's probably hard to see this as symbiotic
but I think it is, and its' worse enemy is people demanding "raw efficiency
of the system".)
So, in sum, I don't see any flaw in the present way things are going.
The standard thing is stable for those wanting that, and people are free
to experiment at the cost of standardization (but also at the benefit of
being free of the shackles of standarization in terms of time, red tape,
expense, commitment, etc... while having, all the while, access to tools
that are stable exactly because of they have, as a matter of market choice,
chosen to operate thusly shackled).
- - - -
[1] "More Than Just Words: Lambda, the Ultimate Political Party"
http://www.nhplace.com/kent/PS/Lambda.html
[Possibly heading slightly OT... Maybe.]
Kent M Pitman <······@nhplace.com> wrote:
+---------------
| The slowness of the present system, for all its flaws, is the
| actual protection itself ... A great deal of the problems of
| the world these days are caused by things running faster than
| can be easily controlled, adapated to, responded to, etc. by
| individuals, such that the process takes on a life of its own.
| And the safeguards on time have a considerable good side in
| maintaining the stability which supports desired exploration...
| It's probably hard to see this as symbiotic but I think it is, and
| its worse enemy is people demanding "raw efficiency of the system".)
+---------------
In Frank Herbert's science-fiction novels "Whipping Star" and "The
Dosadi Experiment" [and a few other short stories as well] containing the
character "Jorj X. McKie" <http://en.wikipedia.org/wiki/Jorj_X._McKie>,
he postulates that when [future?] government got *way* "too efficient"
that there arose a popular movement to throw sand in the works:
http://en.wikipedia.org/wiki/Bureau_of_Sabotage
Red tape no longer exists: laws are conceived of, passed, funded,
and executed within hours, rather than months. The bureaucratic
machinery becomes a juggernaut, rolling over human concerns and
welfare with terrible speed...
...
BuSab began as a terrorist organization whose sole purpose was to
frustrate the workings of government in order to give sentients
a chance to reflect upon changes and deal with them. Having saved
sentiency from its government, BuSab was officially recognized as
a necessary check on the power of government. It provides a natural
(and lucrative) outlet for society's regular crop of troublemakers,
who must be countered by society's regular crop of "do-gooders".
First a corps, then a bureau, BuSab gained legally recognized
powers to interfere in the workings of any world, of any species,
of any government or corporation, answerable only to themselves.
Their motto is, "In Lieu of Red Tape."
It sometimes seems that the open-source software movement [in the
larger sense] has been making some of the same mistakes that led to the
[fictional] arising of BuSab: changing things for the sake of change
and "because it's cool" -- the sardonic and self-deprecating expression
for which, often used in comments at <http://www.userfriendly.org/>,
being "Oooh! Shiny!! I wants it!!! -- and without any apparent concerns
for backwards compatibility or not breaking things that work.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> and without any apparent concerns
> for backwards compatibility or not breaking things that work.
Yeah but thankfully that is a concern that is not Lisp's.
On Sep 11, 12:14 pm, Kent M Pitman <······@nhplace.com> wrote:
> Well, of course, not all of us think CL is ugly nor that any given other
> language is obviously less ugly. So you want to manage your set of what
> assumptions are obvious in discussions like this. I suggest to you that
> there are very few "obviously true" statements you can make in this arena.
NTH (and therefore NTHCDR) and GETHASH take their arguments in the
wrong order (cf. ELT, AREF, SVREF).
MAKUNBOUND is misspelled.(*)
I think that's about it :)
-- Scott
(*) Reminds me of a story, which I probably have wrong, but in my
memory it goes like this: someone asked Brian Kernighan, if he were
going to rewrite Unix from scratch, what he would change. He said, "I
would have spelled `creat' with an `e'". Huh, say I, what about
`umount'?
Scott Burson wrote:
> On Sep 11, 12:14 pm, Kent M Pitman <······@nhplace.com> wrote:
>
>>Well, of course, not all of us think CL is ugly nor that any given other
>>language is obviously less ugly. So you want to manage your set of what
>>assumptions are obvious in discussions like this. I suggest to you that
>>there are very few "obviously true" statements you can make in this arena.
>
>
> NTH (and therefore NTHCDR) and GETHASH take their arguments in the
> wrong order (cf. ELT, AREF, SVREF).
>
> MAKUNBOUND is misspelled.(*)
>
> I think that's about it :)
You forgot (- 2 0) -> 2 but (- 2) -> -2.
kt
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
P� Thu, 13 Sep 2007 01:01:35 +0200, skrev Ken Tilton
<···········@optonline.net>:
>
> You forgot (- 2 0) -> 2 but (- 2) -> -2.
>
No that is fine.
(- 2 0) means 2 - 0 = 2
(- 2) means -2
There is a difference between the unary and binary (or n-ary) operations.
John Thingstad wrote:
> P� Thu, 13 Sep 2007 01:01:35 +0200, skrev Ken Tilton
> <···········@optonline.net>:
>
>>
>> You forgot (- 2 0) -> 2 but (- 2) -> -2.
>>
>
> No that is fine.
> (- 2 0) means 2 - 0 = 2
> (- 2) means -2
> There is a difference between the unary and binary (or n-ary) operations.
Oh, golly, really? I did not know that! <sigh>
Listen, - is the only Lisp operator with two entries in the CLHS under
syntax. I am disappointed I had to spell this out for you, but not
surprised.
kt
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
On Sep 12, 9:34 pm, Ken Tilton <···········@optonline.net> wrote:
> Listen, - is the only Lisp operator with two entries in the CLHS under
> syntax.
No it's not. / behaves the same way: in the unary case, it applies
the operation to the identity value (in this case, the multiplicative
identity value, 1) and the single argument.
Anyway, while I see your point, it's not entirely clear what to do
about it. I guess you could simply disallow the unary case of both of
these operators. This might not be too onerous.
-- Scott
Scott Burson wrote:
> On Sep 12, 9:34 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>Listen, - is the only Lisp operator with two entries in the CLHS under
>>syntax.
>
>
> No it's not. / behaves the same way: in the unary case, it applies
> the operation to the identity value (in this case, the multiplicative
> identity value, 1) and the single argument.
Thanks, I was hoping I could sucker someone into doing my legwork for
me. <g>
Btw, I did not even know that (/ 2) -> 1/2, and I only learned a coupla
months ago here that 1/2 was legal syntax.... hmmm, I think we should
add that to the list of Lisp Sins.
>
> Anyway, while I see your point, it's not entirely clear what to do
> about it. I guess you could simply disallow the unary case of both of
> these operators. This might not be too onerous.
Well, I guess Scheme is the language obsessed with purity so I won't
make them change it yet, but it is funny seeing a whisker of syntax in Lisp.
kt
Ken Tilton <···········@optonline.net> writes:
> Scott Burson wrote:
> > On Sep 12, 9:34 pm, Ken Tilton <···········@optonline.net> wrote:
> >
> >>Listen, - is the only Lisp operator with two entries in the CLHS under
> >>syntax.
> > No it's not. / behaves the same way: in the unary case, it applies
> > the operation to the identity value (in this case, the multiplicative
> > identity value, 1) and the single argument.
>
> Thanks, I was hoping I could sucker someone into doing my legwork for
> me. <g>
>
> Btw, I did not even know that (/ 2) -> 1/2, and I only learned a
> coupla months ago here that 1/2 was legal syntax.... hmmm, I think we
> should add that to the list of Lisp Sins.
One reason there are two signature lines for -, btw, is that the functions
are really different in that case. It's more of an overloading, not the
usual degenerate case of a generic function on n args...
(- 0 0.0) => 0.0
(- 0.0 0.0) => 0.0
(- 0.0) => -0.0
Note the latter is negation, not subtraction, and is managed differently.
I think it's IEEE that says this is the right thing, and I think they
got this one right.
Kent M Pitman wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>Scott Burson wrote:
>>
>>>On Sep 12, 9:34 pm, Ken Tilton <···········@optonline.net> wrote:
>>>
>>>
>>>>Listen, - is the only Lisp operator with two entries in the CLHS under
>>>>syntax.
>>>
>>>No it's not. / behaves the same way: in the unary case, it applies
>>>the operation to the identity value (in this case, the multiplicative
>>>identity value, 1) and the single argument.
>>
>>Thanks, I was hoping I could sucker someone into doing my legwork for
>>me. <g>
>>
>>Btw, I did not even know that (/ 2) -> 1/2, and I only learned a
>>coupla months ago here that 1/2 was legal syntax.... hmmm, I think we
>>should add that to the list of Lisp Sins.
>
>
> One reason there are two signature lines for -, btw, is that the functions
> are really different in that case. It's more of an overloading,...
Right, differentiated by the number of args. That is what has me running
around the room pulling my hair out shrieking at the oh the humanity
horror of Lisp having /syntax!/
How the hell did /that/ get in there? Some big guy (Gabriel?) musta had
a lotta code he did not wanna change. And since when did I move to Brooklyn?
kt
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
+ Ken Tilton <···········@optonline.net>:
> Right, differentiated by the number of args. That is what has me
> running around the room pulling my hair out shrieking at the oh the
> humanity horror of Lisp having /syntax!/
Um, you're referring to 1/2, right? But 1/2 is not some kind of
syntactic sugar for (/ 2) or (/ 1 2). It's converted by the reader
directly to a rational number. Kinda like #.(/ 1 2).
If 1/2 is syntax, then so is 0.5D0. And "one half".
Wait, wait ... chapter 2 of the hyperspec is named ... "Syntax".
News at eleven.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
P� Thu, 13 Sep 2007 06:34:19 +0200, skrev Ken Tilton
<···········@optonline.net>:
>
>
> John Thingstad wrote:
>> P� Thu, 13 Sep 2007 01:01:35 +0200, skrev Ken Tilton
>> <···········@optonline.net>:
>>
>>>
>>> You forgot (- 2 0) -> 2 but (- 2) -> -2.
>>>
>> No that is fine.
>> (- 2 0) means 2 - 0 = 2
>> (- 2) means -2
>> There is a difference between the unary and binary (or n-ary)
>> operations.
>
> Oh, golly, really? I did not know that! <sigh>
>
> Listen, - is the only Lisp operator with two entries in the CLHS under
> syntax. I am disappointed I had to spell this out for you, but not
> surprised.
>
> kt
>
I just I never saw it as a problem. You have a history of making issues of
assenine things..
Inconsistent spelling like reverse, nreverse and remove, delete is more of
a problem.
Either way it stays the way it is.
Incedentally / behaves the same way..
Ken Tilton wrote:
>
>
> Scott Burson wrote:
>
>> On Sep 11, 12:14 pm, Kent M Pitman <······@nhplace.com> wrote:
>>
>>> Well, of course, not all of us think CL is ugly nor that any given other
>>> language is obviously less ugly. So you want to manage your set of what
>>> assumptions are obvious in discussions like this. I suggest to you that
>>> there are very few "obviously true" statements you can make in this
>>> arena.
>>
>>
>>
>> NTH (and therefore NTHCDR) and GETHASH take their arguments in the
>> wrong order (cf. ELT, AREF, SVREF).
>>
>> MAKUNBOUND is misspelled.(*)
>>
>> I think that's about it :)
>
>
> You forgot (- 2 0) -> 2 but (- 2) -> -2.
And string-downcase but lower-case-p? Not even lowercasep?
This language is a disaster!
kt
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
On Sep 13, 9:43 pm, Ken Tilton <···········@optonline.net> wrote:
> And string-downcase but lower-case-p? Not even lowercasep?
Oh, oh, I can fix it!
(defmacro lowercase-p (c)
`(lower-case-p ,c))
Where's Eli? This is perfect - can't do that in Ruby ;)
Brian Adkins wrote:
> On Sep 13, 9:43 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>And string-downcase but lower-case-p? Not even lowercasep?
>
>
> Oh, oh, I can fix it!
>
> (defmacro lowercase-p (c)
> `(lower-case-p ,c))
>
> Where's Eli? This is perfect - can't do that in Ruby ;)
>
(a) You seem to be unaware of the Laws of Conservation of Hyphen
Momentum: according to the CLHS, a term in hyphen motion tends to remain
in motion, a term at hyphen rest tends to remain at rest.
(b) Really, the worst thing you can do in CL is use a macro where a
function would do. The Pope does not sudo ex cathedra to say, "It's not
the heat, it's the humidity."
hth,kenny
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
On Sep 14, 8:24 am, Ken Tilton <···········@optonline.net> wrote:
> Brian Adkins wrote:
> > On Sep 13, 9:43 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>And string-downcase but lower-case-p? Not even lowercasep?
>
> > Oh, oh, I can fix it!
>
> > (defmacro lowercase-p (c)
> > `(lower-case-p ,c))
>
> > Where's Eli? This is perfect - can't do that in Ruby ;)
>
> (b) Really, the worst thing you can do in CL is use a macro where a
> function would do. The Pope does not sudo ex cathedra to say, "It's not
> the heat, it's the humidity."
Geez, my first CL macro and I already committed the worst offense in
CL even though it was only 2 lines long. No problem, I'm here to
learn.
It was of course tongue-in-cheek, but the reason I chose a macro was
for efficiency. I take it from your comment that reasonable CL
implementations will inline the equivalent function (ignore hyphen
inertia for the sake of discussion), so I was prematurely optimizing.
Is that true?
Brian Adkins wrote:
> On Sep 14, 8:24 am, Ken Tilton <···········@optonline.net> wrote:
>
>>Brian Adkins wrote:
>>
>>>On Sep 13, 9:43 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>And string-downcase but lower-case-p? Not even lowercasep?
>>
>>>Oh, oh, I can fix it!
>>
>>>(defmacro lowercase-p (c)
>>> `(lower-case-p ,c))
>>
>>>Where's Eli? This is perfect - can't do that in Ruby ;)
>>
>>(b) Really, the worst thing you can do in CL is use a macro where a
>>function would do. The Pope does not sudo ex cathedra to say, "It's not
>>the heat, it's the humidity."
>
>
> Geez, my first CL macro and I already committed the worst offense in
> CL even though it was only 2 lines long. No problem, I'm here to
> learn.
>
> It was of course tongue-in-cheek, but the reason I chose a macro was
> for efficiency. I take it from your comment that reasonable CL
> implementations will inline the equivalent function (ignore hyphen
> inertia for the sake of discussion), so I was prematurely optimizing.
> Is that true?
>
Call me when the profiler says the function call overhead of a
lowercasep function is the bottleneck in your real-world application.
I'll be waiting by the phone.
kenny
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
On Sep 14, 4:41 pm, Ken Tilton <···········@optonline.net> wrote:
> Call me when the profiler says the function call overhead of a
> lowercasep function is the bottleneck in your real-world application.
> I'll be waiting by the phone.
You made me curious about the efficiency of lower-case-p vs. a
function wrapper vs. a macro.
(defmacro lowercase-p (c)
`(lower-case-p ,c))
(defun lowercasep (c)
(lower-case-p c))
[9]> (lowercase-p #\e)
T
[10]> (lowercasep #\e)
T
(time
(do ((i 1 (1+ i)))
((> i 3000000) 'done)
(lower-case-p #\e)))
Real time: 5.037117 sec.
Run time: 5.008313 sec.
Space: 624 Bytes
DONE
[5]>
(time
(do ((i 1 (1+ i)))
((> i 3000000) 'done)
(lowercasep #\e)))
Real time: 6.511556 sec.
Run time: 6.496406 sec.
Space: 624 Bytes
DONE
[6]>
(time
(do ((i 1 (1+ i)))
((> i 3000000) 'done)
(lowercase-p #\e)))
Real time: 14.498972 sec.
Run time: 14.480904 sec.
Space: 96000648 Bytes
GC: 138, GC time: 0.744036 sec.
DONE
>From this simplistic test, the function wrapper appears to be about
29% slower than the built-in. But what the heck is going on with the
macro version? 96,000,648 bytes and 14+ seconds? I must be
misunderstanding macros because I thought the macro version would
yield identical results to the built-in. I ran this on clisp 2.41 on
Ubuntu Linux.
So not only did I break the "don't use a function when a macro will
do" rule, but my macro is over 2.5 times slower and a memory hog :(
Brian Adkins wrote:
>>From this simplistic test, the function wrapper appears to be about
> 29% slower than the built-in. But what the heck is going on with the
> macro version? 96,000,648 bytes and 14+ seconds? I must be
> misunderstanding macros because I thought the macro version would
> yield identical results to the built-in. I ran this on clisp 2.41 on
> Ubuntu Linux.
[3]> (time
(do ((i 1 (1+ i)))
((> i 3000000) 'done)
(lowercase-p #\e)))
Real time: 32.54517 sec.
Run time: 32.33002 sec.
Space: 96000648 Bytes
GC: 138, GC time: 2.276137 sec.
DONE
[4]> (defun compile-teh-feck-already-you-st00pid-thing ()
(time
(do ((i 1 (1+ i)))
((> i 3000000) 'done)
(lowercase-p #\e))))
COMPILE-TEH-FECK-ALREADY-YOU-ST00PID-THING
[5]> (compile 'COMPILE-TEH-FECK-ALREADY-YOU-ST00PID-THING)
COMPILE-TEH-FECK-ALREADY-YOU-ST00PID-THING ;
NIL ;
NIL
[6]> (compile-teh-feck-already-you-st00pid-thing)
Real time: 0.620293 sec.
Run time: 0.616039 sec.
Space: 0 Bytes
DONE
> So not only did I break the "don't use a function when a macro will
> do" rule, but my macro is over 2.5 times slower and a memory hog :(
Swap "macro" with "function"?
On Sep 14, 7:47 pm, Matthias Buelow <····@incubus.de> wrote:
> I wrote:
> > COMPILE-TEH-FECK-ALREADY-YOU-ST00PID-THING
>
> I'd like to point out that I mean clisp with that, of course...
Ah, thanks for the explanation. I thought it was odd that you would
provide a helpful tip mixed with such a direct insult :)
Brian Adkins wrote:
> Ah, thanks for the explanation. I thought it was odd that you would
> provide a helpful tip mixed with such a direct insult :)
I just don't have any respect for software or the machine it runs on. :)
Matthias Buelow <···@incubus.de> writes:
> Brian Adkins wrote:
>
>> Ah, thanks for the explanation. I thought it was odd that you would
>> provide a helpful tip mixed with such a direct insult :)
>
> I just don't have any respect for software or the machine it runs on. :)
Just remember, you'll be first against the wall when the Singularity
comes.
--
Fred Gilham ······@csl.sri.com
Lisp has jokingly been called "the most intelligent way to misuse a
computer". I think that description is a great compliment because it
transmits the full flavor of liberation: it has assisted a number of
our most gifted fellow humans in thinking previously impossible
thoughts. E. Dijkstra
Brian Adkins <···········@gmail.com> writes:
>
> So not only did I break the "don't use a function when a macro will
> do" rule, but my macro is over 2.5 times slower and a memory hog :(
>
You will probably find that the CLISP /interpreter/ was repeatedly
expanding the macro definition upon each call. Try compiling to see if
there is any speed improvement. (CLISP compiles to byte code, and I'm
not sure how this would affect macro performance.)
David Trudgett
--
These are not the droids you are looking for. Move along.
On Sep 14, 7:50 pm, David Trudgett <·········@yahoo.com> wrote:
> You will probably find that the CLISP /interpreter/ was repeatedly
> expanding the macro definition upon each call. Try compiling to see if
> there is any speed improvement. (CLISP compiles to byte code, and I'm
> not sure how this would affect macro performance.)
Thanks for the explanation.
Ken Tilton <·········@gmail.com> wrote:
+---------------
| > Geez, my first CL macro and I already committed the worst offense in
| > CL even though it was only 2 lines long. No problem, I'm here to
| > learn.
| >
| > It was of course tongue-in-cheek, but the reason I chose a macro was
| > for efficiency. I take it from your comment that reasonable CL
| > implementations will inline the equivalent function (ignore hyphen
| > inertia for the sake of discussion), so I was prematurely optimizing.
| > Is that true?
|
| Call me when the profiler says the function call overhead of a
| lowercasep function is the bottleneck in your real-world application.
| I'll be waiting by the phone.
+---------------
But don't place that call until *after* you've tried
"DECLAIM INLINE" and/or "DEFINE-COMPILER-MACRO"...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Ken Tilton <···········@optonline.net> wrote on Fri, 14 Sep 2007:
> The Pope does not sudo ex cathedra to say, "It's not the heat, it's the
> humidity."
"sudo" is also useful for getting sandwiches:
http://xkcd.com/149/
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
In theory, there is no difference between theory and practice.
In practice, however, there is.
P� Fri, 14 Sep 2007 14:24:35 +0200, skrev Ken Tilton
<···········@optonline.net>:
>
> (b) Really, the worst thing you can do in CL is use a macro where a
> function would do. The Pope does not sudo ex cathedra to say, "It's not
> the heat, it's the humidity."
>
> hth,kenny
>
>
(declaim inline func)
(defun func ...)
Is what you want. This avoids the overhead of a function call (when
compiled) without resorting to a macro.
(Except on Allegro CL which ignores the delaration and does it
automatically when it sees fit)
On Sep 13, 12:34 am, Scott Burson <········@gmail.com> wrote:
> On Sep 11, 12:14 pm, Kent M Pitman <······@nhplace.com> wrote:
>
> > Well, of course, not all of us think CL is ugly nor that any given other
> > language is obviously less ugly. So you want to manage your set of what
> > assumptions are obvious in discussions like this. I suggest to you that
> > there are very few "obviously true" statements you can make in this arena.
>
> NTH (and therefore NTHCDR) and GETHASH take their arguments in the
> wrong order (cf. ELT, AREF, SVREF).
>
> MAKUNBOUND is misspelled.(*)
>
> I think that's about it :)
>
> -- Scott
>
> (*) Reminds me of a story, which I probably have wrong, but in my
> memory it goes like this: someone asked Brian Kernighan, if he were
> going to rewrite Unix from scratch, what he would change. He said, "I
> would have spelled `creat' with an `e'". Huh, say I, what about
> `umount'?
"I saw the code for your computer program yesterday. It looked easy.
Its just a bunch of typing. And half of the words were spelt wrong.
And dont get me started on your over-use of parens."
- The Pointy Haired Boss sees some actual code
On Sep 12, 5:34 pm, Scott Burson <········@gmail.com> wrote:
> On Sep 11, 12:14 pm, Kent M Pitman <······@nhplace.com> wrote:
>
> > Well, of course, not all of us think CL is ugly nor that any given other
> > language is obviously less ugly. So you want to manage your set of what
> > assumptions are obvious in discussions like this. I suggest to you that
> > there are very few "obviously true" statements you can make in this arena.
>
> NTH (and therefore NTHCDR) and GETHASH take their arguments in the
> wrong order (cf. ELT, AREF, SVREF).
>
> MAKUNBOUND is misspelled.(*)
This is the kind of thing I had in mind in the OP, and I can add a few
other things. For example if it's LISTP then it should be ATOMP, not
ATOM. For that matter, why not take a hint from Scheme and denote
predicates with ? instead of P, e.g., LIST? and ATOM? . In this
regard, I think Scheme's use of ! is also helpful. There is also the
matter of functions which have destructive and non-destructive forms,
which are sometimes consistently named xxx and Nxxx and sometimes not.
If you're an expert Lisper, none of this really matters much, I'm
sure. For a beginner like me, however, it steepens the learning
curve, especially if your picking Lisp up in little bits of spare
time. Perhaps a beginner such as self should take it as a challenge
to DEFMACRO away all of the perceived ugliness.
are wrote:
> This is the kind of thing I had in mind in the OP, and I can add a few
> other things. For example if it's LISTP then it should be ATOMP, not
> ATOM.
Agreed but McCarthy named it ATOM, not ATOMP. The P appeared later,
perhaps to avoid clashes with existing symbols (LIST/LISTP).
> For that matter, why not take a hint from Scheme and denote
> predicates with ? instead of P, e.g., LIST? and ATOM? .
...
> In this regard, I think Scheme's use of ! is also helpful.
See next.
> Perhaps a beginner such as self should take it as a challenge
> to DEFMACRO away all of the perceived ugliness.
are wrote:
> On Sep 12, 5:34 pm, Scott Burson <········@gmail.com> wrote:
>> On Sep 11, 12:14 pm, Kent M Pitman <······@nhplace.com> wrote:
>>
>>> Well, of course, not all of us think CL is ugly nor that any given other
>>> language is obviously less ugly. So you want to manage your set of what
>>> assumptions are obvious in discussions like this. I suggest to you that
>>> there are very few "obviously true" statements you can make in this arena.
>> NTH (and therefore NTHCDR) and GETHASH take their arguments in the
>> wrong order (cf. ELT, AREF, SVREF).
>>
>> MAKUNBOUND is misspelled.(*)
>
> This is the kind of thing I had in mind in the OP, and I can add a few
> other things. For example if it's LISTP then it should be ATOMP, not
> ATOM. For that matter, why not take a hint from Scheme and denote
> predicates with ? instead of P, e.g., LIST? and ATOM? . In this
> regard, I think Scheme's use of ! is also helpful. There is also the
> matter of functions which have destructive and non-destructive forms,
> which are sometimes consistently named xxx and Nxxx and sometimes not.
The N stands for "non-consing", not for "destructive."
Names like ATOM and MAKUNBOUND are historical evolutions. Changing them
doesn't buy you anything, but creates gratuitous maintenance problems.
> If you're an expert Lisper, none of this really matters much, I'm
> sure. For a beginner like me, however, it steepens the learning
> curve, especially if your picking Lisp up in little bits of spare
> time. Perhaps a beginner such as self should take it as a challenge
> to DEFMACRO away all of the perceived ugliness.
What is nice about Common Lisp's operator names is that they give you a
sense of history. When you're getting more experienced, you will
actually be able to tell from a name in which decade it was added to Lisp.
This is also useful for newbies: The weirder a name looks, the more
likely it is that you may better not use it (yet).
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
are <·········@gmx.net> wrote on Wed, 19 Sep 2007:
> On Sep 12, 5:34 pm, Scott Burson <········@gmail.com> wrote:
>> On Sep 11, 12:14 pm, Kent M Pitman <······@nhplace.com> wrote:
>> > Well, of course, not all of us think CL is ugly nor that any given other
>> > language is obviously less ugly. [...] I suggest to you that there are
>> > very few "obviously true" statements you can make in this arena.
>>
>> NTH (and therefore NTHCDR) and GETHASH take their arguments in the
>> wrong order (cf. ELT, AREF, SVREF).
>> MAKUNBOUND is misspelled.(*)
>
> This is the kind of thing I had in mind in the OP, and I can add a few
> other things. For example if it's LISTP then it should be ATOMP, not
> ATOM. For that matter, why not take a hint from Scheme and denote
> predicates with ? instead of P, e.g., LIST? and ATOM? .
The answer to some of these questions is clearly for deliberate historical
reasons. There is little to be gained by a gratuitous change, and a large
cost in terms of re-writing volumes of old code.
Common Lisp was not designed from scratch from a blank slate. Many changes
were made to the existing Lisp dialects, where there was significant value to
be gained. If there was little value to be gained, then backwards
compatibility was judged to be the deciding factor.
This is as true today as it was when Common Lisp was first designed a few
decades ago. In that sense, it's a little unfair to complain about some
minor irregularities. They aren't mistakes. The tradeoffs were examined
deliberately, and a choice was made to keep them as is.
> In this regard, I think Scheme's use of ! is also helpful.
Read Kent's words again:
I suggest to you that there are very few "obviously true" statements
you can make in this arena.
All of the examples you come up with may be obvious to _you_, but you're
mistaken to think that the designers of Common Lisp made a pure error, and
that if they were to do it again "of course" they would fix these things that
bother you.
It turns out that there are arguments in favor of the current forms, which
perhaps you're not familiar with.
In the case of Scheme and "!", the Scheme community is far more concerned
with "pure" functional programming, and has a bias to warn programmers when
they violate the ideal. Hence the desire to mark destructive/side-effect
functions.
The Common Lisp community doesn't have that bias. It is a multi-paradigm
language, and non-functional programming is NOT to be discouraged.
Hence, once again, it's far from obvious that adding "!" to every destructive
function in Common Lisp, in the style of Scheme, would actually result in a
language that the CL community would believe to be superior.
> If you're an expert Lisper, none of this really matters much, I'm sure.
> For a beginner like me, however, it steepens the learning curve
You are correct that in any native language (accumulated by actual use over
time, rather than designed from scratch all at once), there are "warts" that
arise for historical reasons. And lack of consistency is a small barrier for
new students to the language.
This tradeoff was known at design time for Common Lisp. And some attempts
were made to regularize it. But ease-of-learning was not the sole attribute
by which the design was judged. There are times (and you've found some) where
other values also mattered.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
I often wonder how come John Tesh isn't as popular a singer as some people
think he should be. Then, I remember it's because he sucks.
-- Imitation Deep Thoughts [Age 15]
Don Geddis <···@geddis.org> writes:
> The answer to some of these questions is clearly for deliberate historical
> reasons. There is little to be gained by a gratuitous change, and a large
> cost in terms of re-writing volumes of old code.
>
> Common Lisp was not designed from scratch from a blank slate. Many changes
> were made to the existing Lisp dialects, where there was significant value to
> be gained. If there was little value to be gained, then backwards
> compatibility was judged to be the deciding factor.
>
> This is as true today as it was when Common Lisp was first designed a few
> decades ago. In that sense, it's a little unfair to complain about some
> minor irregularities. They aren't mistakes. The tradeoffs were examined
> deliberately, and a choice was made to keep them as is.
Quite true.
And this affects not just Common Lisp, but any language that has a large
based of existing programs.
Consider Java, for instance. Even in its relatively short evolution,
there have been a number of changes, but when new items have come into
being, the old were (necessarily) left in to avoid breaking existing
code. So in real, fielded systems, backwards compatibility is a real
issue. For example:
Both Enumerations and Iterators
I/O has both Input and Output Streams as well as Readers and Writers.
and other examples.
Only rarely are changes made to the language that can break existing
code, like the introduction of new reserved words.
--
Thomas A. Russ, USC/Information Sciences Institute
On Sep 11, 11:28 am, are <·········@gmx.net> wrote:
> The seemingly fragmented development of new versions of Lisp (Arc,
> GOO, Otter, you name it) makes me wonder whether ANSI is actively
> working on a new version.
What every lisper ought to do before he dies:
"Plant a tree, write a book, create his own dialect of lisp"
Slobodan Blazeski <·················@gmail.com> writes:
> On Sep 11, 11:28 am, are <·········@gmx.net> wrote:
> > The seemingly fragmented development of new versions of Lisp (Arc,
> > GOO, Otter, you name it) makes me wonder whether ANSI is actively
> > working on a new version.
> What every lisper ought to do before he dies:
> "Plant a tree, write a book, create his own dialect of lisp"
I don't agree, incidentally, except in the trivial sense that Lisp is
designed so that every program feels like it's own embedded dialect,
since it extends the underlying language (potentially in both
functionality and syntax) and produces a new context in which to do
new operations.
Personally, I'd rather see people focus on planting trees... too many
are being cut down these days. It's going to be Easter Planet sometime
soon if we're not careful. Sigh.
(That's a reference to Easter Island for those who don't catch it.
If you don't know why that's relevant, it's a sobering thing to
read up on. It doesn't speak well to human nature's ability to
recognize approaching disasters and act on them in time.)
Kent M Pitman wrote:
> (That's a reference to Easter Island for those who don't catch it.
> If you don't know why that's relevant, it's a sobering thing to
> read up on. It doesn't speak well to human nature's ability to
> recognize approaching disasters and act on them in time.)
What, chopping down all trees just to erect a couple tourist attractions
for some future overseas tourists?
Maybe Earth will be an archaeological tourist attraction for visitors
from N'um Gz'ieh some dozen million years from now.
Simple uniform code/data description allegedly found in strata -- proof
that primitive intelligence once inhabited Earth. Did it live in warm
puddles?
On Sep 12, 4:06 pm, Kent M Pitman <······@nhplace.com> wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > On Sep 11, 11:28 am, are <·········@gmx.net> wrote:
> > > The seemingly fragmented development of new versions of Lisp (Arc,
> > > GOO, Otter, you name it) makes me wonder whether ANSI is actively
> > > working on a new version.
> > What every lisper ought to do before he dies:
> > "Plant a tree, write a book, create his own dialect of lisp"
>
> I don't agree, incidentally, except in the trivial sense that Lisp is
> designed so that every program feels like it's own embedded dialect,
> since it extends the underlying language (potentially in both
> functionality and syntax) and produces a new context in which to do
> new operations.
>
> Personally, I'd rather see people focus on planting trees... too many
> are being cut down these days. It's going to be Easter Planet sometime
> soon if we're not careful. Sigh.
>
> (That's a reference to Easter Island for those who don't catch it.
> If you don't know why that's relevant, it's a sobering thing to
> read up on. It doesn't speak well to human nature's ability to
> recognize approaching disasters and act on them in time.)
It's an irony Kent. Every newbie want's to create his own flawless
lisp (or prefer ANSI committe to design it for him) without being
aware why that's not such a good idea.
cheers
bobi
On Sep 12, 10:06 am, Kent M Pitman <······@nhplace.com> wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > On Sep 11, 11:28 am, are <·········@gmx.net> wrote:
> > > The seemingly fragmented development of new versions of Lisp (Arc,
> > > GOO, Otter, you name it) makes me wonder whether ANSI is actively
> > > working on a new version.
> > What every lisper ought to do before he dies:
> > "Plant a tree, write a book, create his own dialect of lisp"
>
> I don't agree, incidentally, except in the trivial sense that Lisp is
> designed so that every program feels like it's own embedded dialect,
> since it extends the underlying language (potentially in both
> functionality and syntax) and produces a new context in which to do
> new operations.
>
> Personally, I'd rather see people focus on planting trees... too many
> are being cut down these days. It's going to be Easter Planet sometime
> soon if we're not careful. Sigh.
>
> (That's a reference to Easter Island for those who don't catch it.
> If you don't know why that's relevant, it's a sobering thing to
> read up on. It doesn't speak well to human nature's ability to
> recognize approaching disasters and act on them in time.)
Read "Collapse" by Jared Diamond. Discusses Easter Island and other
societies that did and some that were supposed to but did not
collapse.
Mirko