From: Elena
Subject: Common Lisp's fixable issues?
Date: 
Message-ID: <8eaa84c8-bad3-4557-a9e4-07fb5665817f@e35g2000yqc.googlegroups.com>
Since it's unlikely that Common Lisp gets an updated specification
fixing issues programmers have met in using it for years, and since
standards usually have not fixing issues as a goal anyway, I wonder if
you have been bothered by some issues in Common Lisp and have
developed a workaround for them.

For instance, I remember one user complaining that Common Lisp doesn't
adopt a consistent and  convenient naming convention for destructive
procedures: some have "N" as prefix (e.g. "NCONC"), whilst others
don't (e.g. "PUSH"). Another user answered and suggested writing a
package which renamed destructive procedures in a consistent way (e.g.
"CONC!", "PUSH!", etc).

What are your experiences and your suggestions?

Thanks

From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <3aa140a6-9e46-40a2-84cb-b35b3b63551b@37g2000yqp.googlegroups.com>
I posted this question because I have observed newbies learn a
language by following its syntax and API specification and mistakenly
assuming they reflect current best practices. How many young
programmers I've known learned C/C++ and began programming using
"compressed" identifiers and features intended for backward
compatibility! I made them aware of that and shared with them best
practices I've learned and when possible, workarounds I have been
using for a while.

Now, since I'm learning Common Lisp, I'd like to ask more experienced
programmers which features they think don't reflect best practices
(anymore) and if they have developed some workarounds.

Thank you very much
From: Alessio Stalla
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <f219b48c-e281-4e9a-b523-4125952c7daa@p11g2000yqe.googlegroups.com>
On 22 Mar, 15:53, Elena <········@gmail.com> wrote:
> I posted this question because I have observed newbies learn a
> language by following its syntax and API specification and mistakenly
> assuming they reflect current best practices. How many young
> programmers I've known learned C/C++ and began programming using
> "compressed" identifiers and features intended for backward
> compatibility! I made them aware of that and shared with them best
> practices I've learned and when possible, workarounds I have been
> using for a while.
>
> Now, since I'm learning Common Lisp, I'd like to ask more experienced
> programmers which features they think don't reflect best practices
> (anymore) and if they have developed some workarounds.
>
> Thank you very much

Common Lisp is sometimes criticized for its effort to be backwards-
compatible with some of the Lisps that were popular before it. It
seems to me that this critiques mostly involve naming and/or argument
ordering of some operators. As you noted, you can easily "fix" these
issues if they bother you.

Apart from that, there are a number of idioms that are generally
avoided, e.g. classes are generally preferred to structures, require/
provide are deprecated, and so on. Also people often add some features
generally considered to be useful & missing (e.g. global lexical
variables). But I find these to be of minor importance - you can live
without them most of the time and implement them easily (or grab
someone else's implementation) when you need them.

In general, I think the Common Lisp standard is/was very innovative:
it didn't merely document the existing, but actually introduced some
powerful innovations (e.g. CLOS, the condition system, etc.), while
allowing for extensions which can be pretty radical - how many
languages allow libraries to change so much language semantics to,
e.g., introduce continuations into the language?

Alessio
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c6627a$0$20289$607ed4bc@cv.net>
Elena wrote:
> I posted this question because I have observed newbies learn a
> language by following its syntax and API specification and mistakenly
> assuming they reflect current best practices. How many young
> programmers I've known learned C/C++ and began programming using
> "compressed" identifiers and features intended for backward
> compatibility! I made them aware of that and shared with them best
> practices I've learned and when possible, workarounds I have been
> using for a while.
> 
> Now, since I'm learning Common Lisp, I'd like to ask more experienced
> programmers which features they think don't reflect best practices
> (anymore)

Don't use lists for everything. Everything else is fine.

> and if they have developed some workarounds.

defstruct and defclass

kt
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <a3cab9e7-67e3-4524-be3a-73487ca99f1d@z1g2000yqn.googlegroups.com>
Very well, I wasn't expecting radical issues and/or workarounds, just
little tweaks which you have found easing your everyday work. Aren't
we expected to shape Common Lisp in our own language of choice? If
we'd have to fix a lot, maybe the language is just broken and we'd
better change it. OTOH, some people think that the tweaks they use are
not worth sharing because they are minor and reflect their own way of
getting things done. I don't think so. Maybe I can't think of myself
as being as smart as to discover all possible tweaks, and I'm not
affected by the NIH syndrome. I've often found that tricks employed by
other people worked for me too, and I'm grateful those people spent
the time to share.

Therefore, in my path to learning Lisp I'm going to:
- using ! as a suffix to recognize destructive operations (Scheme);
- prefer classes to structures (Alessio Stalla);
- avoid using require/provide (A. S.);
- learn about global lexical variables (A. S.);
- learn thoroughly about the available structures (Kenneth Tilton);
- learn about defstruct and defclass (K. T.);

I agree that the issues I'm concerned about are minor, but that's why
I'd like to fix them. For instance, being a C++ programmer, I've
written a few macros to write:

if (a eq 1 and b ne 3)

instead of:

if (a == 1 && b != 3)

Why? Because "and" is much easier to read and I can't mistype/misread
it for "&"; "eq" and "ne" are less easier to read but still I can't
mistype/misread them with "=" and "|=". I also use a "when" macro to
mean an "if" intentionally without "else", and so forth... I agree
that other programmers used to the standard syntax are puzzled when
reading my code, but by using standard syntax I would be burdened by
fear of making mistakes, and when developing code I want to be as
light as possible. I've found that whenever I explained my reasons to
other programmers, they quickly adopted my tweaks.

Programming languages, just like natural languages evolve by use
without waiting for a new standard.

Cheers
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c6ec8f$0$5940$607ed4bc@cv.net>
Elena wrote:
> Very well, I wasn't expecting radical issues and/or workarounds, just
> little tweaks which you have found easing your everyday work. Aren't
> we expected to shape Common Lisp in our own language of choice? If
> we'd have to fix a lot, maybe the language is just broken and we'd
> better change it. OTOH, some people think that the tweaks they use are
> not worth sharing because they are minor and reflect their own way of
> getting things done. I don't think so. Maybe I can't think of myself
> as being as smart as to discover all possible tweaks, and I'm not
> affected by the NIH syndrome. I've often found that tricks employed by
> other people worked for me too, and I'm grateful those people spent
> the time to share.

I see what you are up to. Head over to c-l.net and start rooting around 
looking for "personal" utility collections that had to get packaged up 
to support some larger library being released. Egomaniacs worse than I 
(hi Rahul!) actually made them top-level projects. Mine is under Cells 
somewhere. Look for "utils" in the name somewhere.


> 
> Therefore, in my path to learning Lisp I'm going to:
> - using ! as a suffix to recognize destructive operations (Scheme);
> - prefer classes to structures (Alessio Stalla);

oops.

> - avoid using require/provide (A. S.);
> - learn about global lexical variables (A. S.);
> - learn thoroughly about the available structures (Kenneth Tilton);
> - learn about defstruct and defclass (K. T.);

If you do the last two you won't have to decide engineering questions 
like they were flavors of ice cream. In any given situation, classes are 
right or structures are right. But you can still prefer chocolate to 
pistachio.

> 
> I agree that the issues I'm concerned about are minor, but that's why
> I'd like to fix them. For instance, being a C++ programmer, I've
> written a few macros to write:
> 
> if (a eq 1 and b ne 3)
> 
> instead of:
> 
> if (a == 1 && b != 3)
> 
> Why? Because "and" is much easier to read and I can't mistype/misread
> it for "&"; "eq" and "ne" are less easier to read but still I can't
> mistype/misread them with "=" and "|=". I also use a "when" macro to
> mean an "if" intentionally without "else", and so forth... I agree
> that other programmers used to the standard syntax are puzzled when
> reading my code, but by using standard syntax I would be burdened by
> fear of making mistakes, and when developing code I want to be as
> light as possible. I've found that whenever I explained my reasons to
> other programmers, they quickly adopted my tweaks.
> 
> Programming languages, just like natural languages evolve by use
> without waiting for a new standard.

Scour all those utils packages and maybe you can come up with a 
universal-utils package. Paul Graham's "On Lisp" has a bunch, too.

I just feel bad that you are missing the forest for that one little twig 
over there. The point of Lisp is the whiplash you get from programming 
faster than you ever thought possible. The utils you will find are cures 
for the trivial things that produce irritating drag at warp speed and 
will not matter until you get to warp speed. So...

Didn't you have an application you wanted to write?

:)

kt
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <42e0efbe-4418-4083-bf91-bb8bcc2256f7@g19g2000yql.googlegroups.com>
On 23 Mar, 02:57, Kenneth Tilton <·········@gmail.com> wrote:
> Elena wrote:
> > Therefore, in my path to learning Lisp I'm going to:
> > - using ! as a suffix to recognize destructive operations (Scheme);
> > - prefer classes to structures (Alessio Stalla);
>
> oops.

Why not? As a C++ programmer, I've trashed "class" and I'm using
"struct" all the time. They are equivalent, but "struct" allows much
shorter declarations. Maybe structures and classes in Common Lisp are
in the same league.
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c7e9c4$0$22535$607ed4bc@cv.net>
Elena wrote:
> On 23 Mar, 02:57, Kenneth Tilton <·········@gmail.com> wrote:
>> Elena wrote:
>>> Therefore, in my path to learning Lisp I'm going to:
>>> - using ! as a suffix to recognize destructive operations (Scheme);
>>> - prefer classes to structures (Alessio Stalla);
>> oops.
> 
> Why not? As a C++ programmer, I've trashed "class" and I'm using
> "struct" all the time. They are equivalent, but "struct" allows much
> shorter declarations. Maybe structures and classes in Common Lisp are
> in the same league.

I should have provided a forward reference to what came later in my 
response: preference does not enter into it. Don't use defclass where 
defstruct will do, period.

btw, in this case it is not about succinctness of code. defstructs can 
be terser, but we commune lispers like our cobol lisp (I think I have 
that right). what we do not like is slow code like Ruby, and CLOS is a 
pig at runtime.
From: Thomas F. Burdick
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <7ac58fc0-5bc3-4f1e-a972-de0e96779493@j38g2000yqa.googlegroups.com>
On 23 mar, 20:58, Kenneth Tilton <·········@gmail.com> wrote:

> btw, in this case it is not about succinctness of code. defstructs can
> be terser, but we commune lispers like our cobol lisp (I think I have
> that right). what we do not like is slow code like Ruby, and CLOS is a
> pig at runtime.

Ken, you ignorant slut. Ruby tasted like shit. Defstruct tasted like
paper. Defclass tasted like slow paper. None of them tasted like pig.
KR, though, tasted like five-spice roasted pork!

(Oh, and Cells tasted "a little like shit, but not too much". I'll
leave the French Pascal to translate that mess for you ... I tried to
find a tempting picture, but they all looked nasty. I think there
might be a universal point here.)
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c830c1$0$24471$607ed4bc@cv.net>
Thomas F. Burdick wrote:
> On 23 mar, 20:58, Kenneth Tilton <·········@gmail.com> wrote:
> 
>> btw, in this case it is not about succinctness of code. defstructs can
>> be terser, but we commune lispers like our cobol lisp (I think I have
>> that right). what we do not like is slow code like Ruby, and CLOS is a
>> pig at runtime.
> 
> Ken, you ignorant slut. Ruby tasted like shit. Defstruct tasted like
> paper. Defclass tasted like slow paper. None of them tasted like pig.
> KR, though, tasted like five-spice roasted pork!
> 
> (Oh, and Cells tasted "a little like shit, but not too much". I'll
> leave the French Pascal to translate that mess for you ... I tried to
> find a tempting picture, but they all looked nasty. I think there
> might be a universal point here.)

Wait. You're still coming to the annual dataflow conference in monte 
carlo, yes? How is c4 coming?

kt
From: Thomas F. Burdick
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <5476c512-a840-4437-a30c-a31a73cc144a@v19g2000yqn.googlegroups.com>
On 24 mar, 02:00, Kenneth Tilton <·········@gmail.com> wrote:
> Thomas F. Burdick wrote:
> > On 23 mar, 20:58, Kenneth Tilton <·········@gmail.com> wrote:
>
> >> btw, in this case it is not about succinctness of code. defstructs can
> >> be terser, but we commune lispers like our cobol lisp (I think I have
> >> that right). what we do not like is slow code like Ruby, and CLOS is a
> >> pig at runtime.
>
> > Ken, you ignorant slut. Ruby tasted like shit. Defstruct tasted like
> > paper. Defclass tasted like slow paper. None of them tasted like pig.
> > KR, though, tasted like five-spice roasted pork!
>
> > (Oh, and Cells tasted "a little like shit, but not too much". I'll
> > leave the French Pascal to translate that mess for you ... I tried to
> > find a tempting picture, but they all looked nasty. I think there
> > might be a universal point here.)
>
> Wait. You're still coming to the annual dataflow conference in monte
> carlo, yes? How is c4 coming?

Well yeah, that sounds a lot nicer than the reactive conference in
Hanford, WA.

Unfortunately I haven't had much opportunity to use dataflow harnesses
recently. Every time I catch a bug that would have been impossible
with a proper reactive setup, it hurts. So C4 is on ice at the moment,
as it's not being used, and I don't feel any particular need to
increase the amount of CL abandonware in the intertubes.

I see that you've changed the Cells license back to something
reasonable, though (LLGPL). Or was I tripping and it was never GPL? In
any case, I probably jump back on the Cells bandwagon if my next
dataflow opportunity is in CL.

And I found a picture: http://www.restaurant-le-prieure.com/photos/andouillette.jpg
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c8dec3$0$5918$607ed4bc@cv.net>
Thomas F. Burdick wrote:
> On 24 mar, 02:00, Kenneth Tilton <·········@gmail.com> wrote:
>> Thomas F. Burdick wrote:
>>> On 23 mar, 20:58, Kenneth Tilton <·········@gmail.com> wrote:
>>>> btw, in this case it is not about succinctness of code. defstructs can
>>>> be terser, but we commune lispers like our cobol lisp (I think I have
>>>> that right). what we do not like is slow code like Ruby, and CLOS is a
>>>> pig at runtime.
>>> Ken, you ignorant slut. Ruby tasted like shit. Defstruct tasted like
>>> paper. Defclass tasted like slow paper. None of them tasted like pig.
>>> KR, though, tasted like five-spice roasted pork!
>>> (Oh, and Cells tasted "a little like shit, but not too much". I'll
>>> leave the French Pascal to translate that mess for you ... I tried to
>>> find a tempting picture, but they all looked nasty. I think there
>>> might be a universal point here.)
>> Wait. You're still coming to the annual dataflow conference in monte
>> carlo, yes? How is c4 coming?
> 
> Well yeah, that sounds a lot nicer than the reactive conference in
> Hanford, WA.
> 
> Unfortunately I haven't had much opportunity to use dataflow harnesses
> recently. Every time I catch a bug that would have been impossible
> with a proper reactive setup, it hurts. So C4 is on ice at the moment,
> as it's not being used, and I don't feel any particular need to
> increase the amount of CL abandonware in the intertubes.
> 
> I see that you've changed the Cells license back to something
> reasonable, though (LLGPL). Or was I tripping and it was never GPL? 

Hard to say. It is indeed possible I had it GPL for a week before coming 
to my senses and maybe you happened to snag it then. It was MIT for the 
longest time and I think LLGPL was your idea.

> In
> any case, I probably jump back on the Cells bandwagon if my next
> dataflow opportunity is in CL.
> 
> And I found a picture: http://www.restaurant-le-prieure.com/photos/andouillette.jpg

Oh, thank goodness. Er...have I forgotten a reference?

kt
From: Thomas F. Burdick
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <d196221d-31e3-476e-956c-a58cfb9b1f91@e38g2000yqa.googlegroups.com>
On 24 mar, 14:23, Kenneth Tilton <·········@gmail.com> wrote:
> Thomas F. Burdick wrote:
> > On 24 mar, 02:00, Kenneth Tilton <·········@gmail.com> wrote:
> >> Thomas F. Burdick wrote:
> >>> On 23 mar, 20:58, Kenneth Tilton <·········@gmail.com> wrote:
> >>>> btw, in this case it is not about succinctness of code. defstructs can
> >>>> be terser, but we commune lispers like our cobol lisp (I think I have
> >>>> that right). what we do not like is slow code like Ruby, and CLOS is a
> >>>> pig at runtime.
> >>> Ken, you ignorant slut. Ruby tasted like shit. Defstruct tasted like
> >>> paper. Defclass tasted like slow paper. None of them tasted like pig.
> >>> KR, though, tasted like five-spice roasted pork!
> >>> (Oh, and Cells tasted "a little like shit, but not too much". I'll
> >>> leave the French Pascal to translate that mess for you ... I tried to
> >>> find a tempting picture, but they all looked nasty. I think there
> >>> might be a universal point here.)
> >> Wait. You're still coming to the annual dataflow conference in monte
> >> carlo, yes? How is c4 coming?
>
> > Well yeah, that sounds a lot nicer than the reactive conference in
> > Hanford, WA.
>
> > Unfortunately I haven't had much opportunity to use dataflow harnesses
> > recently. Every time I catch a bug that would have been impossible
> > with a proper reactive setup, it hurts. So C4 is on ice at the moment,
> > as it's not being used, and I don't feel any particular need to
> > increase the amount of CL abandonware in the intertubes.
>
> > I see that you've changed the Cells license back to something
> > reasonable, though (LLGPL). Or was I tripping and it was never GPL?
>
> Hard to say. It is indeed possible I had it GPL for a week before coming
> to my senses and maybe you happened to snag it then. It was MIT for the
> longest time and I think LLGPL was your idea.

Ah, that sounds possible.

> > In
> > any case, I probably jump back on the Cells bandwagon if my next
> > dataflow opportunity is in CL.
>
> > And I found a picture:http://www.restaurant-le-prieure.com/photos/andouillette.jpg
>
> Oh, thank goodness. Er...have I forgotten a reference?

I said that Cells tasted like shit, but not too much? A famous
quotation is that politics is like andouillette, it should smell like
shit, but not too much. And andouillette is really tasty. Except
having just looked it up, apparently it was Clemenceau (ick) who said
that, so I take it back.
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c8ef4c$0$20294$607ed4bc@cv.net>
Thomas F. Burdick wrote:
> I said that Cells tasted like shit, 

You've been talking to Costanza!

Anyway, I decided to go with raw HTML and CSS instead of qooxdoo for 
WebCells, no Javascript of course since I want all the action in Cells 
anyway. Expect blinding speed and astonishing expressiveness. Soon even 
the most obtuse yobbo will be force to bow before His Kennyness.

kt
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49ca00e2$0$22526$607ed4bc@cv.net>
Rob Warnock wrote:
> Kenneth Tilton  <·········@gmail.com> wrote:
> +---------------
> | Anyway, I decided to go with raw HTML and CSS instead of qooxdoo for 
> | WebCells...
> +---------------
> 
> So are you using HTOUT, CL-WHO, or something of your own devising
> to emit the HTML?
> 
> 

Wait. Commie Pinko Lisp does not have a built-in standard HTML library? 
PWUAUAHHHAHAHAHHAA! <loser!!!!/>

Which one* did Edi write? I'll use that. I use ACL's now but of course 
if I want to rule the world (I do! I do!) I better make it free so I can 
suck in all the skinflint moneysaving hours spending on free software 
hassles yobbos.

<k/>

* I mean which one out of the three he wrote is best?
From: Rob Warnock
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <8sedna5ozf9olVfUnZ2dnUVZ_q7inZ2d@speakeasy.net>
Kenneth Tilton  <·········@gmail.com> wrote:
+---------------
| Rob Warnock wrote:
| > So are you using HTOUT, CL-WHO, or something of your own devising
| > to emit the HTML?
| 
| Wait. Commie Pinko Lisp does not have a built-in standard HTML library? 
| PWUAUAHHHAHAHAHHAA! <loser!!!!/>
| 
| Which one* did Edi write? I'll use that. I use ACL's now...
+---------------

Lessee here...

Tim Bradshaw wrote HTOUT <http://www.tfeb.org/lisp/hax.html#HTOUT>
(which I use, mainly because it was there first) and Edi Weitz wrote
CL-WHO <http://weitz.de/cl-who/>, but there's a combination of options
that makes their user interfaces nearly identical so I'd be inclined to
give the user their choice. [Oh, and both have non-viral free licenses...]

But if you're already using ACL's (John Foderaro's), then you
should know that HTMLGEN is available under an LLGPL license, see
<http://www.cliki.net/htmlgen> & <http://constantly.at/lisp/htmlgen.tar.gz>.

Of course, there are certainly a bunch of others out there, see
<http://www.cliki.net/Lisp%20Markup%20Languages>, but probably one
or more of the above three is what you want.

+---------------
| * I mean which one out of the three he wrote is best?
+---------------

What were the other two? I only know about CL-WHO.


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49ca0c92$0$22535$607ed4bc@cv.net>
Rob Warnock wrote:
> Kenneth Tilton  <·········@gmail.com> wrote:
> +---------------
> | Rob Warnock wrote:
> | > So are you using HTOUT, CL-WHO, or something of your own devising
> | > to emit the HTML?
> | 
> | Wait. Commie Pinko Lisp does not have a built-in standard HTML library? 
> | PWUAUAHHHAHAHAHHAA! <loser!!!!/>
> | 
> | Which one* did Edi write? I'll use that. I use ACL's now...
> +---------------
> 
> Lessee here...
> 
> Tim Bradshaw wrote HTOUT <http://www.tfeb.org/lisp/hax.html#HTOUT>
> (which I use, mainly because it was there first) and Edi Weitz wrote
> CL-WHO <http://weitz.de/cl-who/>, but there's a combination of options
> that makes their user interfaces nearly identical so I'd be inclined to
> give the user their choice. [Oh, and both have non-viral free licenses...]
> 
> But if you're already using ACL's (John Foderaro's), then you
> should know that HTMLGEN is available under an LLGPL license, see
> <http://www.cliki.net/htmlgen> & <http://constantly.at/lisp/htmlgen.tar.gz>.
> 
> Of course, there are certainly a bunch of others out there, see
> <http://www.cliki.net/Lisp%20Markup%20Languages>, but probably one
> or more of the above three is what you want.

Well, com etot hinko fit, I have to go ba k to option 3 (?) you offered 
originally: webcells will be its own html generator. Sorry for putting 
you thru all that.

Same deal as with cells-gtk and celtk: one builds a hierarchy of clos 
classes (hmm maybe I should roll my own object model based on rdf while 
I am at it?) whose slots correspond to tag options and webcells 
generates the DHTML.


> 
> +---------------
> | * I mean which one out of the three he wrote is best?
> +---------------
> 
> What were the other two? I only know about CL-WHO.

Maybe I am thinking of the three web servers he wrote?

kt
From: Alessio Stalla
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <c41c9d8d-5653-463f-8097-47539ff5f668@r33g2000yqn.googlegroups.com>
On Mar 23, 8:45 pm, Elena <········@gmail.com> wrote:
> On 23 Mar, 02:57, Kenneth Tilton <·········@gmail.com> wrote:
>
> > Elena wrote:
> > > Therefore, in my path to learning Lisp I'm going to:
> > > - using ! as a suffix to recognize destructive operations (Scheme);
> > > - prefer classes to structures (Alessio Stalla);
>
> > oops.
>
> Why not? As a C++ programmer, I've trashed "class" and I'm using
> "struct" all the time. They are equivalent, but "struct" allows much
> shorter declarations. Maybe structures and classes in Common Lisp are
> in the same league.

I did not mean to say structures should never be used; in CL, classes
and structures are two similar but different things, not two
alternative syntaxes for the same construct. (btw, I didn't know about
struct/class in C++, else I would have put more care into what I
said). CL structures are more efficient than classes, but less
versatile, so I'd advise starting with classes and maybe turn them
into structures later if performance matters, rather than starting
with structures only to have to turn them into classes when you need
proper OO.

A.
From: Pascal Costanza
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <72o340Fqq558U1@mid.individual.net>
Elena wrote:
> Very well, I wasn't expecting radical issues and/or workarounds, just
> little tweaks which you have found easing your everyday work. Aren't
> we expected to shape Common Lisp in our own language of choice? If
> we'd have to fix a lot, maybe the language is just broken and we'd
> better change it. OTOH, some people think that the tweaks they use are
> not worth sharing because they are minor and reflect their own way of
> getting things done. I don't think so. Maybe I can't think of myself
> as being as smart as to discover all possible tweaks, and I'm not
> affected by the NIH syndrome. I've often found that tricks employed by
> other people worked for me too, and I'm grateful those people spent
> the time to share.
> 
> Therefore, in my path to learning Lisp I'm going to:
> - using ! as a suffix to recognize destructive operations (Scheme);

That's one of the things I find really ugly in Common Lisp code.

> - prefer classes to structures (Alessio Stalla);
> - avoid using require/provide (A. S.);
> - learn about global lexical variables (A. S.);
> - learn thoroughly about the available structures (Kenneth Tilton);
> - learn about defstruct and defclass (K. T.);
> 
> I agree that the issues I'm concerned about are minor, but that's why
> I'd like to fix them. 

LispWorks comes with a package with some "straightforward" extensions to 
Common Lisp. The package is actually called "LISPWORKS". Of that 
package, I regularly use with-unique-names, rebinding, removef and, to a 
lesser extent, deletef.

Apart from that, I don't really miss a lot.

> Programming languages, just like natural languages evolve by use
> without waiting for a new standard.

Indeed.


Pascal

-- 
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <74bd8c06-97dc-4b74-b4e1-a5af4cfb97d8@j8g2000yql.googlegroups.com>
On 23 Mar, 01:23, Pascal Costanza <····@p-cos.net> wrote:
> Elena wrote:
> > Therefore, in my path to learning Lisp I'm going to:
> > - using ! as a suffix to recognize destructive operations (Scheme);
>
> That's one of the things I find really ugly in Common Lisp code.

Would you suggest a prettier naming convention, easy to spot and
search?
From: Pascal Costanza
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <72ob0rFranvnU1@mid.individual.net>
Elena wrote:
> On 23 Mar, 01:23, Pascal Costanza <····@p-cos.net> wrote:
>> Elena wrote:
>>> Therefore, in my path to learning Lisp I'm going to:
>>> - using ! as a suffix to recognize destructive operations (Scheme);
>> That's one of the things I find really ugly in Common Lisp code.
> 
> Would you suggest a prettier naming convention, easy to spot and
> search?

I don't see the use for such a naming convention. It's kind of 
arbitrary. What's so special about side effects, after all?

Are there special naming conventions for functions that use call/cc? For 
functions that rebind special variables? For functions that print 
something on the screen? For functions that allocate new storage? Etc., 
etc.?


Pascal

-- 
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Pillsy
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <8754a5be-f2d4-4c02-8386-90dd7289e6bb@p20g2000yqi.googlegroups.com>
On Mar 22, 10:38 pm, Pascal Costanza <····@p-cos.net> wrote:
> Elena wrote:
[...]
> > Would you suggest a prettier naming convention, easy to spot and
> > search?

> I don't see the use for such a naming convention.

The main use is that many useful functions can be done with side-
effects and without. Both REVERSE and NREVERSE are useful things to
have in the language, and it's nice to be able to distinguish between
them.

Likewise with SUBSEQ and NSUBSEQ, or NCONC and APPEND. Except if
you're going to have a convention, you might as well follow it. Even
if you know about REVERSE and NREVERSE, you won't have any particular
way of figuring out which of DELETE and REMOVE is the destructive
one.

Arguably, the NFOO semi-convention is Common Lisp highlights the
"specialness" of these particular routines better, because the whole
point of using them is that they're non-consing.

Cheers, Pillsy
From: Javier
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <gq87fa$t69$1@aioe.org>
Pascal Costanza escribi�:

> Are there special naming conventions for functions that use call/cc? For
> functions that rebind special variables? For functions that print
> something on the screen? For functions that allocate new storage? Etc.,
> etc.?

For functions doing side effects: yes. Even, people are constructing or
using new languages* that tries to avoid them, so we can consider it a
mayor issue, that much to deserve a special notation.

* i.e: Clojure, Hashell, Ocaml....
From: Pascal Costanza
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <72pmp5Fqrg34U1@mid.individual.net>
Javier wrote:
> Pascal Costanza escribi�:
> 
>> Are there special naming conventions for functions that use call/cc? For
>> functions that rebind special variables? For functions that print
>> something on the screen? For functions that allocate new storage? Etc.,
>> etc.?
> 
> For functions doing side effects: yes. Even, people are constructing or
> using new languages* that tries to avoid them, so we can consider it a
> mayor issue, that much to deserve a special notation.
> 
> * i.e: Clojure, Hashell, Ocaml....

There are also languages trying to come up with new syntax. Doesn't make 
it a major issue either.


Pascal

-- 
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: ···@crispylogics.com
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <6147dd49-ac30-46ca-b83d-c0768b7a088c@h28g2000yqd.googlegroups.com>
On 23 Mrz., 01:39, Elena <········@gmail.com> wrote:
> On 23 Mar, 01:23, Pascal Costanza <····@p-cos.net> wrote:
>
> > Elena wrote:
> > > Therefore, in my path to learning Lisp I'm going to:
> > > - using ! as a suffix to recognize destructive operations (Scheme);
>
> > That's one of the things I find really ugly in Common Lisp code.
>
> Would you suggest a prettier naming convention, easy to spot and
> search?

To me - things like ! and ? in operator names are more like name
encodings than name conventions.

I don't like the idea of encoding such things in the name of
operations. Why should I use an operator without knowing what it does?
The very first sentence for CL:SORT in the HyperSpec tells me: "sort
and stable-sort destructively sort sequences..." (http://
www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_sortcm_stable-sort.html).
Similarily, I also always hated naming conventions in C++ were the
type of the variable binding is encoded into the variable name; which
actually just solves the problem of having a bad IDE. It makes things
unreadable and distracts you from more important things. It's better
to have a quick path to your documentation than to encode the
documentation into every identifier-use over your whole program.

Another point: Scheme is quite different to Common Lisp; It emphasises
a functional style more than CL. If you use Scheme as a teaching tool
it is comfortable to be able to tell your students not to use any
operator with a ! in its name. So for me using ! and ? to markup some
attributes of an operator is more a thing that helps teachers getting
their point across, than it actually helps actual programmers.

--
Jochen Schmidt
CRISPYLOGICS
Uhlandstr. 9, 90408 Nuremberg

Fon +49 (0)911 517 999 82
Fax +49 (0)911 517 999 83

mailto:(format nil "~(····@~36r.~36r~)" 870180 1680085828711918828
16438) http://www.crispylogics.com
From: Tobias C. Rittweiler
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <8763i0rwe3.fsf@freebits.de>
···@crispylogics.com writes:

> To me - things like ! and ? in operator names are more like name
> encodings than name conventions.

Do you use the -P convention? How is it different?

  -T.
From: ···@crispylogics.com
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <ac8046fd-5c71-4916-9717-7ab59e2d68f8@q16g2000yqg.googlegroups.com>
On 23 Mrz., 18:17, "Tobias C. Rittweiler" <····@freebits.de.invalid>
wrote:
> ····@crispylogics.com writes:
> > To me - things like ! and ? in operator names are more like name
> > encodings than name conventions.
>
> Do you use the -P convention? How is it different?
>
>   -T.

It doesn't sound silly when pronounced ;-)
From: ····················@hotmail.com
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <b2339591-8a56-4ee2-b436-a408f436b184@y13g2000yqn.googlegroups.com>
On 23 Mar, 00:12, Elena <········@gmail.com> wrote:

<snip>

> I agree that the issues I'm concerned about are minor, but that's why
> I'd like to fix them. For instance, being a C++ programmer, I've
> written a few macros to write:
>
> if (a eq 1 and b ne 3)
>
> instead of:
>
> if (a == 1 && b != 3)

read this:

http://www.dinkumware.com/manuals/?manual=compleat&page=iso646.html

> Why? Because "and" is much easier to read and I can't mistype/misread
> it for "&"; "eq" and "ne" are less easier to read but still I can't
> mistype/misread them with "=" and "|=". I also use a "when" macro to
> mean an "if" intentionally without "else", and so forth... I agree
> that other programmers used to the standard syntax are puzzled when
> reading my code, but by using standard syntax I would be burdened by
> fear of making mistakes, and when developing code I want to be as
> light as possible. I've found that whenever I explained my reasons to
> other programmers, they quickly adopted my tweaks.

I think you'd be better off getting comfortable with the usual way
of doing things and in C/C++ "&&" is much more usual than "and".

<snip>
From: Marco Antoniotti
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <9c360c61-ea8d-4ece-8c09-2cbfdec266cd@s20g2000yqh.googlegroups.com>
On Mar 23, 11:32 am, ····················@hotmail.com wrote:
> On 23 Mar, 00:12, Elena <········@gmail.com> wrote:
>
> <snip>
>
> > I agree that the issues I'm concerned about are minor, but that's why
> > I'd like to fix them. For instance, being a C++ programmer, I've
> > written a few macros to write:
>
> > if (a eq 1 and b ne 3)
>
> > instead of:
>
> > if (a == 1 && b != 3)
>
> read this:
>
> http://www.dinkumware.com/manuals/?manual=compleat&page=iso646.html

Man!  I had forgotten about that....

Cheers
--
Marco







>
> > Why? Because "and" is much easier to read and I can't mistype/misread
> > it for "&"; "eq" and "ne" are less easier to read but still I can't
> > mistype/misread them with "=" and "|=". I also use a "when" macro to
> > mean an "if" intentionally without "else", and so forth... I agree
> > that other programmers used to the standard syntax are puzzled when
> > reading my code, but by using standard syntax I would be burdened by
> > fear of making mistakes, and when developing code I want to be as
> > light as possible. I've found that whenever I explained my reasons to
> > other programmers, they quickly adopted my tweaks.
>
> I think you'd be better off getting comfortable with the usual way
> of doing things and in C/C++ "&&" is much more usual than "and".
>
> <snip>
From: Pascal J. Bourguignon
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <874oxkh3tz.fsf@galatea.local>
····················@hotmail.com writes:

> On 23 Mar, 00:12, Elena <········@gmail.com> wrote:
>
> <snip>
>
>> I agree that the issues I'm concerned about are minor, but that's why
>> I'd like to fix them. For instance, being a C++ programmer, I've
>> written a few macros to write:
>>
>> if (a eq 1 and b ne 3)
>>
>> instead of:
>>
>> if (a == 1 && b != 3)
>
> read this:
>
> http://www.dinkumware.com/manuals/?manual=compleat&page=iso646.html
>
>> Why? Because "and" is much easier to read and I can't mistype/misread
>> it for "&"; "eq" and "ne" are less easier to read but still I can't
>> mistype/misread them with "=" and "|=". I also use a "when" macro to
>> mean an "if" intentionally without "else", and so forth... I agree
>> that other programmers used to the standard syntax are puzzled when
>> reading my code, but by using standard syntax I would be burdened by
>> fear of making mistakes, and when developing code I want to be as
>> light as possible. I've found that whenever I explained my reasons to
>> other programmers, they quickly adopted my tweaks.
>
> I think you'd be better off getting comfortable with the usual way
> of doing things and in C/C++ "&&" is much more usual than "and".

However, and is _standard_ (#include <iso646.h>) so you can use it
even on project where your own #define are frowned upon. ;-)

-- 
__Pascal Bourguignon__
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <472d2be3-83a8-47b9-9119-accd16a8e3d4@p11g2000yqe.googlegroups.com>
On 23 Mar, 12:32, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> ····················@hotmail.com writes:
> > On 23 Mar, 00:12, Elena <········@gmail.com> wrote:
>
> > <snip>
>
> >> I agree that the issues I'm concerned about are minor, but that's why
> >> I'd like to fix them. For instance, being a C++ programmer, I've
> >> written a few macros to write:
>
> >> if (a eq 1 and b ne 3)
>
> >> instead of:
>
> >> if (a == 1 && b != 3)
>
> > read this:
>
> >http://www.dinkumware.com/manuals/?manual=compleat&page=iso646.html
>
> >> Why? Because "and" is much easier to read and I can't mistype/misread
> >> it for "&"; "eq" and "ne" are less easier to read but still I can't
> >> mistype/misread them with "=" and "|=". I also use a "when" macro to
> >> mean an "if" intentionally without "else", and so forth... I agree
> >> that other programmers used to the standard syntax are puzzled when
> >> reading my code, but by using standard syntax I would be burdened by
> >> fear of making mistakes, and when developing code I want to be as
> >> light as possible. I've found that whenever I explained my reasons to
> >> other programmers, they quickly adopted my tweaks.
>
> > I think you'd be better off getting comfortable with the usual way
> > of doing things and in C/C++ "&&" is much more usual than "and".
>
> However, and is _standard_ (#include <iso646.h>) so you can use it
> even on project where your own #define are frowned upon. ;-)
>
> --
> __Pascal Bourguignon__

You got it, Pascal. That's how I've sold it: "Look! They've already
done it. They are standard headers. You think you're way smarter than
your own compiler writers, do you?" :-)))))
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <2d83c84c-1fa2-454b-893f-d241bd6055a8@e35g2000yqc.googlegroups.com>
On 23 Mar, 11:32, ····················@hotmail.com wrote:
> On 23 Mar, 00:12, Elena <········@gmail.com> wrote:
>
> <snip>
>
> > I agree that the issues I'm concerned about are minor, but that's why
> > I'd like to fix them. For instance, being a C++ programmer, I've
> > written a few macros to write:
>
> > if (a eq 1 and b ne 3)
>
> > instead of:
>
> > if (a == 1 && b != 3)
>
> read this:
>
> http://www.dinkumware.com/manuals/?manual=compleat&page=iso646.html

I already know and use that full time. Indeed, that header gave me the
idea... Therefore I took the "eq" and "ne" from Perl (I'm such an
unoriginal person :-/ ).

Thank you for pointing that out: can you all understand why I'm
looking for hints?

>
> > Why? Because "and" is much easier to read and I can't mistype/misread
> > it for "&"; "eq" and "ne" are less easier to read but still I can't
> > mistype/misread them with "=" and "|=". I also use a "when" macro to
> > mean an "if" intentionally without "else", and so forth... I agree
> > that other programmers used to the standard syntax are puzzled when
> > reading my code, but by using standard syntax I would be burdened by
> > fear of making mistakes, and when developing code I want to be as
> > light as possible. I've found that whenever I explained my reasons to
> > other programmers, they quickly adopted my tweaks.
>
> I think you'd be better off getting comfortable with the usual way
> of doing things and in C/C++ "&&" is much more usual than "and".

Never. Never. Never. Maybe I'd also be better off using a Qwerty
keyboard instead of the customized Dvorak I'm typing on. I like to get
out of the office ASAP, any booster is really appreciated. Or maybe
I'm just an outcast :-(
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c66074$0$20288$607ed4bc@cv.net>
Elena wrote:
> Since it's unlikely that Common Lisp gets an updated specification
> fixing issues programmers have met in using it for years, and since
> standards usually have not fixing issues as a goal anyway, I wonder if
> you have been bothered by some issues in Common Lisp and have
> developed a workaround for them.
> 
> For instance, I remember one user complaining that Common Lisp doesn't
> adopt a consistent and  convenient naming convention for destructive
> procedures: some have "N" as prefix (e.g. "NCONC"), whilst others
> don't (e.g. "PUSH"). Another user answered and suggested writing a
> package which renamed destructive procedures in a consistent way (e.g.
> "CONC!", "PUSH!", etc).
> 

Harmless, delightful reminders of our roots. I use car and cadr instead 
of first and second as a way of identifying people with whom I never 
want to go drinking.

kzo
From: Javier
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <gq5q11$nak$1@aioe.org>
Kenneth Tilton escribi�:

> Harmless, delightful reminders of our roots. I use car and cadr instead
> of first and second as a way of identifying people with whom I never
> want to go drinking.

How old are you Kenny?
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c67411$0$22505$607ed4bc@cv.net>
Javier wrote:
> Kenneth Tilton escribi�:
> 
>> Harmless, delightful reminders of our roots. I use car and cadr instead
>> of first and second as a way of identifying people with whom I never
>> want to go drinking.
> 
> How old are you Kenny?

An obsession is born.
From: Javier
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <gq5ucb$sg4$1@aioe.org>
Kenneth Tilton escribi�:
> Javier wrote:
>> Kenneth Tilton escribi�:
>>
>>> Harmless, delightful reminders of our roots. I use car and cadr instead
>>> of first and second as a way of identifying people with whom I never
>>> want to go drinking.
>>
>> How old are you Kenny?
> 
> An obsession is born.

No, I asked because you are like a teenager, but without the "like".
From: eric-and-jane-smith
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <b8vxl.1879$3g7.1745@newsfe15.iad>
Javier <·······@gmail.com> wrote in ·················@aioe.org:

>>> How old are you Kenny?
>> 
>> An obsession is born.
> 
> No, I asked because you are like a teenager, but without the "like".

He's probably done more programming work than any teenager on the planet.  
Have you ever done any?
From: Javier
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <gq5va6$tu5$1@aioe.org>
eric-and-jane-smith escribi�:
> Javier <·······@gmail.com> wrote in ·················@aioe.org:
> 
>>>> How old are you Kenny?
>>> An obsession is born.
>> No, I asked because you are like a teenager, but without the "like".
> 
> He's probably done more programming work than any teenager on the planet.  

And he is probably the oldest teenager in the planet.

> Have you ever done any?

Yes.
From: André Thieme
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <gq60cr$28j$1@news.motzarella.org>
Javier schrieb:
> eric-and-jane-smith escribi�:
>> Javier <·······@gmail.com> wrote in ·················@aioe.org:
>>
>>>>> How old are you Kenny?
>>>> An obsession is born.
>>> No, I asked because you are like a teenager, but without the "like".
>> He's probably done more programming work than any teenager on the planet.  
> 
> And he is probably the oldest teenager in the planet.
> 
>> Have you ever done any?
> 
> Yes.

You can see Kenny Tilton here:
http://video.google.com/videoplay?docid=-1331906677993764413


Andr�
-- 
From: Javier
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <gq62ho$1ja$1@aioe.org>
Andr� Thieme escribi�:
> Javier schrieb:
>> eric-and-jane-smith escribi�:
>>> Javier <·······@gmail.com> wrote in ·················@aioe.org:
>>>
>>>>>> How old are you Kenny?
>>>>> An obsession is born.
>>>> No, I asked because you are like a teenager, but without the "like".
>>> He's probably done more programming work than any teenager on the
>>> planet.  
>>
>> And he is probably the oldest teenager in the planet.
>>
>>> Have you ever done any?
>>
>> Yes.
> 
> You can see Kenny Tilton here:
> http://video.google.com/videoplay?docid=-1331906677993764413

Typical crazy arrogant American, I guess. And he says he is in the path
of Buddhism? He is in the path of foolishness.

I think he is not doing any good to the CL community. Probably he his
responsible in a high percentage of people being aware of Lisp.
The other day I was talking in #Clojure, very respectful people, and
talked about c.l.l. They agreed that in c.l.l there are very closed mind
 and hostile people... well ok, but sadly c.l.l is still the heart of
the Lisp community.
From: Patrick May
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <m2bprtnvuc.fsf@spe.com>
Javier <·······@gmail.com> writes:
> Andr� Thieme escribi�:
>> You can see Kenny Tilton here:
>> http://video.google.com/videoplay?docid=-1331906677993764413
>
> Typical crazy arrogant American, I guess. And he says he is in the
> path of Buddhism? He is in the path of foolishness.
>
> I think he is not doing any good to the CL community. Probably he his
> responsible in a high percentage of people being aware of Lisp.  The
> other day I was talking in #Clojure, very respectful people, and
> talked about c.l.l. They agreed that in c.l.l there are very closed
> mind and hostile people... well ok, but sadly c.l.l is still the heart
> of the Lisp community.

     A married couple were considering moving to a new town.  They came
     to visit and, while driving in, they saw an old farmer working in
     his field.  They approached the man and asked "What are the people
     like in this town?"

     The farmer asked them "What are the people like in the town where
     you live?"

     "Oh, they're horrible." said the woman.  "Unfriendly, boring, never
     a kind word about anyone, and very stand-offish."

     "Well," said the farmer, "I expect you'll find folks around here
     just the same."

     The next day another couple contemplating moving came by and asked
     the old farmer the same question.  "What are the people like in the
     town where you live?" he asked, again.

     "Oh, they're wonderful!" said the couple.  "Friendly, interesting,
     always willing to help someone out."

     "Well," said the farmer, "I expect you'll find folks around here
     just the same."

Just another crazy, arrogant American on the eightfold path,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
http://www.spe.com/pjm | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Javier
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <gq68ma$7i6$1@aioe.org>
Patrick May escribi�:

> Just another crazy, arrogant American on the eightfold path,

Crazy is probably ok, but if you are arrogant means that you should make
some more effort to kill it if you really are in the "eightfold path".
The same with being so much biased to something (i.e. Lisp and/or American).
From: Patrick May
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <m27i2hntyk.fsf@spe.com>
Javier <·······@gmail.com> writes:
>> Just another crazy, arrogant American on the eightfold path,
>
> Crazy is probably ok, but if you are arrogant means that you should
> make some more effort to kill it if you really are in the "eightfold
> path".  The same with being so much biased to something (i.e. Lisp
> and/or American).

     I suggest you re-read my previous post (you know, the part _above_
my signature), followed by the information at this link:

          http://en.wikipedia.org/wiki/Psychological_projection

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
http://www.spe.com/pjm | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Javier
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <gq6b4f$a5l$1@aioe.org>
Patrick May escribi�:
> Javier <·······@gmail.com> writes:
>>> Just another crazy, arrogant American on the eightfold path,
>> Crazy is probably ok, but if you are arrogant means that you should
>> make some more effort to kill it if you really are in the "eightfold
>> path".  The same with being so much biased to something (i.e. Lisp
>> and/or American).
> 
>      I suggest you re-read my previous post (you know, the part _above_
> my signature),

I read it. A relativist generalization history, with the intention of
avoiding assuming a problem.


> followed by the information at this link:
> 
>           http://en.wikipedia.org/wiki/Psychological_projection


Not really. I read the common definitions, and none applies to me. But I
found this for you:


http://en.wikipedia.org/wiki/Intellectualization





> 
> Sincerely,
> 
> Patrick
> 
> ------------------------------------------------------------------------
> S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
>                        | systems design and implementation.
> http://www.spe.com/pjm | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Raffael Cavallaro
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <9a7bb83c-372f-43a8-b5f3-cd535f045d61@e18g2000yqo.googlegroups.com>
sometimes one needs to be direct

javier is stupendously arrogant because he presumes to lecture experts
in common lisp on what he ignorantly believes to be shortcomings of
the language which he barely knows

he then accuses one of these experts of being "arrogant."

this is the very definition of psychological projection

javier is a troll who is either clever at feigning a complete lack of
self awareness in order to get more bites, or, more likely, he is a
troll who is genuinely completely lacking in self awareness.

in either case, he is an arrogant troll
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c6fc91$0$5897$607ed4bc@cv.net>
Raffael Cavallaro wrote:
> sometimes one needs to be direct
> 
> javier is stupendously arrogant because he presumes to lecture experts
> in common lisp on what he ignorantly believes to be shortcomings of
> the language which he barely knows
> 
> he then accuses one of these experts of being "arrogant."
> 
> this is the very definition of psychological projection
> 
> javier is a troll who is either clever at feigning a complete lack of
> self awareness in order to get more bites, or, more likely, he is a
> troll who is genuinely completely lacking in self awareness.
> 
> in either case, he is an arrogant troll

Word up, for the most part, but towards the end he was making a good 
faith attempt to communicate. Still off the mark, but the good faith 
forgives a lot.

I wonder how old /he/ is, not as a sarcastic slam, but in fact.
From: Javier
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <gq89od$vp4$1@aioe.org>
Kenneth Tilton escribi�:

> Word up, for the most part, but towards the end he was making a good
> faith attempt to communicate. Still off the mark, but the good faith
> forgives a lot.

Says the alcoholic teenager in his fifty.


> I wonder how old /he/ is, not as a sarcastic slam, but in fact.

Not as a sarcastic slam? Then why?
From: Javier
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <gq88qn$uuf$1@aioe.org>
Raffael Cavallaro escribi�:
> sometimes one needs to be direct
> 
> javier is stupendously arrogant because he presumes to lecture experts
> in common lisp on what he ignorantly believes to be shortcomings of
> the language which he barely knows
> 
> he then accuses one of these experts of being "arrogant."
> 
> this is the very definition of psychological projection
> 
> javier is a troll who is either clever at feigning a complete lack of
> self awareness in order to get more bites, or, more likely, he is a
> troll who is genuinely completely lacking in self awareness.
> 
> in either case, he is an arrogant troll


First of all, mine wasn't a defense, it was an _attack_.

Second, I don't need to project nothing, specially projecting my
arrogance. Arrogance is something that happens without the need to
project in others. Otherwise it would not be arrogance.
Anyway, mine wasn't arrogance. It was just my opinion with a little of
malevolence added.

And third, this is funny, who is the obsessed one? Every time you answer
to me, without me calling you, is to tell that I'm a troll. Would you
like to kiss my ass or something like that?
From: Raffael Cavallaro
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <58341661-30bf-438b-bb3e-9c6f0a2cdef2@f19g2000yqh.googlegroups.com>
On Mar 23, 11:14 am, Javier <·······@gmail.com> wrote:

> Would you like to kiss my ass or something like that?

spoken like a true troll.
From: ···@crispylogics.com
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <4d52e2e0-2c5f-4ebc-92e2-0f1b5da5761e@r33g2000yqn.googlegroups.com>
On 22 Mrz., 20:14, Javier <·······@gmail.com> wrote:
> André Thieme escribió:
>
>
>
>
>
> > Javier schrieb:
> >> eric-and-jane-smith escribió:
> >>> Javier <·······@gmail.com> wrote ···················@aioe.org:
>
> >>>>>> How old are you Kenny?
> >>>>> An obsession is born.
> >>>> No, I asked because you are like a teenager, but without the "like".
> >>> He's probably done more programming work than any teenager on the
> >>> planet.  
>
> >> And he is probably the oldest teenager in the planet.
>
> >>> Have you ever done any?
>
> >> Yes.
>
> > You can see Kenny Tilton here:
> >http://video.google.com/videoplay?docid=-1331906677993764413
>
> Typical crazy arrogant American, I guess. And he says he is in the path
> of Buddhism? He is in the path of foolishness.
>
> I think he is not doing any good to the CL community. Probably he his
> responsible in a high percentage of people being aware of Lisp.
> The other day I was talking in #Clojure, very respectful people, and
> talked about c.l.l. They agreed that in c.l.l there are very closed mind
>  and hostile people... well ok, but sadly c.l.l is still the heart of
> the Lisp community.

Thats wrong - Lisp is a multiheart community.

JS
From: Jacobite1607
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <a0ca4fea-b988-44a3-a317-590229fdc128@q33g2000pra.googlegroups.com>
On Mar 22, 11:59 am, Kenneth Tilton <·········@gmail.com> wrote:
>
> Harmless, delightful reminders of our roots. I use car and cadr instead
> of first and second as a way of identifying people with whom I never
> want to go drinking.

Is that sort of like drinking and driving, or who gets there second
pays for the one who got there first?
From: Vend
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <d0deb78f-bc4f-47e7-bad9-189da7103435@e18g2000yqo.googlegroups.com>
On 22 Mar, 14:29, Elena <········@gmail.com> wrote:
> Since it's unlikely that Common Lisp gets an updated specification
> fixing issues programmers have met in using it for years, and since
> standards usually have not fixing issues as a goal anyway, I wonder if
> you have been bothered by some issues in Common Lisp and have
> developed a workaround for them.
>
> For instance, I remember one user complaining that Common Lisp doesn't
> adopt a consistent and  convenient naming convention for destructive
> procedures: some have "N" as prefix (e.g. "NCONC"), whilst others
> don't (e.g. "PUSH"). Another user answered and suggested writing a
> package which renamed destructive procedures in a consistent way (e.g.
> "CONC!", "PUSH!", etc).
>
> What are your experiences and your suggestions?

I suppose that many people here think that Common Lisp is the best
possible programming language and consider the idea of fixing it
blasphemous. :D
From: John Thingstad
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <op.uq7nm1xmut4oq5@pandora.alfanett.no>
P� Sun, 22 Mar 2009 20:02:59 +0100, skrev Vend <······@virgilio.it>:

> On 22 Mar, 14:29, Elena <········@gmail.com> wrote:
>> Since it's unlikely that Common Lisp gets an updated specification
>> fixing issues programmers have met in using it for years, and since
>> standards usually have not fixing issues as a goal anyway, I wonder if
>> you have been bothered by some issues in Common Lisp and have
>> developed a workaround for them.
>>
>> For instance, I remember one user complaining that Common Lisp doesn't
>> adopt a consistent and �convenient naming convention for destructive
>> procedures: some have "N" as prefix (e.g. "NCONC"), whilst others
>> don't (e.g. "PUSH"). Another user answered and suggested writing a
>> package which renamed destructive procedures in a consistent way (e.g.
>> "CONC!", "PUSH!", etc).
>>
>> What are your experiences and your suggestions?
>
> I suppose that many people here think that Common Lisp is the best
> possible programming language and consider the idea of fixing it
> blasphemous. :D

Not exactly. Once upon a time Richard Feynman set out to create a better  
notation for calculus. He was happy with it but soon discovered no-one  
else cold read his results. It is sort of the same with Common Lisp. I  
find it better to stick with standard names as it allows others  
(experienced users) to more easily read what I have done. I agree the  
standard is full of inconsistencies and has some omissions, but nothing is  
perfect. They are our warts so to speak.

--------------
John Thingstad
From: Rob Warnock
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <qNydnVqSmrwxQFvUnZ2dnUVZ_hGWnZ2d@speakeasy.net>
John Thingstad <·······@online.no> wrote:
+---------------
| skrev Vend <······@virgilio.it>:
| > I suppose that many people here think that Common Lisp is the best
| > possible programming language and consider the idea of fixing it
| > blasphemous. :D
| 
| Not exactly. Once upon a time Richard Feynman set out to create a better  
| notation for calculus. He was happy with it but soon discovered no-one  
| else cold read his results. It is sort of the same with Common Lisp.
| I find it better to stick with standard names as it allows others  
| (experienced users) to more easily read what I have done.
+---------------

Exactly. I use all *kinds* of shortcuts/abbreviations when I'm just
hacking around in the REPL, but for the most part I am careful to
exclude such idiosyncrasies from production code for the sake of
readability by others -- one notable exception being the use of my
DEFLEX macro for "global lexicals" [which is entirely too convenient
to give up ;-} ].

+---------------
| I agree the standard is full of inconsistencies and has some
| omissions, but nothing is perfect. They are our warts so to speak.
+---------------

Indeed. One can only "fix" them at the risk of fragmenting communications
within the community. E.g., it's only now, after talking about it
fairly frequently for six or seven years, that I'm starting to feel
comfortable posting examples using DEFLEX without some long footnote
explaining it. [Though I confess I do still often add a *short*
footnote with a URL to a sample implementation...  ;-} ]


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Marco Antoniotti
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <abf4a907-f2b2-44cf-b705-b32e80a07f17@h28g2000yqd.googlegroups.com>
On Mar 22, 9:38 pm, "John Thingstad" <·······@online.no> wrote:
> På Sun, 22 Mar 2009 20:02:59 +0100, skrev Vend <······@virgilio.it>:
>
>
>
> > On 22 Mar, 14:29, Elena <········@gmail.com> wrote:
> >> Since it's unlikely that Common Lisp gets an updated specification
> >> fixing issues programmers have met in using it for years, and since
> >> standards usually have not fixing issues as a goal anyway, I wonder if
> >> you have been bothered by some issues in Common Lisp and have
> >> developed a workaround for them.
>
> >> For instance, I remember one user complaining that Common Lisp doesn't
> >> adopt a consistent and  convenient naming convention for destructive
> >> procedures: some have "N" as prefix (e.g. "NCONC"), whilst others
> >> don't (e.g. "PUSH"). Another user answered and suggested writing a
> >> package which renamed destructive procedures in a consistent way (e.g.
> >> "CONC!", "PUSH!", etc).
>
> >> What are your experiences and your suggestions?
>
> > I suppose that many people here think that Common Lisp is the best
> > possible programming language and consider the idea of fixing it
> > blasphemous. :D
>
> Not exactly. Once upon a time Richard Feynman set out to create a better  
> notation for calculus. He was happy with it but soon discovered no-one  
> else cold read his results. It is sort of the same with Common Lisp. I  
> find it better to stick with standard names as it allows others  
> (experienced users) to more easily read what I have done. I agree the  
> standard is full of inconsistencies and has some omissions, but nothing is  
> perfect. They are our warts so to speak.
>

Exactly it took me *months* to figure out that Ruby 'inject' is
nothing else that 'fold' or 'reduce' in disguise. :{

Cheers
--
Marco
From: eric-and-jane-smith
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <Y%uxl.1878$3g7.1547@newsfe15.iad>
Elena <········@gmail.com> wrote in news:8eaa84c8-bad3-4557-a9e4-
············@e35g2000yqc.googlegroups.com:

> you have been bothered by some issues in Common Lisp and have
> developed a workaround for them.

Everyone develops their own version of Common Lisp, and their own 
programming style.  E.g. where someone else might say (compose #'not 
#'null) I say (cf not not) and where someone else might use mvb to mean 
multiple-value-bind, I use mbind, because I also use other binds such as 
dbind and tbind, and they're easier to remember as a group, and to 
recognize at a glance.  Whoever uses mvb will say it's better because 
it's shorter, but I used assembler language for a long time before Lisp, 
and mvb to me means to move a byte.

From my point of view, Common Lisp is a foundation for developing your 
own personal perfect programming language.  Whatever combination of 
language features works best for you.  Or if you're a group of 
programmers working together, whatever combination of features works best 
for the group.  But generally groups of programmers are not needed with 
such a productive programming language.  If you have a meeting of 
programmers discussing what changes to make to a program, one programmer 
could have been making those changes during that meeting, so the time 
spent by everyone who attended the meeting was mostly wasted.  Common 
Lisp is the kind of programming language where it's better to just do the 
work instead of talking about it, because it can get done sooner than it 
can get talked about.

People ask why there seems to be little demand for Common Lisp 
programmers.  But that's like asking why there is little demand for 
elevator riders.  Obviously, if you're supposed to attend a meeting on 
the top floor, you should be an elevator rider, but it wouldn't be a good 
idea to mention that in your resume/cv.  If your boss wants to ride the 
elevator, he can do it himself, with no help from you.  Common Lisp 
programmers don't usually hire other Common Lisp programmers, because 
they can do the work themselves more easily than they can assign it to 
other programmers.

The "issues" you're concerned about, such as inconsistent naming style, 
inconsistent argument order, etc., are very superficial.  Everyone who 
wants to solve those problems will have their own preference of solution.  
Someone with a personality like Monk might take a long time, getting 
everything perfect before proceeding.  But another Monk might disagree 
and spend even more time correcting those corrections.  Other people, 
with more common sense, would proceed doing their real work at full 
speed, and would make whatever minor changes whenever convenient.  No 
matter how big your program gets, it's never hard to edit it to make that 
kind of change, if you use a decent editor and have decent editing 
skills.
From: Pillsy
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <a4246f91-74d2-47e2-b956-727ef7a671b1@q16g2000yqg.googlegroups.com>
On Mar 22, 9:29 am, Elena <········@gmail.com> wrote:

> Since it's unlikely that Common Lisp gets an updated specification
> fixing issues programmers have met in using it for years, and since
> standards usually have not fixing issues as a goal anyway, I wonder if
> you have been bothered by some issues in Common Lisp and have
> developed a workaround for them.

Even if, for some crazy reason, the CL community decided to start a
whole new standardization process tomorrow, I think we'd be basically
stuck with the names we have now. Even the really bad ones, like SLOT-
MAKUNBOUND or T. It just wouldn't be worth the trouble to change them;
either you'd break lots of existing code for no reason, or you'd end
up having two names for lots of functions, which would make things
more confusing rather than less.

Yes, I think T is the single worst name in the language. Taking a one-
letter symbol and making it one of the most commonly used constants in
the language was not such a good choice.

Cheers,
Pillsy
From: Thomas M. Hermann
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <sPidnURwmYPKn1rUnZ2dnUVZ_huWnZ2d@centurytel.net>
Pillsy wrote:
> Yes, I think T is the single worst name in the language. Taking a one-
> letter symbol and making it one of the most commonly used constants in
> the language was not such a good choice.

It's a simple matter of economics. ANSI allotted the committee with a 
fixed number of letters for all of the symbols in the COMMON-LISP 
package. At the time, it was the most number of letters ever awarded a 
language and seemed for all intensive purpose, inexhaustible. So, the 
committee went off and started using letters willy-nilly. Symbols like 
LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, DOUBLE-FLOAT-NEGATIVE-EPSILON, 
ARITHMETIC-ERROR-OPERATION, LOAD-LOGICAL-PATHNAME-TRANSLATIONS and 
PPRINT-EXIT-IF-LIST-EXHAUSTED. (Side fact: Eastern European countries 
protested with the UN at this extravagant use of letters in light of 
their deficit of vowels.) One day, it became clear that the 
inexhaustible set of letters was, in fact, nearing exhaustion. Either 
that, or the people responsible for typing all of the symbols were. 
Anyway, it became clear that shorter symbols were in order. So they 
started defining things like ELT, NTH, ASH, CIS and GCD. It looked like 
they were going to squeak the standard in just under the allotment, when 
one of the committee members noted that there was no symbol for either 
true or false. False was immediately discarded because it had 1 more 
letter than true. But, there were not enough letters left for TRUE, 
either. The committee had no energy left to negotiate the change in 
existing symbol names to obtain the necessary letters. So they wrote in 
the final meetings minutes, "Screw it, we're tired, out of letters and 
want to go home and drink beer. The letter 'T' is the symbol for true. 
Furthermore, it is the set of all objects. The type t is the supertype 
of every type, including itself. Every object is of type t. Stuff it if 
you don't like it."

And that, my friend, is how we arrived at 'T' instead of TRUE.

Cheers,

Tom H.

-- 
=== Thomas M. Hermann ===
From: Alberto Riva
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <gq70kd$f816$1@usenet.osg.ufl.edu>
Thomas M. Hermann wrote:
> Pillsy wrote:
>> Yes, I think T is the single worst name in the language. Taking a one-
>> letter symbol and making it one of the most commonly used constants in
>> the language was not such a good choice.
> 
> It's a simple matter of economics. ANSI allotted the committee with a 
> fixed number of letters for all of the symbols in the COMMON-LISP 
> package. At the time, it was the most number of letters ever awarded a 
> language and seemed for all intensive purpose, inexhaustible. So, the 
> committee went off and started using letters willy-nilly. Symbols like 
> LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT, DOUBLE-FLOAT-NEGATIVE-EPSILON, 
> ARITHMETIC-ERROR-OPERATION, LOAD-LOGICAL-PATHNAME-TRANSLATIONS and 
> PPRINT-EXIT-IF-LIST-EXHAUSTED. (Side fact: Eastern European countries 
> protested with the UN at this extravagant use of letters in light of 
> their deficit of vowels.) One day, it became clear that the 
> inexhaustible set of letters was, in fact, nearing exhaustion. Either 
> that, or the people responsible for typing all of the symbols were. 
> Anyway, it became clear that shorter symbols were in order. So they 
> started defining things like ELT, NTH, ASH, CIS and GCD. It looked like 
> they were going to squeak the standard in just under the allotment, when 
> one of the committee members noted that there was no symbol for either 
> true or false. False was immediately discarded because it had 1 more 
> letter than true. But, there were not enough letters left for TRUE, 
> either. The committee had no energy left to negotiate the change in 
> existing symbol names to obtain the necessary letters. So they wrote in 
> the final meetings minutes, "Screw it, we're tired, out of letters and 
> want to go home and drink beer. The letter 'T' is the symbol for true. 
> Furthermore, it is the set of all objects. The type t is the supertype 
> of every type, including itself. Every object is of type t. Stuff it if 
> you don't like it."
> 
> And that, my friend, is how we arrived at 'T' instead of TRUE.

I think this should be in the FAQ. Seriously.

Alberto
From: Alberto Riva
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <gq6vj6$f812$1@usenet.osg.ufl.edu>
Pillsy wrote:
> 
> Yes, I think T is the single worst name in the language. Taking a one-
> letter symbol and making it one of the most commonly used constants in
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the language was not such a good choice.

I agree that sometimes it's annoying that you can't call a variable T, 
but... do you really use T so often in your programs? The only cases I 
can think of off the top of my head in which I'd normally use T are 
'else' clauses in COND or CASE. Do you write (if (eq (= a b) t) ...) 
very often in your code?

Alberto
From: Nicolas Neuss
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <87r60od3u6.fsf@ma-patru.mathematik.uni-karlsruhe.de>
Alberto Riva <·····@nospam.ufl.edu> writes:

> Pillsy wrote:
>>
>> Yes, I think T is the single worst name in the language. Taking a one-
>> letter symbol and making it one of the most commonly used constants in
>                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> the language was not such a good choice.
>
> I agree that sometimes it's annoying that you can't call a variable T,
> but... do you really use T so often in your programs? The only cases I can
> think of off the top of my head in which I'd normally use T are 'else'
> clauses in COND or CASE. Do you write (if (eq (= a b) t) ...) very often in
> your code?

t occurs rather often in mathematics and physics formulae (mostly denoting
time).  So this can be really disturbing to some people.  OTOH, although I
have been bitten by this, I don't know if I would really prefer "true"
instead.

Nicolas
From: Pascal J. Bourguignon
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <87d4c8h8p7.fsf@galatea.local>
Nicolas Neuss <········@math.uni-karlsruhe.de> writes:

> Alberto Riva <·····@nospam.ufl.edu> writes:
>
>> Pillsy wrote:
>>>
>>> Yes, I think T is the single worst name in the language. Taking a one-
>>> letter symbol and making it one of the most commonly used constants in
>>                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> the language was not such a good choice.
>>
>> I agree that sometimes it's annoying that you can't call a variable T,
>> but... do you really use T so often in your programs? The only cases I can
>> think of off the top of my head in which I'd normally use T are 'else'
>> clauses in COND or CASE. Do you write (if (eq (= a b) t) ...) very often in
>> your code?
>
> t occurs rather often in mathematics and physics formulae (mostly denoting
> time).  So this can be really disturbing to some people.  OTOH, although I
> have been bitten by this, I don't know if I would really prefer "true"
> instead.

But T is used for both True and Top.  What would you propose? Tup? Trop?
And NIL is used for both False and Bottom. Faltom?  Botse?


What I really think is that all these proponents of changes in the
names are but satanic communists saying they want to "simplify" the
chinese ideograms when what they really want is to destroy people and
disconnect them from their history, preventing them to read the
accumulated knowledge of a multi-millenary culture (or 50-yearary
culture in the case of Lisp).


-- 
__Pascal Bourguignon__
From: Casper H.S. Dik
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c75fa7$0$192$e4fe514c@news.xs4all.nl>
···@informatimago.com (Pascal J. Bourguignon) writes:

>What I really think is that all these proponents of changes in the
>names are but satanic communists saying they want to "simplify" the
>chinese ideograms when what they really want is to destroy people and
>disconnect them from their history, preventing them to read the
>accumulated knowledge of a multi-millenary culture (or 50-yearary
>culture in the case of Lisp).

It's not just them; we often change the spelling of Dutch.  That makes
it difficult to read older texts.  Fortunately, the "K-for-C" didn't
make it but it was used by some social "scientists".  Their texts
were difficult to read.


But you can still read Shakespear; not that you would pronunciate it
correctly.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: TomSW
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <ae708b33-d021-4bb9-b68c-ad8fcd329355@w34g2000yqm.googlegroups.com>
On Mar 23, 11:08 am, Casper H.S. Dik <··········@Sun.COM> wrote:
> ····@informatimago.com (Pascal J. Bourguignon) writes:
>
> >What I really think is that all these proponents of changes in the
> >names are but satanic communists saying they want to "simplify" the
> >chinese ideograms when what they really want is to destroy people and
> >disconnect them from their history, preventing them to read the
> >accumulated knowledge of a multi-millenary culture (or 50-yearary
> >culture in the case of Lisp).
>
> It's not just them; we often change the spelling of Dutch.  That makes
> it difficult to read older texts.  Fortunately, the "K-for-C" didn't
> make it but it was used by some social "scientists".  Their texts
> were difficult to read.
>
> But you can still read Shakespear; not that you would pronunciate it
> correctly.

Actually, with Shakespeare it's spelling that's the problem, not
pronunciation. If they had had standard spelling (and maybe
photocopiers) in 1600 hundreds of ambiguities, doubts and academic
feuds would have been spared, and our knowledge of Shakespeare would
be much better.

Tom SW
From: eric-and-jane-smith
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <vGFxl.32165$5t4.24619@newsfe24.iad>
Pillsy <·········@gmail.com> wrote in news:a4246f91-74d2-47e2-b956-
············@q16g2000yqg.googlegroups.com:

> Yes, I think T is the single worst name in the language. Taking a one-
> letter symbol and making it one of the most commonly used constants in
> the language was not such a good choice.

Maybe we should rename it GREEN-T.  That would use less of our precious 
namespace and therefore be economical and ecological, thus green.  It would 
be easy to remember because it's just a variation of the original T.  It 
might even motivate some people to choose healthier beverages than beer.

Hmm.  Nah.  I would hate that even more than T.

In any case, it should be more letters than NIL.  E.g. YES and NO would be 
fine with me.  Because NIL is used a lot more often than T.
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c72e47$0$5917$607ed4bc@cv.net>
eric-and-jane-smith wrote:
> Pillsy <·········@gmail.com> wrote in news:a4246f91-74d2-47e2-b956-
> ············@q16g2000yqg.googlegroups.com:
> 
>> Yes, I think T is the single worst name in the language. Taking a one-
>> letter symbol and making it one of the most commonly used constants in
>> the language was not such a good choice.
> 
> Maybe we should rename it GREEN-T.  That would use less of our precious 
> namespace and therefore be economical and ecological, thus green.  It would 
> be easy to remember because it's just a variation of the original T.  It 
> might even motivate some people to choose healthier beverages than beer.
> 
> Hmm.  Nah.  I would hate that even more than T.
> 
> In any case, it should be more letters than NIL.  E.g. YES and NO would be 
> fine with me.  Because NIL is used a lot more often than T.

Mr-T?

We'll need modern mode to do it right.

hth,k
From: Marco Antoniotti
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <bb7c4a86-cd8f-4204-845a-6498d7b1e4a4@33g2000yqm.googlegroups.com>
On Mar 23, 7:38 am, Kenneth Tilton <·········@gmail.com> wrote:
> eric-and-jane-smith wrote:
> > Pillsy <·········@gmail.com> wrote in news:a4246f91-74d2-47e2-b956-
> > ············@q16g2000yqg.googlegroups.com:
>
> >> Yes, I think T is the single worst name in the language. Taking a one-
> >> letter symbol and making it one of the most commonly used constants in
> >> the language was not such a good choice.
>
> > Maybe we should rename it GREEN-T.  That would use less of our precious
> > namespace and therefore be economical and ecological, thus green.  It would
> > be easy to remember because it's just a variation of the original T.  It
> > might even motivate some people to choose healthier beverages than beer.
>
> > Hmm.  Nah.  I would hate that even more than T.
>
> > In any case, it should be more letters than NIL.  E.g. YES and NO would be
> > fine with me.  Because NIL is used a lot more often than T.
>
> Mr-T?
>
> We'll need modern mode to do it right.
>

(with-flame-bait-ahead ()
  "Except that 'modern mode' is not right.")

Cheers
--
Marco
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c7538b$0$29270$607ed4bc@cv.net>
Marco Antoniotti wrote:
> On Mar 23, 7:38 am, Kenneth Tilton <·········@gmail.com> wrote:
>> eric-and-jane-smith wrote:
>>> Pillsy <·········@gmail.com> wrote in news:a4246f91-74d2-47e2-b956-
>>> ············@q16g2000yqg.googlegroups.com:
>>>> Yes, I think T is the single worst name in the language. Taking a one-
>>>> letter symbol and making it one of the most commonly used constants in
>>>> the language was not such a good choice.
>>> Maybe we should rename it GREEN-T.  That would use less of our precious
>>> namespace and therefore be economical and ecological, thus green.  It would
>>> be easy to remember because it's just a variation of the original T.  It
>>> might even motivate some people to choose healthier beverages than beer.
>>> Hmm.  Nah.  I would hate that even more than T.
>>> In any case, it should be more letters than NIL.  E.g. YES and NO would be
>>> fine with me.  Because NIL is used a lot more often than T.
>> Mr-T?
>>
>> We'll need modern mode to do it right.
>>
> 
> (with-flame-bait-ahead ()
>   "Except that 'modern mode' is not right.")

No problemo! What is the right term? I'll be disappointed if it is just 
"case-sensitive Lisp", mind you. I want some terminology here!

kt
From: Marco Antoniotti
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <a4de691d-f039-44df-99f1-b6200ddb3795@v15g2000yqn.googlegroups.com>
On Mar 23, 10:17 am, Kenneth Tilton <·········@gmail.com> wrote:
> Marco Antoniotti wrote:
> > On Mar 23, 7:38 am, Kenneth Tilton <·········@gmail.com> wrote:
> >> eric-and-jane-smith wrote:
> >>> Pillsy <·········@gmail.com> wrote in news:a4246f91-74d2-47e2-b956-
> >>> ············@q16g2000yqg.googlegroups.com:
> >>>> Yes, I think T is the single worst name in the language. Taking a one-
> >>>> letter symbol and making it one of the most commonly used constants in
> >>>> the language was not such a good choice.
> >>> Maybe we should rename it GREEN-T.  That would use less of our precious
> >>> namespace and therefore be economical and ecological, thus green.  It would
> >>> be easy to remember because it's just a variation of the original T.  It
> >>> might even motivate some people to choose healthier beverages than beer.
> >>> Hmm.  Nah.  I would hate that even more than T.
> >>> In any case, it should be more letters than NIL.  E.g. YES and NO would be
> >>> fine with me.  Because NIL is used a lot more often than T.
> >> Mr-T?
>
> >> We'll need modern mode to do it right.
>
> > (with-flame-bait-ahead ()
> >   "Except that 'modern mode' is not right.")
>
> No problemo! What is the right term? I'll be disappointed if it is just
> "case-sensitive Lisp", mind you. I want some terminology here!

It goes deeper.  Call it what you want, IMHO there is a fix for the
case problem of CL which does not require an incompatible change like
Franz's 'modern mode' :)  Didn't I say this was a flame-bait?

Cheers
--
Marco
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c762f5$0$22528$607ed4bc@cv.net>
Marco Antoniotti wrote:
> On Mar 23, 10:17 am, Kenneth Tilton <·········@gmail.com> wrote:
>> Marco Antoniotti wrote:
>>> On Mar 23, 7:38 am, Kenneth Tilton <·········@gmail.com> wrote:
>>>> eric-and-jane-smith wrote:
>>>>> Pillsy <·········@gmail.com> wrote in news:a4246f91-74d2-47e2-b956-
>>>>> ············@q16g2000yqg.googlegroups.com:
>>>>>> Yes, I think T is the single worst name in the language. Taking a one-
>>>>>> letter symbol and making it one of the most commonly used constants in
>>>>>> the language was not such a good choice.
>>>>> Maybe we should rename it GREEN-T.  That would use less of our precious
>>>>> namespace and therefore be economical and ecological, thus green.  It would
>>>>> be easy to remember because it's just a variation of the original T.  It
>>>>> might even motivate some people to choose healthier beverages than beer.
>>>>> Hmm.  Nah.  I would hate that even more than T.
>>>>> In any case, it should be more letters than NIL.  E.g. YES and NO would be
>>>>> fine with me.  Because NIL is used a lot more often than T.
>>>> Mr-T?
>>>> We'll need modern mode to do it right.
>>> (with-flame-bait-ahead ()
>>>   "Except that 'modern mode' is not right.")
>> No problemo! What is the right term? I'll be disappointed if it is just
>> "case-sensitive Lisp", mind you. I want some terminology here!
> 
> It goes deeper.  Call it what you want, IMHO there is a fix for the
> case problem of CL which does not require an incompatible change like
> Franz's 'modern mode' :)  Didn't I say this was a flame-bait?

Can we ream them over if* again while we are at it?

kxo
From: Marco Antoniotti
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <a75d7613-d46c-469b-9cb8-684cd5523f04@h5g2000yqh.googlegroups.com>
On Mar 23, 11:22 am, Kenneth Tilton <·········@gmail.com> wrote:
> Marco Antoniotti wrote:
> > On Mar 23, 10:17 am, Kenneth Tilton <·········@gmail.com> wrote:
> >> Marco Antoniotti wrote:
> >>> On Mar 23, 7:38 am, Kenneth Tilton <·········@gmail.com> wrote:
> >>>> eric-and-jane-smith wrote:
> >>>>> Pillsy <·········@gmail.com> wrote in news:a4246f91-74d2-47e2-b956-
> >>>>> ············@q16g2000yqg.googlegroups.com:
> >>>>>> Yes, I think T is the single worst name in the language. Taking a one-
> >>>>>> letter symbol and making it one of the most commonly used constants in
> >>>>>> the language was not such a good choice.
> >>>>> Maybe we should rename it GREEN-T.  That would use less of our precious
> >>>>> namespace and therefore be economical and ecological, thus green.  It would
> >>>>> be easy to remember because it's just a variation of the original T.  It
> >>>>> might even motivate some people to choose healthier beverages than beer.
> >>>>> Hmm.  Nah.  I would hate that even more than T.
> >>>>> In any case, it should be more letters than NIL.  E.g. YES and NO would be
> >>>>> fine with me.  Because NIL is used a lot more often than T.
> >>>> Mr-T?
> >>>> We'll need modern mode to do it right.
> >>> (with-flame-bait-ahead ()
> >>>   "Except that 'modern mode' is not right.")
> >> No problemo! What is the right term? I'll be disappointed if it is just
> >> "case-sensitive Lisp", mind you. I want some terminology here!
>
> > It goes deeper.  Call it what you want, IMHO there is a fix for the
> > case problem of CL which does not require an incompatible change like
> > Franz's 'modern mode' :)  Didn't I say this was a flame-bait?
>
> Can we ream them over if* again while we are at it?
>

Don't give you-know-who ideas :)

Cheers
--
Marco
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <befd7e9d-499e-47d1-ac67-849be8ff6101@c11g2000yqj.googlegroups.com>
On 23 Mar, 12:09, Marco Antoniotti <·······@gmail.com> wrote:
> On Mar 23, 11:22 am, Kenneth Tilton <·········@gmail.com> wrote:
> > Can we ream them over if* again while we are at it?
>
> Don't give you-know-who ideas :)

You talkin' to me?... You talkin' to me?... You talkin' to me?

http://www.youtube.com/watch?v=Hw9_bMZmtQU

What should I know about "if*"? ^_^
From: Marco Antoniotti
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <2a8c7b7a-7aed-429e-97e0-9caa4f8340ea@e18g2000yqo.googlegroups.com>
On Mar 23, 8:52 pm, Elena <········@gmail.com> wrote:
> On 23 Mar, 12:09, Marco Antoniotti <·······@gmail.com> wrote:
>
> > On Mar 23, 11:22 am, Kenneth Tilton <·········@gmail.com> wrote:
> > > Can we ream them over if* again while we are at it?
>
> > Don't give you-know-who ideas :)
>
> You talkin' to me?... You talkin' to me?... You talkin' to me?

Nope.  I hope you don't have a mohawk either.

>
> http://www.youtube.com/watch?v=Hw9_bMZmtQU
>
> What should I know about "if*"? ^_^

That it is the equivalent of LOOP.  Enough said.

Cheers
--
Marco
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <2eb3535a-53bd-4233-808b-8a41c57426b4@z1g2000yqn.googlegroups.com>
On 23 Mar, 21:11, Marco Antoniotti <·······@gmail.com> wrote:
> On Mar 23, 8:52 pm, Elena <········@gmail.com> wrote:
> > What should I know about "if*"? ^_^
>
> That it is the equivalent of LOOP.  Enough said.

Heck!

Still adamant that Common Lisp hasn't any issue?
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c7fbf3$0$5937$607ed4bc@cv.net>
Elena wrote:
> On 23 Mar, 21:11, Marco Antoniotti <·······@gmail.com> wrote:
>> On Mar 23, 8:52 pm, Elena <········@gmail.com> wrote:
>>> What should I know about "if*"? ^_^
>> That it is the equivalent of LOOP.  Enough said.
> 
> Heck!
> 
> Still adamant that Common Lisp hasn't any issue?

<sigh>

Well, could be a good sign, Lisp gets its first dizzy blonde. Point of 
information: I thought you had settled on Scheme? Shouldn't you be over 
in c.l.scheme fixing that?

As for if* vs. loop: iteration is big enough to justify a DSL, a fork in 
the road is not.

Where /is/ Erik when we need him?!
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <ca7b6c97-5799-4d89-8cf9-39ca8465bca2@g19g2000yql.googlegroups.com>
On 23 Mar, 22:15, Kenneth Tilton <·········@gmail.com> wrote:
> Well, could be a good sign, Lisp gets its first dizzy blonde.

Are you talkin' about me? You know, dude, I'm not your average blonde.
I have red hair, "Navy Seals" cut. A cut to kill, you know! Aren't you
talkin' about me? Who's the other chick here? I'm Italian and
therefore quite jealous, you know? Beware!

;-)))))

> As for if* vs. loop: iteration is big enough to justify a DSL, a fork in
> the road is not.

I don't understand what you are saying. Does anyone care to explain?
Thanks.

> Where /is/ Erik when we need him?!

Erik Naggum, right? Oh, Erik, I miss him too. Very sharp guy, indeed.
Luckily there are backups of old threads starring him. Do you remember
the unemployed programmer-and-Perl dilemma? Let me refresh your
memories:

http://www.schnada.de/grapt/eriknaggum-perlrant.html

;-)

Jokes apart, some time ago I've read on his site that he was
experiencing some illness. I hope he's better now. Maybe I should drop
him a line, even if he has never heard about me...
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c834cc$0$24466$607ed4bc@cv.net>
Elena wrote:
> On 23 Mar, 22:15, Kenneth Tilton <·········@gmail.com> wrote:
>> Well, could be a good sign, Lisp gets its first dizzy blonde.
> 
> Are you talkin' about me? You know, dude, I'm not your average blonde.
> I have red hair, "Navy Seals" cut. A cut to kill, you know! Aren't you
> talkin' about me? Who's the other chick here? I'm Italian and
> therefore quite jealous, you know? Beware!

Nose rings? Tattoos? Could be the dizzy blonde of the 21st century. 
Let's try a test:

    Let's go shopping!

Did your heart skip a beat?

> 
> ;-)))))
> 
>> As for if* vs. loop: iteration is big enough to justify a DSL, a fork in
>> the road is not.
> 
> I don't understand what you are saying. Does anyone care to explain?

Hang on. Have you ever actually programmed a computer?

> Thanks.
> 
>> Where /is/ Erik when we need him?!
> 
> Erik Naggum, right? Oh, Erik, I miss him too. Very sharp guy, indeed.
> Luckily there are backups of old threads starring him. Do you remember
> the unemployed programmer-and-Perl dilemma? Let me refresh your
> memories:
> 
> http://www.schnada.de/grapt/eriknaggum-perlrant.html
> 
> ;-)
> 
> Jokes apart, some time ago I've read on his site that he was
> experiencing some illness. I hope he's better now. Maybe I should drop
> him a line, even if he has never heard about me...

It could be the end of him.
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <1fe12801-6ed8-43e7-abe5-21a015f0a561@y9g2000yqg.googlegroups.com>
On 24 Mar, 02:18, Kenneth Tilton <·········@gmail.com> wrote:
> Let's try a test:
>
>     Let's go shopping!
>
> Did your heart skip a beat?

Nope. I've failed the test, haven't I? Are you going to "retire" me?

http://en.wikipedia.org/wiki/Voight-Kampff_machine

> >> As for if* vs. loop: iteration is big enough to justify a DSL, a fork in
> >> the road is not.
>
> > I don't understand what you are saying. Does anyone care to explain?
>
> Hang on. Have you ever actually programmed a computer?

As far as I can remember... yes: I programmed my microwave oven.
Enough said?

Come on, Kenneth, I'm not a native English speaker. I wondered if
there was a piece of information I was missing. Is it a joke? Then
don't bother to explain. Thanks.

> > Jokes apart, some time ago I've read on his site that he was
> > experiencing some illness. I hope he's better now. Maybe I should drop
> > him a line, even if he has never heard about me...
>
> It could be the end of him.

Well, at least I understand this to be a joke.

Seriously, I hope Erik is better now.

Cheers
From: Rob Warnock
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <sqKdndOg--TEMlXUnZ2dnUVZ_uCdnZ2d@speakeasy.net>
Elena  <········@gmail.com> wrote:
+---------------
| Kenneth Tilton <·········@gmail.com> wrote:
| > As for if* vs. loop: iteration is big enough to justify a DSL, a fork in
| > the road is not.
| 
| I don't understand what you are saying. Does anyone care to explain?
+---------------

"DSL" == "Domain-Specific Language", so Kenny is just saying that CL's
LOOP provides a sufficiently rich set of semantics to choose from that
a specialized sub-language for LOOP is not unreasonable. [Another example
might be the DSL encoded into the format strings of the FORMAT function.
*Definitely* "non-Lispy", but so incredibly useful that a DSL is justified.]

And Kenny is also saying that the simple two-way branch provided by CL's
built-in IF -- a simple two-way "fork in the road" -- *doesn't meet the
test of "a sufficiently rich set of semantics" to justify the DSL that
Franz's (or John Foderaro's, whichever) IF* macro provides. [IF* basically
allows the use of THEN & ELSE keywords instead of using CL's PROGN to
group multiple expressions in an IF branch.]

+---------------
| > Where /is/ Erik when we need him?!
| 
| Erik Naggum, right? Oh, Erik, I miss him too. Very sharp guy, indeed.
| Luckily there are backups of old threads starring him. Do you remember
| the unemployed programmer-and-Perl dilemma? Let me refresh your
| memories:
| 
| http://www.schnada.de/grapt/eriknaggum-perlrant.html
+---------------

Yes, indeedy! Line noise! I can't read Perl that *I* wrote a week later! ;-}

Actually, my big "Aha!" moment for Perl was when I read Sriram
Srinivasan's "Advanced Perl Programming", and found out that Perl's
"typeglobs" are really a lot like CL symbols, except with more slots,
and using readmacros as accessors:

 Perl form	CL (near-)equivalent form
 =========	=========================
    *foo	'foo			; the typeglob for "foo"
    $foo	(symbol-value 'foo)	; scalar value
    &foo	(symbol-function 'foo)	; function value
    %foo	(symbol-plist 'foo) 	; associative array (:test #'eq)
    @foo	(symbol-array 'foo)	; array value [no direct CL equiv.]
    FOO		(symbol-stream 'foo)	; filehandle [no direct CL equiv.]

[O.k., (SYMBOL-PLIST 'FOO) is really only a rough analogy to %foo;
SYMBOL-HASH might be a better name. But the former can do the job,
perhaps just not as efficiently. (Also, GET uses EQ as the test, and
Perl's "%" uses something closer to EQUAL.) And let's not even mention
"aliasing" from assigning typeglobs!! (E.g., do "local *b; *b = *a;",
and now $b ==> a's scalar value and &b  ==> a's function value!)]

Once I figured all that out, reading Perl code got a *lot* easier...  ;-}

+---------------
| Jokes apart, some time ago I've read on his site that he was
| experiencing some illness. I hope he's better now.
+---------------

His web site [last updated a year and a half ago] suggests
probably not, unfortunately:

    http://naggum.no/
    ... @2006-257
    ...
    I am unable to keep my company in operation for health reasons...
    Until my health improves, which it might never do sufficiently,
    I am generally unable to accept programming projects, teaching
    opportunities, or requests to advise students, although I would
    really like to see what I can do if you would like my input.
    ...


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <b48a5412-a9b6-47d2-a934-f2be93428b3f@s20g2000yqh.googlegroups.com>
On 23 Mar, 22:15, Kenneth Tilton <·········@gmail.com> wrote:
> Point of
> information: I thought you had settled on Scheme? Shouldn't you be over
> in c.l.scheme fixing that?

I don't mind: both Scheme and Common Lisp can draw circles around any
Blub out there. I do prefer Scheme because of its shared namespace for
variables, required TCO and consistent naming (don't care about
"modern"). I don't know about macros, it seems that CL has got a
simpler system, more integrated into the language.

I have more hope for CL, because CLers have already a culture of
working together, albeit with some glitches, and they have a
comprehensive standard and many (almost) portable libraries to start
with.

The moon is right there, we just have to raise our hands to touch it
^_^
From: ····················@hotmail.com
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <8809441c-1f35-4496-bf38-fdeda42b898a@37g2000yqp.googlegroups.com>
On 23 Mar, 23:01, Elena <········@gmail.com> wrote:

<snip>

> I don't mind: both Scheme and Common Lisp can draw circles around any
> Blub out there. I do prefer Scheme because of its shared namespace for
> variables, required TCO and consistent naming (don't care about
> "modern"). I don't know about macros, it seems that CL has got a
> simpler system, more integrated into the language.

I started to understand macros when i read this

    http://www.lisperati.com/casting.html

"oh, it just returns a list! Why didn't someone tell me before?"

I almost understood scheme macros when I read this

    http://docs.plt-scheme.org/guide/macros.html

<snip>
From: Wade
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <782558bb-fab5-4b0b-88a0-02f01ed4e38b@b6g2000pre.googlegroups.com>
Erik knew what kind of psychological hoops some people
go through and then blame everyone else
for their issues. This thread seems pretty typical of this
behavior.

Trying to learn Common Lisp, but putting no effort and
energy into it. But with huge egos they
think its Common Lisp's and its user's fault.

If they had a little humility and were _committed_
to learning they would come to see the Lisp
behind Common Lisp.  Learning takes large
amounts of energy and is difficult.  But you
have to work hard sometimes.

I find it extremely funny that the
people complaining about the Common Lisp
Standard are the biggest proponents of another
standard.  Of course it would be their standard,
not some old farts who obviously did not know
what they were doing.

I am a proponent of no standard. When I read
comments that the Common Lisp Standard killed
Lisp what I hear is that the Authoritative approach
is not compatible with Lisp (even when the
Controlling Authority is the "Community").
Its like the grammar police who cannot stand
english evolving and changing.

Wade
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <defb61fe-f54b-4610-b38c-d86f89b03726@p11g2000yqe.googlegroups.com>
On 24 Mar, 00:30, Wade <·············@gmail.com> wrote:
> Erik knew what kind of psychological hoops some people
> go through and then blame everyone else
> for their issues. This thread seems pretty typical of this
> behavior.
>
> Trying to learn Common Lisp, but putting no effort and
> energy into it. But with huge egos they
> think its Common Lisp's and its user's fault.
>
> If they had a little humility and were _committed_
> to learning they would come to see the Lisp
> behind Common Lisp.  Learning takes large
> amounts of energy and is difficult.  But you
> have to work hard sometimes.
>
> I find it extremely funny that the
> people complaining about the Common Lisp
> Standard are the biggest proponents of another
> standard.  Of course it would be their standard,
> not some old farts who obviously did not know
> what they were doing.
>
> I am a proponent of no standard. When I read
> comments that the Common Lisp Standard killed
> Lisp what I hear is that the Authoritative approach
> is not compatible with Lisp (even when the
> Controlling Authority is the "Community").
> Its like the grammar police who cannot stand
> english evolving and changing.
>
> Wade

You completely missed the point. Nobody here has proposed a new
standard.

All people here have a lot of respect for CL. Some have no deference,
that's all.
From: Marco Antoniotti
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <312d8e82-4fc8-477f-ae50-912f52ccce80@e18g2000yqo.googlegroups.com>
On Mar 23, 10:06 pm, Elena <········@gmail.com> wrote:
> On 23 Mar, 21:11, Marco Antoniotti <·······@gmail.com> wrote:
>
> > On Mar 23, 8:52 pm, Elena <········@gmail.com> wrote:
> > > What should I know about "if*"? ^_^
>
> > That it is the equivalent of LOOP.  Enough said.
>
> Heck!
>
> Still adamant that Common Lisp hasn't any issue?

Never said it hasn't.  I repeat.  Have you tried to look at
pathnames? :)

Cheers
--
Marco
From: Raffael Cavallaro
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <fd6b8795-94d4-441d-8750-61e817d86153@h5g2000yqh.googlegroups.com>
On Mar 23, 2:38 am, Kenneth Tilton <·········@gmail.com> wrote:

>
> Mr-T?
>

I pity the fool renames the symbol for the boolean representing true,
the canonical generalized boolean representing true, the name of the
type to which all objects belong, the supertype of all types
(including itself), and the name of the superclass of all classes
except itself!
From: Marcus Breiing
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <fl99vykbmxa1k@breiing.com>
* Raffael Cavallaro

> I pity the fool renames the symbol for the boolean representing true,
> the canonical generalized boolean representing true, the name of the
> type to which all objects belong, the supertype of all types
> (including itself), and the name of the superclass of all classes
> except itself!

The flaw is not in the name, but in the fact that a name like this is
globally and irreversibly declared constant. CL wouldn't be worse off
if people had to write 'T instead of T in a few places.
From: Raffael Cavallaro
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <0cbc18a3-25ad-4789-b06f-e0d2ca344e24@p11g2000yqe.googlegroups.com>
On Mar 23, 11:15 am, Marcus Breiing <······@2009w12.mail.breiing.com>
wrote:

>
> The flaw is not in the name, but in the fact that a name like this is
> globally and irreversibly declared constant. CL wouldn't be worse off
> if people had to write 'T instead of T in a few places.

clearly not a fan of the A Team
From: Marcus Breiing
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <ga3axna2lu0qp@breiing.com>
* Raffael Cavallaro

> clearly not a fan of the A Team

Heh. But even if I was... in my corner of the world, the show was
lip-synched.
From: Tobias C. Rittweiler
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <871vsorw33.fsf@freebits.de>
Pillsy <·········@gmail.com> writes:

> Yes, I think T is the single worst name in the language. Taking a one-
> letter symbol and making it one of the most commonly used constants in
> the language was not such a good choice.

There's an alternative to renaming it. Make it a global symbol-macro.

  -T.
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c7cb40$0$5900$607ed4bc@cv.net>
> Pillsy <·········@gmail.com> writes:
> 
>> Yes, I think T is the single worst name in the language. Taking a one-
>> letter symbol and making it one of the most commonly used constants in
>> the language was not such a good choice.
> 

Just had a thought. I wonder if I code t once a year. t is like g*d, the 
name that should never be spoken.

Anyone got the grep for a standalone t?

Why don't we just take the damn symbol back?! We cannot speak of the 
Tao, we cannot type Lisp truth.

I scare myself sometimes.
From: Rob Warnock
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <esWdnT00TrwB1lXUnZ2dnUVZ_jiWnZ2d@speakeasy.net>
Kenneth Tilton  <·········@gmail.com> wrote:
+---------------
| Anyone got the grep for a standalone t?
+---------------

"grep -i '\<t\>'" should do it. Note, though, that when I
ran that over the CMUCL code base, I found *6288* lines!

+---------------
| Why don't we just take the damn symbol back?!
+---------------

Why not, indeed?  ;-}  ;-}

    > (shadow 't)

    COMMON-LISP:T
    > (deflex t 32.456)

    T
    > t

    32.456
    > (defun t () t)

    T
    > (let ((t 'inner-truth))
	(list t (t) cl:t))
    
    (INNER-TRUTH 32.456 COMMON-LISP:T)
    > 


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Thomas F. Burdick
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <eabbd13d-7fc2-4705-93f6-b3614c0d9424@z23g2000prd.googlegroups.com>
On Mar 22, 2:29 pm, Elena <········@gmail.com> wrote:

> For instance, I remember one user complaining that Common Lisp doesn't
> adopt a consistent and  convenient naming convention for destructive
> procedures: some have "N" as prefix (e.g. "NCONC"), whilst others
> don't (e.g. "PUSH"). Another user answered and suggested writing a
> package which renamed destructive procedures in a consistent way (e.g.
> "CONC!", "PUSH!", etc).

PUSH isn't destructive, it side-effects a place, which is different.
If you wanted consistent naming, it would be:

  (defun push (item list)
    (cons item list))

  (defun npush (item list)
    (if (null list)
        (list item)
        (let ((new (cons (car list) (cdr list))))
          (rplaca list item)
          (rplacd list new)
          list)))

  ;; Cue comments about multiple evaluations, out-of-order evaluation,
etc ...

  (defmacro pushf (item place)
    `(setf ,place (push ,item ,place)))

  (defmacro npushf (item place)
    `(setf ,place (npush ,item ,place)))

> What are your experiences and your suggestions?

I think you're looking at the very trivial stuff that's unimportant.
Getting a standard for extensible streams that's less clunky than Gray
streams would be 1000x more useful.
From: Tobias C. Rittweiler
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <87ab7crwkc.fsf@freebits.de>
"Thomas F. Burdick" <········@gmail.com> writes:

>   ;; Cue comments about multiple evaluations, out-of-order evaluation,
> etc ...
>
>   (defmacro pushf (item place)
>     `(setf ,place (push ,item ,place)))
>
>   (defmacro npushf (item place)
>     `(setf ,place (npush ,item ,place)))

I'm quite fond of CALLF which I essentially ripped from cl.el. See

  http://common-lisp.net/pipermail/alexandria-devel/2007-September/000259.html

It allows you to write your example as

  (defmacro pushf (item place)
    ;; the 2 says that the 2nd argument is the place.
    `(callf-n 2 #'push ,item ,place))

and deals with all the problems you mention above. :-)

  -T.
From: Thomas F. Burdick
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <24a02909-b833-400b-85db-6985f792c821@v38g2000yqb.googlegroups.com>
On 23 mar, 18:14, "Tobias C. Rittweiler" <····@freebits.de.invalid>
wrote:
> "Thomas F. Burdick" <········@gmail.com> writes:
>
> >   ;; Cue comments about multiple evaluations, out-of-order evaluation,
> > etc ...
>
> >   (defmacro pushf (item place)
> >     `(setf ,place (push ,item ,place)))
>
> >   (defmacro npushf (item place)
> >     `(setf ,place (npush ,item ,place)))
>
> I'm quite fond of CALLF which I essentially ripped from cl.el. See
>
>  http://common-lisp.net/pipermail/alexandria-devel/2007-September/0002...
>
> It allows you to write your example as
>
>   (defmacro pushf (item place)
>     ;; the 2 says that the 2nd argument is the place.
>     `(callf-n 2 #'push ,item ,place))
>
> and deals with all the problems you mention above. :-)

Wow, cool! Now *that* is a utility that belongs in the standard :-)
From: gugamilare
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <ebd0a6a9-c1e4-43a7-bea1-8afee71199e4@v38g2000yqb.googlegroups.com>
On 24 mar, 09:44, "Thomas F. Burdick" <········@gmail.com> wrote:
> On 23 mar, 18:14, "Tobias C. Rittweiler" <····@freebits.de.invalid>
> wrote:
>
>
>
> > "Thomas F. Burdick" <········@gmail.com> writes:
>
> > >   ;; Cue comments about multiple evaluations, out-of-order evaluation,
> > > etc ...
>
> > >   (defmacro pushf (item place)
> > >     `(setf ,place (push ,item ,place)))
>
> > >   (defmacro npushf (item place)
> > >     `(setf ,place (npush ,item ,place)))
>
> > I'm quite fond of CALLF which I essentially ripped from cl.el. See
>
> >  http://common-lisp.net/pipermail/alexandria-devel/2007-September/0002...
>
> > It allows you to write your example as
>
> >   (defmacro pushf (item place)
> >     ;; the 2 says that the 2nd argument is the place.
> >     `(callf-n 2 #'push ,item ,place))
>
> > and deals with all the problems you mention above. :-)
>
> Wow, cool! Now *that* is a utility that belongs in the standard :-)

What? You are using push as if it were cons? That is not good.
From: Thomas F. Burdick
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <63dff17e-f98e-42d8-a44f-bed6f690db73@p6g2000pre.googlegroups.com>
On Mar 24, 2:58 pm, gugamilare <··········@gmail.com> wrote:
> On 24 mar, 09:44, "Thomas F. Burdick" <········@gmail.com> wrote:
>
>
>
>
>
> > On 23 mar, 18:14, "Tobias C. Rittweiler" <····@freebits.de.invalid>
> > wrote:
>
> > > "Thomas F. Burdick" <········@gmail.com> writes:
>
> > > >   ;; Cue comments about multiple evaluations, out-of-order evaluation,
> > > > etc ...
>
> > > >   (defmacro pushf (item place)
> > > >     `(setf ,place (push ,item ,place)))
>
> > > >   (defmacro npushf (item place)
> > > >     `(setf ,place (npush ,item ,place)))
>
> > > I'm quite fond of CALLF which I essentially ripped from cl.el. See
>
> > >  http://common-lisp.net/pipermail/alexandria-devel/2007-September/0002...
>
> > > It allows you to write your example as
>
> > >   (defmacro pushf (item place)
> > >     ;; the 2 says that the 2nd argument is the place.
> > >     `(callf-n 2 #'push ,item ,place))
>
> > > and deals with all the problems you mention above. :-)
>
> > Wow, cool! Now *that* is a utility that belongs in the standard :-)
>
> What? You are using push as if it were cons? That is not good.

Only in the alternate universe where we change CL to use consistent n-
and -f naming conventions. You need to read more of the thread context.
From: Thomas A. Russ
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <ymiwsagchgx.fsf@blackcat.isi.edu>
Elena <········@gmail.com> writes:
> For instance, I remember one user complaining that Common Lisp doesn't
> adopt a consistent and  convenient naming convention for destructive
> procedures: some have "N" as prefix (e.g. "NCONC"), whilst others
> don't (e.g. "PUSH").

Point of clarification:

PUSH is NOT necessarily a destructive operation.  Destructive procedures
mutate data structures, and that is not a given with PUSH, anymore than
it is with SETF.  Whether it is destructive or not depends on the place
form that is passed to it.

Now, you could make a case for REVERSE/NREVERSE vs. say REMOVE/DELETE.

But in most languages that are not designed de-novo, you will tend to
have such inconsistencies.  It is the sign of any language that is old
enough to have evolved, and whose implementers prize maintaining
backward compatibility.

Most users just accept this and don't bother developing work-arounds.
You just learn the language as it is.

It is similar to the way that most (European) natural languages have
irregular verbs in them.  Clearly a sub-optimal language design, but the
existing users are used to them, and there's a large existing collection
of work that uses them, so....

-- 
Thomas A. Russ,  USC/Information Sciences Institute
From: Matthias Buelow
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <72perqFr43anU1@mid.dfncis.de>
Elena wrote:

> don't (e.g. "PUSH"). Another user answered and suggested writing a
> package which renamed destructive procedures in a consistent way (e.g.
> "CONC!", "PUSH!", etc).

Not the exclamation marks, please... and no question marks, either. That
should be reserved for user symbols, to stand out.
From: Kaz Kylheku
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <20090401062447.668@gmail.com>
On 2009-03-22, Elena <········@gmail.com> wrote:
> Since it's unlikely that Common Lisp gets an updated specification
> fixing issues programmers have met in using it for years, and since
> standards usually have not fixing issues as a goal anyway, I wonder if
> you have been bothered by some issues in Common Lisp and have
> developed a workaround for them.
>
> For instance, I remember one user complaining that Common Lisp doesn't
> adopt a consistent and  convenient naming convention for destructive
> procedures: some have "N" as prefix (e.g. "NCONC"), whilst others
> don't (e.g. "PUSH"). Another user answered and suggested writing a
> package which renamed destructive procedures in a consistent way (e.g.
> "CONC!", "PUSH!", etc).
>
> What are your experiences and your suggestions?

Yes; these issues are in fact ``issues''. 

I.e. psychological problems to be taken up with your therapist.

The reasonable software engineer doesn't care about NCONC versus PUSH.

See, in the real world we work on projects in which the number of
symbols defined in the language is dwarfed by project-defined symbols.

The important thing about language-defined symbols is that they are
standardized. That's the beginning and the end. 

How those symbols are spelled is the stuff of arguments for after 5 p.m. on a
Friday when you head to the programmer bar to have a few drinks.

Naming conventions are indeed very important for project-defined symbols,
because the number of symbols is large, there is significant churn in the
codebase, the number of people who are familiar with the symbols is small, and
the documentation is far from complete and correct.

Language-defined symbols are different from project-defined symbols. See even
if Lisp didn't have a global macro called PUSH, you probably wouldn't use that
name in a serious, big project. It's too short, for one thing.  This macro can
only have a four-letter name precisely because it's part of a language.  In
your own package, you might have a MYPACKAGE::PUSH. But perhaps only as a
private symbol; you'd worry that if it was exported, the likelihood of it
clashing with something would be high.

I don't care if it starts with N or not, but I would probably hate it if PUSH
was called CONS-WITH-AND-UPDATE. But even if it had been called that, it would
still have the virtue that it's been in the standard language for twenty years,
and everyone knows what it means.

Anyway, you obviously have not even thought about this very well, because not
all of the destructive operations are the same.

Consider that NCONC destructively manipulates an /object/, whereas PUSH
manipulates a /place/. The N means that it's non-consing. Why should they both
share some ! convention?

NCONC behaves the same as APPEND, except that it's destructive. But PUSH is
/necessarily/ destructive; there can be no non-destructive flavor of PUSH.

Using the character ! in standard symbols is a terrible idea.  Doing so would
effectively  make the ! character reserved and unavailable for use in custom
read macros (except as a dispatch character where the context makes it clear
that it's not a symbol constituent).

In the Lisp language there is already a convention for introducing a variant on
some function or operator, which is like another one but somewhat different.
This convention is to append the * character to the name, exemplified by DO and
DO*, or LET and LET*, LIST and LIST*.

In a Lisp designed from scratch, I would gravitate toward this convention in
naming pairs of functions which are related such that one is destructive and
the other isn't:  APPEND and APPEND*, et cetera. The name CONC! instead of
NCONC doesn't fix the fact that CONC and APPEND are unrelated words, yet they
are used for naming almost exactly the same function.

About PUSH, I would say that it's inconsistent with some of the other operators
that manipulate places. Don't compare the name PUSH to NCONC but to SETF,
ROTATEF, and INCF.  The F probably means ``form'' because these operators take
a form which designates a place, and mutate its value. So PUSH and POP might be
called PUSHF and POPF.

In a language designed from scratch, I'd probably avoid these cryptic suffices.
Obviously SETF has the suffix because SET is already taken, and there is the
SETQ precedent. The other cousins of SETF which use setf expansion have the F
because they imitate SETF. In a brand new Lisp, I'd just call them SET, INC,
ROTATE, PUSH and POP.

Anyway, Doc, I see that our hour is up; I feel better.
From: Raffael Cavallaro
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <1aa57404-8059-4cd7-b2ed-7d4ead534cb4@p11g2000yqe.googlegroups.com>
On Mar 23, 6:53 pm, Kaz Kylheku <········@gmail.com> wrote:

> Yes; these issues are in fact ``issues''.
>
> I.e. psychological problems to be taken up with your therapist.

[much wisdom snipped]

exactly.
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <91483c5a-4e42-4be5-afc2-12e720c8019e@j39g2000yqn.googlegroups.com>
On 24 Mar, 01:10, Raffael Cavallaro <················@gmail.com>
wrote:
> On Mar 23, 6:53 pm, Kaz Kylheku <········@gmail.com> wrote:
>
> > Yes; these issues are in fact ``issues''.
>
> > I.e. psychological problems to be taken up with your therapist.
>
> [much wisdom snipped]
>
> exactly.

What have you just snipped? Your brain carrying much wisdom? What a
pity! That would explain why you have been left with just one word to
say. Oh, and a dot too.

:-)))))

Cheers
From: Raffael Cavallaro
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <f38e86f2-8e5f-4a15-9928-5dbd3583eb5b@e18g2000yqo.googlegroups.com>
On Mar 23, 11:00 pm, Elena <········@gmail.com> wrote:

[awkward attempt at humor snippd]

> That would explain why you have been left with just one word to
> say. Oh, and a dot too.
>
> :-)))))
>
> Cheers

for you, I'll splurge.
(wait for it)

.
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49c867e3$0$20302$607ed4bc@cv.net>
Elena wrote:
> On 24 Mar, 01:10, Raffael Cavallaro <················@gmail.com>
> wrote:
>> On Mar 23, 6:53 pm, Kaz Kylheku <········@gmail.com> wrote:
>>
>>> Yes; these issues are in fact ``issues''.
>>> I.e. psychological problems to be taken up with your therapist.
>> [much wisdom snipped]
>>
>> exactly.
> 
> What have you just snipped? Your brain carrying much wisdom? What a
> pity! That would explain why you have been left with just one word to
> say. Oh, and a dot too.
> 
> :-)))))
> 
> Cheers

And we thought Javier was a troll. This one starts out with some 
nonsense about having to persuade management to adopt Lisp then forgets 
they did that and launches into that other favorite troll about things 
needing fixing. Now if only he had remembered to touch base from time to 
  time with the management pitch crap.

Game Over.
From: Javier
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <gqauhd$9do$1@aioe.org>
Kenneth Tilton escribi�:
> Elena wrote:
>> On 24 Mar, 01:10, Raffael Cavallaro <················@gmail.com>
>> wrote:
>>> On Mar 23, 6:53 pm, Kaz Kylheku <········@gmail.com> wrote:
>>>
>>>> Yes; these issues are in fact ``issues''.
>>>> I.e. psychological problems to be taken up with your therapist.
>>> [much wisdom snipped]
>>>
>>> exactly.
>>
>> What have you just snipped? Your brain carrying much wisdom? What a
>> pity! That would explain why you have been left with just one word to
>> say. Oh, and a dot too.
>>
>> :-)))))
>>
>> Cheers
> 
> And we thought Javier was a troll. This one starts out with some
> nonsense about having to persuade management to adopt Lisp then forgets
> they did that and launches into that other favorite troll about things
> needing fixing. Now if only he had remembered to touch base from time to
>  time with the management pitch crap.
> 
> Game Over.

Kenny went to his psychotherapeutic: "I have a problem, I only happen to
see trolls all around". And he responds: "Kenny, I said you not  to eat
those mushrooms, again with the same?"
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <79a8ab35-6f9b-4dc1-8e3a-03020cb8990f@o11g2000yql.googlegroups.com>
On 23 Mar, 23:53, Kaz Kylheku <········@gmail.com> wrote:
> Yes; these issues are in fact ``issues''.
>
> I.e. psychological problems to be taken up with your therapist.
>
> The reasonable software engineer doesn't care about NCONC versus PUSH.

Then maybe I'm not a reasonable software engineer. Have you ever met a
programmer who redefines basic operators as "==" and "!=". Here I am
^_^

Indeed, I've yet to decide if a switch to a sales career would be the
best choice for me now, all things considered. Smart people go into
management or sales, don't they?

> See, in the real world we work on projects in which the number of
> symbols defined in the language is dwarfed by project-defined symbols.
>
> The important thing about language-defined symbols is that they are
> standardized. That's the beginning and the end.

It depends. How many inconsistencies are there? Both within the
standard and most used libraries? Few? OK, not an ideal solution,
still we can cope with that. Many? Hmmm... we really have to?

But: newbies and not so skilled programmers learn by looking at the
standard and the libraries they are using, therefore bad practice
spreads. How many C++ programmers have you known who program as the C
library and MFC were a best practice manual? We'll have to mantain/fix
their code.

More: many programmers have to deal with different languages, each
with its own standard and idiosyncrasies (me, too). Let's help them
not having too much to remember, if we can. Don't you care about your
more troubled fellows?

> Anyway, you obviously have not even thought about this very well, because not
> all of the destructive operations are the same.

You bet! I stated very early that I'm a CL newbie. But I'm not a
programming newbie, therefore I thought I could have a few (hopefully
useful) things to say. Of course, I've asked the experts first.

> Consider that NCONC destructively manipulates an /object/, whereas PUSH
> manipulates a /place/. The N means that it's non-consing. Why should they both
> share some ! convention?
>
> NCONC behaves the same as APPEND, except that it's destructive. But PUSH is
> /necessarily/ destructive; there can be no non-destructive flavor of PUSH.

I won't get lost into details here because I'm not skilled enough.
What I care about is: are the function's arguments going to be
modified in place (destructed)? I'd like to know that at the point
where they are called (that's why I hate C++ references, always need
to check prototypes grrrrr).

> Using the character ! in standard symbols is a terrible idea.  Doing so would
> effectively  make the ! character reserved and unavailable for use in custom
> read macros (except as a dispatch character where the context makes it clear
> that it's not a symbol constituent).

You know better, you pick the character you prefer ^_^ I don't mind, I
just borrowed from Scheme (an existing standard, I'm not playing the
inventor character here). I only care it's easy to search and to spot.
"N" prefix doesn't cut it, don't you agree?

> In the Lisp language there is already a convention for introducing a variant on
> some function or operator, which is like another one but somewhat different.
> This convention is to append the * character to the name, exemplified by DO and
> DO*, or LET and LET*, LIST and LIST*.

I knew that. Works for me, too. As you have already understood, I'm
not discussing variants here. I'd only like to distinguish between
consing/destructive functions.

> In a Lisp designed from scratch, I would gravitate toward this convention in
> naming pairs of functions which are related such that one is destructive and
> the other isn't:  APPEND and APPEND*, et cetera. The name CONC! instead of
> NCONC doesn't fix the fact that CONC and APPEND are unrelated words, yet they
> are used for naming almost exactly the same function.
> About PUSH, I would say that it's inconsistent with some of the other operators
> that manipulate places. Don't compare the name PUSH to NCONC but to SETF,
> ROTATEF, and INCF.  The F probably means ``form'' because these operators take
> a form which designates a place, and mutate its value. So PUSH and POP might be
> called PUSHF and POPF.
>
> In a language designed from scratch, I'd probably avoid these cryptic suffices.
> Obviously SETF has the suffix because SET is already taken, and there is the
> SETQ precedent. The other cousins of SETF which use setf expansion have the F
> because they imitate SETF. In a brand new Lisp, I'd just call them SET, INC,
> ROTATE, PUSH and POP.

We are on c.l.l here, aren't we? For a moment I thought I was on
c.l.scheme ^_^
(everyone designing his own extension)

Designing a new Lisp? Oh, no. CL is quite good already. Tested by
time. Let's just fix some minor issues, add a few libraries useful to
current needs and... conquer the world.

>
> Anyway, Doc, I see that our hour is up; I feel better.

I hope you're right. I'll feel better then, too.

Thank you very much Kaz for your very detailed post.

Cheers
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <5958993a-adf7-483d-b36f-46a22a32c4a1@j38g2000yqa.googlegroups.com>
On Mar 25, 3:13 am, Kaz Kylheku <········@gmail.com> wrote:
> On 2009-03-24, Elena <········@gmail.com> wrote:
>
> > On 23 Mar, 23:53, Kaz Kylheku <········@gmail.com> wrote:
> >> Yes; these issues are in fact ``issues''.
>
> >> I.e. psychological problems to be taken up with your therapist.
>
> >> The reasonable software engineer doesn't care about NCONC versus PUSH.
>
> > Then maybe I'm not a reasonable software engineer. Have you ever met a
> > programmer who redefines basic operators as "==" and "!=".
>
> Yes; this is done all the time in C++. It allows expressions like
> ptr != 0 to work, where ptr is an instance of a smart pointer class.
>
> You aren't special, sorry.

I *am* special, sorry. I wasn't talking about operator overloading.

I don't want to repeat it here. Search among threads if you are
curious.

>
> > Indeed, I've yet to decide if a switch to a sales career would be the
> > best choice for me now, all things considered.
>
> If you can sell your naive Lisp proposals to comp.lang.lisp, I'd say you have a
> chance.

My proposals could be naive indeed, but I'm not the only one who
wishes to update the standard. And I've read proposals which not naive
at all.

Anyway, I'll take your suggestion and consider this "sell" to be my
entry level test for sales career ;-)))))

>
> > But: newbies and not so skilled programmers learn by looking at the
> > standard and the libraries they are using, therefore bad practice
> > spreads. How many C++ programmers have you known who program as the C
> > library and MFC were a best practice manual? We'll have to mantain/fix
> > their code.
>
> Speaking of C++ and standards, it's safe to say that 99.999...% of the world's
> C and C++ programmers have never seen so much as the cover pages of their
> applicable standards.

I don't think so. Maybe it's safer to say that 99.999...% of the
world's C and C++ programmers start(ed) programming by looking at
tutorial based onto the standard, therefore practices "promoted" by
the standard are still likely to be followed.

Cheers
From: Tamas K Papp
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <72ugarFrmpirU1@mid.individual.net>
On Wed, 25 Mar 2009 02:17:00 -0700, Elena wrote:

> On Mar 25, 3:13 am, Kaz Kylheku <········@gmail.com> wrote:
>>
>> If you can sell your naive Lisp proposals to comp.lang.lisp, I'd say
>> you have a chance.
> 
> My proposals could be naive indeed, but I'm not the only one who wishes
> to update the standard. And I've read proposals which not naive at all.

Many of the "proposals" to update the standard tell you more about the
cluelessness of their proponents than CL.

CL was designed to be extremely extensible, and 95% of the proposed
"updates" can be dealt with by defining a thin layer of utilities,
perhaps in a separate namespace, as many of the examples above have
indicated.  For example, I don't see why the inclusion of someone's
favorite utilities necessitates a revision of the standard, when you
can just use a library and start programming; the continuous low-key
whining about the need to update the standard is an excuse for not
programming.

If people feel that the current standard is very constraining, they
can build a new language on top of CL, like Mark Tarver did with Qi
I/II, an excellent piece of work.

Tamas
From: Kaz Kylheku
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <20090403073330.138@gmail.com>
On 2009-03-25, Tamas K Papp <······@gmail.com> wrote:
> On Wed, 25 Mar 2009 02:17:00 -0700, Elena wrote:
>
>> On Mar 25, 3:13 am, Kaz Kylheku <········@gmail.com> wrote:
>>>
>>> If you can sell your naive Lisp proposals to comp.lang.lisp, I'd say
>>> you have a chance.
>> 
>> My proposals could be naive indeed, but I'm not the only one who wishes
>> to update the standard. And I've read proposals which not naive at all.
>
> Many of the "proposals" to update the standard tell you more about the
> cluelessness of their proponents than CL.

I would fix things that were identified as issues (obviously). Hunt down areas
in the language where there was controversy and compromises were made for the
sake of implementations, and give those areas a face lift.

For instance, there is the business of a dynamic control transfers that is
``hijacked'' by the initiation of another control transfer inside an
unwind-protect cleanup clause. This needs to have sensible semantics; it's not
acceptable to permit the tear-down of all intervening exit points between the
original control transfer and its target before unwinding takes place. The
unwind protect should still see everything that was in the dynamic contour at
the time when the unwind-protect form started evaluating.  

See this is the sort of thing I'd want to see in the next standard.

Not some bullshit, puerile renaming of NCONC.
From: Kaz Kylheku
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <20090403071808.35@gmail.com>
On 2009-03-25, Elena <········@gmail.com> wrote:
> On Mar 25, 3:13 am, Kaz Kylheku <········@gmail.com> wrote:
>> On 2009-03-24, Elena <········@gmail.com> wrote:
>> > spreads. How many C++ programmers have you known who program as the C
>> > library and MFC were a best practice manual? We'll have to mantain/fix
>> > their code.
>>
>> Speaking of C++ and standards, it's safe to say that 99.999...% of the
>> world's C and C++ programmers have never seen so much as the cover pages of
>> their applicable standards.
>
> I don't think so. Maybe it's safer to say that 99.999...% of the
> world's C and C++ programmers start(ed) programming by looking at
> tutorial based onto the standard, therefore practices "promoted" by
> the standard are still likely to be followed.

And so what if they are? I think that the C++ standard library is well-designed
in its conventions. And so is the C one even. Come on, ``strpbrk'' and
``strcspn'' are awesome mnemonics. Find the [p]ointer to the [br]ea[k] in the
string where one of a set of characters occurs for the first time, and
compute the length of the [sp]a[n] of characters made up of the [c]omplement of
the given set.

I don't know what your beef is with MFC (formerly AFX), but I doubt
you are 0.1% of the programmer that were the designers of AFX.  That library
has good, consistent naming conventions. A class name starts with capital C,
members with m_, a window handle member is m_hw<something>, a function that
handles an event is OnSomething(...) and so on. 
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <8ac66623-4fea-4425-8c90-24e470a7f39d@v19g2000yqn.googlegroups.com>
On 25 Mar, 22:12, Kaz Kylheku <········@gmail.com> wrote:
> > I don't think so. Maybe it's safer to say that 99.999...% of the
> > world's C and C++ programmers start(ed) programming by looking at
> > tutorial based onto the standard, therefore practices "promoted" by
> > the standard are still likely to be followed.
>
> And so what if they are? I think that the C++ standard library is well-designed
> in its conventions. And so is the C one even. Come on, ``strpbrk'' and
> ``strcspn'' are awesome mnemonics. Find the [p]ointer to the [br]ea[k] in the
> string where one of a set of characters occurs for the first time, and
> compute the length of the [sp]a[n] of characters made up of the [c]omplement of
> the given set.

I understand your opinion and I could agree that the designers of the
library have made a good job with what they have got in the time they
have designed it. The designers of the language less so, but it's
always easy to criticize. C++ is broken, a curse for those who have to
learn it (been there, done that), yet who's going to fix it? Nobody.
Your best option is to take it as an experiment, and use the C++
compiler as a C one with better type checks. Maybe stick with C with
classes. Wanna have a look at a soundly designed language and library?
Look at Eiffel. Sadly it has never catched up.

Maybe "strpbrk" and "strcspn" are awesome mnemonics, an useful
optimization to save bytes on the disks when they used to be
expensive. "Compressed" identifiers still employed by C programmers
decades after them are much less awesome. You don't see even junior
Lisp programmers saving characters when they choose their identifiers?
Guess why.

>
> I don't know what your beef is with MFC (formerly AFX), but I doubt
> you are 0.1% of the programmer that were the designers of AFX.  That library
> has good, consistent naming conventions. A class name starts with capital C,
> members with m_, a window handle member is m_hw<something>, a function that
> handles an event is OnSomething(...) and so on.

I agree with you. Again, sadly programmers still have used smartly
designed yet cumbersome MFC RTTI long after C++ got its own RTTI; they
don't understand the real meaning of Hungarian notation and use all
sorts of useless prefixes in the identifiers they choose. And so on.
Do you think such programmers are irrecoverable fools? I'm telling you
something: been there, done that. I thought that things where the way
they were because that was the "right" way: better learn by copying
the gurus. Having not had a clue about "legacy" support for a long
time. Got it?

I hope I'm much wiser today.

Cheers
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <90100736-19a5-4e4a-bb13-b437b552fba0@b16g2000yqb.googlegroups.com>
On 26 Mar, 01:38, Elena <········@gmail.com> wrote:
> I understand your opinion and I could agree that the designers of the
> library have made a good job with what they have got in the time they
> have designed it. The designers of the language less so, but it's
> always easy to criticize. C++ is broken, a curse for those who have to
> learn it (been there, done that), yet who's going to fix it? Nobody.
> Your best option is to take it as an experiment, and use the C++
> compiler as a C one with better type checks. Maybe stick with C with
> classes. Wanna have a look at a soundly designed language and library?
> Look at Eiffel. Sadly it has never catched up.

The only really useful C++ advanced programming construct I've found
so far is smart pointers. They solve a really difficult problem. When
it comes to other things, who wants to deal with bizantine error
messages from the compiler.
From: Pascal J. Bourguignon
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <8763hweoln.fsf@galatea.local>
Elena <········@gmail.com> writes:

> On 26 Mar, 01:38, Elena <········@gmail.com> wrote:
>> I understand your opinion and I could agree that the designers of the
>> library have made a good job with what they have got in the time they
>> have designed it. The designers of the language less so, but it's
>> always easy to criticize. C++ is broken, a curse for those who have to
>> learn it (been there, done that), yet who's going to fix it? Nobody.
>> Your best option is to take it as an experiment, and use the C++
>> compiler as a C one with better type checks. Maybe stick with C with
>> classes. Wanna have a look at a soundly designed language and library?
>> Look at Eiffel. Sadly it has never catched up.
>
> The only really useful C++ advanced programming construct I've found
> so far is smart pointers. They solve a really difficult problem. 

They don't solve anything.  
By contrast: Garbage collection solves a problem.

> When
> it comes to other things, who wants to deal with bizantine error
> messages from the compiler.

-- 
__Pascal Bourguignon__
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <2d451024-19d8-4a74-ae40-156db824c845@h5g2000yqh.googlegroups.com>
On Mar 26, 7:21 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Elena <········@gmail.com> writes:
> > The only really useful C++ advanced programming construct I've found
> > so far is smart pointers. They solve a really difficult problem.
>
> They don't solve anything.  
> By contrast: Garbage collection solves a problem.

They do. Garbage collection doesn't cut everything. OTOH, smart
pointers allow you to implement garbage collection too. IMHO, along
with RAII idiom, here is where C++ is unique and shines above every
other (OOP) language. Nope, "with-open-THING" doesn't cut it (what if
you forget using it?). I don't know, perhaps you could emulate smart
pointers using scads of macros, but that would make the C++ crowd just
smile.

I won't go further. If you'd like to know more, post on a C++
newsgroup.

Cheers
From: Daniel Janus
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <slrngsmn0i.d4v.przesunmalpe@students.mimuw.edu.pl>
Dnia 26.03.2009 Elena <········@gmail.com> napisa�/a:

>> > The only really useful C++ advanced programming construct I've found
>> > so far is smart pointers. They solve a really difficult problem.
>>
>> They don't solve anything. �
>> By contrast: Garbage collection solves a problem.
>
> They do. Garbage collection doesn't cut everything. OTOH, smart
> pointers allow you to implement garbage collection too. IMHO, along
> with RAII idiom, here is where C++ is unique and shines above every
> other (OOP) language. 

Yeah.  From Linux's `man 2 close':

   Not checking the return value of close() is a common  but  nevertheless
   serious  programming error.  It is quite possible that errors on a pre-
   vious write(2) operation are first reported at the final close().   Not
   checking the return value when closing the file may lead to silent loss
   of data.  This can especially be observed with NFS and with disk quota.

Now what do the implementations of ofstream destructors out there do 
when the underlying close() returns an error?  Yes, that's right, they
*shamelessly and silently ignore the error*.  They cannot throw
exceptions, because throwing exceptions from C++ destructors is the
most straight way to all hell breaking loose.  Talk about WITH-OPEN-FILE's 
``disadvantages''!

-- 
Daniel 'Nathell' Janus, ······@nathell.korpus.pl, http://korpus.pl/~nathell
Nothing smells more like a slaughterhouse than a graduate seminar.
   -- Leonard Cohen, "The Favourite Game"
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <7095932a-be04-491b-987e-3a91826346b5@s20g2000yqh.googlegroups.com>
On Mar 26, 10:42 am, Daniel Janus <············@nathell.korpus.pl>
wrote:
> Dnia 26.03.2009 Elena <········@gmail.com> napisa³/a:
>
> >> > The only really useful C++ advanced programming construct I've found
> >> > so far is smart pointers. They solve a really difficult problem.
>
> >> They don't solve anything.  
> >> By contrast: Garbage collection solves a problem.
>
> > They do. Garbage collection doesn't cut everything. OTOH, smart
> > pointers allow you to implement garbage collection too. IMHO, along
> > with RAII idiom, here is where C++ is unique and shines above every
> > other (OOP) language.
>
> Yeah.  From Linux's `man 2 close':
>
>    Not checking the return value of close() is a common  but  nevertheless
>    serious  programming error.  It is quite possible that errors on a pre-
>    vious write(2) operation are first reported at the final close().   Not
>    checking the return value when closing the file may lead to silent loss
>    of data.  This can especially be observed with NFS and with disk quota.
>
> Now what do the implementations of ofstream destructors out there do
> when the underlying close() returns an error?  Yes, that's right, they
> *shamelessly and silently ignore the error*.  They cannot throw
> exceptions, because throwing exceptions from C++ destructors is the
> most straight way to all hell breaking loose.  Talk about WITH-OPEN-FILE's
> ``disadvantages''!

struct Fool_proof_ofstream : protected std::ofstream {
    // Implementation skipped.
    virtual ~Fool_proof_ofstream () {
       // Check whether "close" has been called. Otherwise, fire
       // an assertion in debug mode, or try to issue a warning
       // in release mode.
       // Implementation left out.
    }
};

IMHO, C++ streams are for losers anyway: long live (encapsulated)
"stdio.h"!

You know, standards can have issues too. They aren't a best practice
guide either. Now try to make most CLers realize that.

Cheers
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <a43c0bd3-60ed-4392-8f13-e569d095b175@v39g2000yqm.googlegroups.com>
On Mar 26, 11:07 am, Elena <········@gmail.com> wrote:
> IMHO, C++ streams are for losers anyway: long live (encapsulated)
> "stdio.h"!

Rushed to comment here. I meant: they are just an interesting yet
failed experiment. Long live "stdio.h" again!
From: Daniel Janus
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <slrngsmpoh.b93.przesunmalpe@students.mimuw.edu.pl>
Dnia 26.03.2009 Elena <········@gmail.com> napisa�/a:

>        // Check whether "close" has been called. 

And force yourself to remember to call it just at the right moment 
in all possible control flows through your code?  This is manual
resource management.  Isn't it exactly this that RAII was supposed
to solve?

-- 
Daniel 'Nathell' Janus, ······@nathell.korpus.pl, http://korpus.pl/~nathell
Nazwanie czego� ,,g�wnem'' jest wspania�ym argumentem politycznym,
ale ma zerow� moc poznawcz�.
   -- Stefan Soko�owski, pl.hum.polszczyzna
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <6b804afe-f3ad-47fc-9811-493f107d2d2e@h5g2000yqh.googlegroups.com>
On Mar 26, 11:29 am, Daniel Janus <············@nathell.korpus.pl>
wrote:
> Dnia 26.03.2009 Elena <········@gmail.com> napisa³/a:
>
> >        // Check whether "close" has been called.
>
> And force yourself to remember to call it just at the right moment
> in all possible control flows through your code?  This is manual
> resource management.  Isn't it exactly this that RAII was supposed
> to solve?

It was just an example: you think you should check *every* "close"
return code? You can make the program remind you about that. You
choose.
From: Pascal J. Bourguignon
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <7cskl0d1qi.fsf@pbourguignon.anevia.com>
Elena <········@gmail.com> writes:

> On Mar 26, 7:21�am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Elena <········@gmail.com> writes:
>> > The only really useful C++ advanced programming construct I've found
>> > so far is smart pointers. They solve a really difficult problem.
>>
>> They don't solve anything. �
>> By contrast: Garbage collection solves a problem.
>
> They do. Garbage collection doesn't cut everything. OTOH, smart
> pointers allow you to implement garbage collection too. IMHO, along
> with RAII idiom, here is where C++ is unique and shines above every
> other (OOP) language. Nope, "with-open-THING" doesn't cut it (what if
> you forget using it?). I don't know, perhaps you could emulate smart
> pointers using scads of macros, but that would make the C++ crowd just
> smile.
>
> I won't go further. If you'd like to know more, post on a C++
> newsgroup.


struct A {
  SmartPtr<A> n;
};

void f(){
  SmartPtr<A> a=new A;
  a->n=a;
} // what happens here?


On the other hand,

(defstruct a n)
(let ((a (make-a)))
  (setf (a-n a) a)
  ) ; here a can be garbage collected.




-- 
__Pascal Bourguignon__
From: Tamas K Papp
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <7317f9Fsai2gU1@mid.individual.net>
On Thu, 26 Mar 2009 03:00:08 -0700, Elena wrote:

> They do. Garbage collection doesn't cut everything. OTOH, smart pointers
> allow you to implement garbage collection too. IMHO, along with RAII

Why would I want to implement garbage collection?  CL already has it.
If C++ doesn't, why would I use it?  I had the misfortune of using a
symbolic library written in C++ during the summer of 2006, which had a
garbage collection system implemented by the author - it crashed about
10% of the time.  Cf Greenspun's 10th law.

> idiom, here is where C++ is unique and shines above every other (OOP)
> language. Nope, "with-open-THING" doesn't cut it (what if you forget
> using it?). I don't know, perhaps you could emulate smart pointers using
> scads of macros, but that would make the C++ crowd just smile.

But why would I want to emulate smart pointers?  CL already has
garbage collection, bounds checking, etc.  If I reimplemented these
things using macros, then even Lisp programmers would smile and say:
"Lo! That idiot is wasting his time instead of writing applications!".

> I won't go further. If you'd like to know more, post on a C++ newsgroup.

If you are representative of the C++ programmer crowd, then I would
never want to post on a C++ newsgroup.  You came here and started a
pointless thread, then started talking about C++.  I am sorry that you
are unemployed and cannot use your time more productively, but that
doesn't excuse generating noise on CLL.  Learn a foreign language (a
natural language, not a computer one, you don't seem to have the knack
for the latter), get a pet, or take up gardening, whatever fills your
time, just please stop posting random stuff here.

Tamas
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <7ca321d0-c6b7-4869-b572-5e01528565b1@s20g2000yqh.googlegroups.com>
On Mar 26, 11:33 am, Tamas K Papp <······@gmail.com> wrote:
> On Thu, 26 Mar 2009 03:00:08 -0700, Elena wrote:
> > They do. Garbage collection doesn't cut everything. OTOH, smart pointers
> > allow you to implement garbage collection too. IMHO, along with RAII
>
> Why would I want to implement garbage collection?  CL already has it.
> If C++ doesn't, why would I use it?  I had the misfortune of using a
> symbolic library written in C++ during the summer of 2006, which had a
> garbage collection system implemented by the author - it crashed about
> 10% of the time.  Cf Greenspun's 10th law.
>
> > idiom, here is where C++ is unique and shines above every other (OOP)
> > language. Nope, "with-open-THING" doesn't cut it (what if you forget
> > using it?). I don't know, perhaps you could emulate smart pointers using
> > scads of macros, but that would make the C++ crowd just smile.
>
> But why would I want to emulate smart pointers?  CL already has
> garbage collection, bounds checking, etc.  If I reimplemented these
> things using macros, then even Lisp programmers would smile and say:
> "Lo! That idiot is wasting his time instead of writing applications!".

Oh yeah, CL is perfect. I know, I know.

BTW, garbage collection issues have been pointed out elsewhere, I
won't repeat it here. Search engines are your friends :-)

> > I won't go further. If you'd like to know more, post on a C++ newsgroup.
>
> If you are representative of the C++ programmer crowd, then I would
> never want to post on a C++ newsgroup.  You came here and started a
> pointless thread, then started talking about C++.  I am sorry that you
> are unemployed and cannot use your time more productively, but that
> doesn't excuse generating noise on CLL.  Learn a foreign language (a
> natural language, not a computer one, you don't seem to have the knack
> for the latter), get a pet, or take up gardening, whatever fills your
> time, just please stop posting random stuff here.

I'm not representative of the C++ programmer crowd at all, guaranteed.
Does that make you happier? I hope so. (No flame intended)

Pointless thread? Random stuff? We'll see. If I realize that the prize
is worth the trouble... I'm still thinking about it.
From: Tamas K Papp
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <7319rjFsjhdqU1@mid.individual.net>
On Thu, 26 Mar 2009 04:53:59 -0700, Elena wrote:

> On Mar 26, 11:33 am, Tamas K Papp <······@gmail.com> wrote:
>>
>> But why would I want to emulate smart pointers?  CL already has garbage
>> collection, bounds checking, etc.  If I reimplemented these things
>> using macros, then even Lisp programmers would smile and say: "Lo! That
>> idiot is wasting his time instead of writing applications!".
> 
> Oh yeah, CL is perfect. I know, I know.

Whether CL is perfect is not relevant here.  I just pointed out that
it already has the features that smart pointers provide, so emulating
them in CL is quite pointless (except as an intellectual exercise).

> I'm not representative of the C++ programmer crowd at all, guaranteed.

I think that you are.  This is not the first time in this thread where
you claim that you are special, I have not seen any evidence to
support that.  It appears that thinking that you are an outlier makes
you feel better, but please realize that it does not impress people.

> Pointless thread? Random stuff? We'll see. If I realize that the prize
> is worth the trouble... I'm still thinking about it.

Yeah, whatever.  If you had spent 50% of the time you devoted to
writing to CLL on learning Lisp, you could have made a decision
already.  Clearly you don't want to do it, and exploring the reasons
behind this is up to you and your therapist.

Good luck.

Tamas
From: Larry Coleman
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <ee5b7268-0613-41da-9818-506a33536fc7@m36g2000vbp.googlegroups.com>
On Mar 26, 8:13 am, Tamas K Papp <······@gmail.com> wrote:

> > I'm not representative of the C++ programmer crowd at all, guaranteed.
>
> I think that you are.  
>

No, she's not. Experienced C/C++ programmers generally don't #define
away && and ||.

Larry Coleman
From: Marco Antoniotti
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <a6ba58ab-083a-454f-80fa-29e426c529c3@w9g2000yqa.googlegroups.com>
On Mar 26, 2:01 pm, Larry Coleman <············@yahoo.com> wrote:
> On Mar 26, 8:13 am, Tamas K Papp <······@gmail.com> wrote:
>
> > > I'm not representative of the C++ programmer crowd at all, guaranteed.
>
> > I think that you are.  
>
> No, she's not. Experienced C/C++ programmers generally don't #define
> away && and ||.

... they write Emacs functions that detect if

#include <iso646.h>

appears in the code. :)

Cheers
--
Marco
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <d10bce4b-05ea-4f1f-b5a7-3a472bc8e258@e5g2000vbe.googlegroups.com>
On Mar 26, 1:01 pm, Larry Coleman <············@yahoo.com> wrote:
> On Mar 26, 8:13 am, Tamas K Papp <······@gmail.com> wrote:
>
> > > I'm not representative of the C++ programmer crowd at all, guaranteed.
>
> > I think that you are.  
>
> No, she's not. Experienced C/C++ programmers generally don't #define
> away && and ||.
>
> Larry Coleman

s/Experienced/Average experienced/

;-)
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <1e13220d-bbfc-4d61-92c4-8c815236aad4@s19g2000vbp.googlegroups.com>
On Mar 26, 1:13 pm, Elena <········@gmail.com> wrote:
> On Mar 26, 1:01 pm, Larry Coleman <············@yahoo.com> wrote:
>
> > On Mar 26, 8:13 am, Tamas K Papp <······@gmail.com> wrote:
>
> > > > I'm not representative of the C++ programmer crowd at all, guaranteed.
>
> > > I think that you are.  
>
> > No, she's not. Experienced C/C++ programmers generally don't #define
> > away && and ||.
>
> > Larry Coleman
>
> s/Experienced/Average experienced/
>
> ;-)

I just forgot. Have a read:

http://groups.google.com/group/comp.lang.lisp/msg/39264ea41667ca9b

I hope you'll value Pascal's opinion more, since he is from your own
crowd.

Cheers
From: Larry Coleman
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <a5d1e0e7-836c-46ca-803c-e273be277aee@r3g2000vbp.googlegroups.com>
On Mar 26, 9:21 am, Elena <········@gmail.com> wrote:
> On Mar 26, 1:13 pm, Elena <········@gmail.com> wrote:
>
>
>
> > On Mar 26, 1:01 pm, Larry Coleman <············@yahoo.com> wrote:
>
> > > On Mar 26, 8:13 am, Tamas K Papp <······@gmail.com> wrote:
>
> > > > > I'm not representative of the C++ programmer crowd at all, guaranteed.
>
> > > > I think that you are.  
>
> > > No, she's not. Experienced C/C++ programmers generally don't #define
> > > away && and ||.
>
> > > Larry Coleman
>
> > s/Experienced/Average experienced/
>
> > ;-)
>
> I just forgot. Have a read:
>
> http://groups.google.com/group/comp.lang.lisp/msg/39264ea41667ca9b
>
> I hope you'll value Pascal's opinion more, since he is from your own
> crowd.
>
> Cheers

That's fine, but my point was that you are entirely correct in saying
that you're not representative of the C++ crowd.

For the record, I'm not actually part of the lisp crowd. I mainly lurk
here because the flame wars are much more interesting (and frequent)
than the ones on comp.lang.haskell.
From: Thomas A. Russ
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <ymid4c4j6tq.fsf@blackcat.isi.edu>
Larry Coleman <············@yahoo.com> writes:

> For the record, I'm not actually part of the lisp crowd. I mainly lurk
> here because the flame wars are much more interesting (and frequent)
> than the ones on comp.lang.haskell.

We'd be happy to lend them a few trolls, if only we could figure out how...

-- 
Thomas A. Russ,  USC/Information Sciences Institute
From: Larry Coleman
Subject: Why Lisp Can't Offload its Trolls to Haskell (Was: Re: Common Lisp's 	fixable issues?)
Date: 
Message-ID: <ef867b18-b1b0-4202-93da-9a248106f5fb@v28g2000vbb.googlegroups.com>
On Mar 26, 5:46 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Larry Coleman <············@yahoo.com> writes:
> > For the record, I'm not actually part of the lisp crowd. I mainly lurk
> > here because the flame wars are much more interesting (and frequent)
> > than the ones on comp.lang.haskell.
>
> We'd be happy to lend them a few trolls, if only we could figure out how...
>
> --
> Thomas A. Russ,  USC/Information Sciences Institute

Having lurked on both groups for a while, I'm not sure it's even
possible. Haskell's approach to newbies is different. Newbies who are
willing to put in the work and approach it with an open mind are
welcomed. Those who aren't mostly never show up in the first place
because of stuff like:

product :: Num a => [a] -> a
product = foldr1 (*)

Even if they get past that, they start to get antsy when told there's
no such thing as assignment, and run away screaming at the first
mention of the word "monad."

But that's really a side issue. The main reason IMHO is that Haskell
is still very much a moving target. The spec is still being actively
worked on, and even the old hands are still experimenting with how
best to do things.

Larry Coleman
From: Elena
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell (Was: Re: Common 	Lisp's fixable issues?)
Date: 
Message-ID: <a2ef807f-33ce-4e5d-ad36-1ac2d4ea8ffd@q9g2000yqc.googlegroups.com>
On Mar 27, 12:54 pm, Larry Coleman <············@yahoo.com> wrote:
> On Mar 26, 5:46 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
> > Larry Coleman <············@yahoo.com> writes:
> > > For the record, I'm not actually part of the lisp crowd. I mainly lurk
> > > here because the flame wars are much more interesting (and frequent)
> > > than the ones on comp.lang.haskell.
>
> > We'd be happy to lend them a few trolls, if only we could figure out how...
>
> > --
> > Thomas A. Russ,  USC/Information Sciences Institute
>
> Having lurked on both groups for a while, I'm not sure it's even
> possible. Haskell's approach to newbies is different. Newbies who are
> willing to put in the work and approach it with an open mind are
> welcomed. Those who aren't mostly never show up in the first place
> because of stuff like:
>
> product :: Num a => [a] -> a
> product = foldr1 (*)
>
> Even if they get past that, they start to get antsy when told there's
> no such thing as assignment, and run away screaming at the first
> mention of the word "monad."

Speaking as a troll - as I hope I have already qualified as such, but
I still wonder how I shall manage to get my name into c.l.l. "mad
list" - I've never lurked or even checked out comp.lang.haskell. I got
past monads and stuff like:

> product :: Num a => [a] -> a
> product = foldr1 (*)

But then I ran away screaming at the first mention of ten levels of
precedence among operators. Ten! I mean: what's the matter with them
guys? And what about those user definable cryptic operators? Am I
supposed to parse ten levels of precedence and hieroglyphs? Think of
useless IT college questions...

Therefore, for better or worse, as long as CL has both parentheses and
human readable symbols (and I'm not banned), I'm lurking here,
fellows.

>
> But that's really a side issue. The main reason IMHO is that Haskell
> is still very much a moving target. The spec is still being actively
> worked on, and even the old hands are still experimenting with how
> best to do things.

I think CL gets hyped as the forgotten hidden gem of IT, too (think
Paul Graham essays). Of course those essays do fire up all kinds of
quirky people.

Another reason is that CL lacks a FAQ explaining some issues too.
Interested people will not land here just to flame - they don't
complain about parenthesis, lack of GUI IDEs, etc. they have already
been sold such things - but they ask genuine/ingenuous questions they
haven't found an answer to (as others and I have done, I think).

Speaking of that, I was thinking about updating myself the CL FAQ to
sort some things out. FAQ found over the Internet are dated too. Last
thread about a Newbie CL FAQ dates three years ago. I'll get in touch
with current FAQ mantainers. Maybe I'll start this weekend, if I don't
get any dates.

Cheers Lispers (or Lispniks?)
:-)))))
From: Pascal J. Bourguignon
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell
Date: 
Message-ID: <7ctz5fqb4w.fsf@pbourguignon.anevia.com>
Elena <········@gmail.com> writes:
> Another reason is that CL lacks a FAQ explaining some issues too.

It doesn't have one FAQ, it doesn't have two FAQs, it doesn't have
three FAQs, it has at least FOUR FAQs!

http://www.google.fr/search?q=Common+Lisp+FAQ

> Speaking of that, I was thinking about updating myself the CL FAQ to

Which one?

> sort some things out. FAQ found over the Internet are dated too. 

So what?  Lisp is 50 years old.

It's Frequently Asked Questions, not Recently Asked Questions!

Perhaps you should instead create a RAQ!  That would solve the problem
all these newbies seem to have.


> Last
> thread about a Newbie CL FAQ dates three years ago. I'll get in touch
> with current FAQ mantainers. Maybe I'll start this weekend, if I don't
> get any dates.

Forget the FAQ.  Run a RAQ!


-- 
__Pascal Bourguignon__
From: GP lisper
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell (Was: Re: Common  Lisp's fixable issues?)
Date: 
Message-ID: <slrngsr6en.din.spambait@phoenix.clouddancer.com>
On Fri, 27 Mar 2009 07:10:46 -0700 (PDT), <········@gmail.com> wrote:
> On Mar 27, 12:54�pm, Larry Coleman <············@yahoo.com> wrote:
>> On Mar 26, 5:46�pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>>
>> > Larry Coleman <············@yahoo.com> writes:
>> > > For the record, I'm not actually part of the lisp crowd. I mainly lurk
>> > > here because the flame wars are much more interesting (and frequent)
>> > > than the ones on comp.lang.haskell.
>>
>> > We'd be happy to lend them a few trolls, if only we could figure out how...
>>
>> > --
>> > Thomas A. Russ, �USC/Information Sciences Institute
>>
>> Having lurked on both groups for a while, I'm not sure it's even
>> possible. Haskell's approach to newbies is different. Newbies who are
>> willing to put in the work and approach it with an open mind are
>> welcomed. Those who aren't mostly never show up in the first place
>> because of stuff like:
>>
>> product :: Num a => [a] -> a
>> product = foldr1 (*)
>>
>> Even if they get past that, they start to get antsy when told there's
>> no such thing as assignment, and run away screaming at the first
>> mention of the word "monad."
>
> Speaking as a troll - as I hope I have already qualified as such, but
> I still wonder how I shall manage to get my name into c.l.l. "mad
> list" - I've never lurked or even checked out comp.lang.haskell. I got
> past monads and stuff like:
>
>> product :: Num a => [a] -> a
>> product = foldr1 (*)
>
> But then I ran away screaming at the first mention of ten levels of
> precedence among operators. Ten! I mean: what's the matter with them
> guys?

What, you against the Metric System or something?


-- 
If I owned this place and hell, I'd rent it out and live in hell.
From: Andrew Reilly
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell (Was: Re: Common 	Lisp's fixable issues?)
Date: 
Message-ID: <73557pFsvujrU2@mid.individual.net>
On Fri, 27 Mar 2009 07:10:46 -0700, Elena wrote:

> But then I ran away screaming at the first mention of ten levels of
> precedence among operators. Ten! I mean: what's the matter with them
> guys?

Why would that frighten a C++ programmer like you?  C has fourteen.  (I 
don't do C++ if I can help it, but I'd guess it would have a few more.)

cut-and-pasted from "man operator":

           Operator                             Associativity
           --------                             -------------
           () [] -> .                           left to right
           ! ~ ++ -- - (type) * & sizeof        right to left
           * / %                                left to right
           + -                                  left to right
           << >>                                left to right
           < <= > >=                            left to right
           == !=                                left to right
           &                                    left to right
           ^                                    left to right
           |                                    left to right
           &&                                   left to right
           ||                                   left to right
           ?:                                   right to left
           = += -= *= /= %= <<= >>= &= ^= |=    right to left
           ,                                    left to right

So: fourteen levels *and* two directions.  The parser must look a hoot.

Yes, lack of precedence tables is one of the things that I *love* about 
lisp, forth and assembler.  The whole notion that mathematical 
expressions should also be code is bogus: fortran was a mistake.

Cheers,

-- 
Andrew
From: Larry Coleman
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell (Was: Re: Common 	Lisp's fixable issues?)
Date: 
Message-ID: <69d77912-9359-4880-81ab-d57e7dc4a0bb@c9g2000yqm.googlegroups.com>
On Mar 27, 10:10 am, Elena <········@gmail.com> wrote:
> Speaking as a troll - as I hope I have already qualified as such, but
> I still wonder how I shall manage to get my name into c.l.l. "mad
> list"

You've got my vote for both.

>- I've never lurked or even checked out comp.lang.haskell. I got
> past monads and stuff like:
>
> > product :: Num a => [a] -> a
> > product = foldr1 (*)
>
> But then I ran away screaming at the first mention of ten levels of
> precedence among operators. Ten! I mean: what's the matter with them
> guys? And what about those user definable cryptic operators? Am I
> supposed to parse ten levels of precedence and hieroglyphs? Think of
> useless IT college questions...

Extra troll credit given for your research into Haskell, but you
forgot to mention that precedence can be set for user-defined
operators as well.

>
> Therefore, for better or worse, as long as CL has both parentheses and
> human readable symbols (and I'm not banned), I'm lurking here,
> fellows.
>

Yes, but thanks to your hard work and research, you're now qualified
to troll the Haskell groups as well. If you decide to do that, a brief
look at category theory should put the icing on the cake.

Good luck.
From: Slobodan Blazeski
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell (Was: Re: Common 	Lisp's fixable issues?)
Date: 
Message-ID: <8cd03a13-cbdd-4e90-93b8-3afab07ad809@k2g2000yql.googlegroups.com>
On Mar 27, 4:10 pm, Elena <········@gmail.com> wrote
> Speaking as a troll - as I hope I have already qualified as such, but
> I still wonder how I shall manage to get my name into c.l.l. "mad
> list"

Read the complete work of Gavino.  If that doesn't help you can always
hire Xah Lee to coach you.
But I advice to become good cll resident. The competition for trolls
in cll extremely hursh.

bobi
http://tourdelisp.blogspot.com/
http://www.letoverlambda.com/
From: Pascal J. Bourguignon
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell
Date: 
Message-ID: <7c3aczrtnw.fsf@pbourguignon.anevia.com>
Larry Coleman <············@yahoo.com> writes:

> On Mar 26, 5:46�pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>> Larry Coleman <············@yahoo.com> writes:
>> > For the record, I'm not actually part of the lisp crowd. I mainly lurk
>> > here because the flame wars are much more interesting (and frequent)
>> > than the ones on comp.lang.haskell.
>>
>> We'd be happy to lend them a few trolls, if only we could figure out how...
>
> Having lurked on both groups for a while, I'm not sure it's even
> possible. Haskell's approach to newbies is different. Newbies who are
> willing to put in the work and approach it with an open mind are
> welcomed. 

Same here.


> Those who aren't mostly never show up in the first place
> because of stuff like:
>
> product :: Num a => [a] -> a
> product = foldr1 (*)
>
> Even if they get past that, they start to get antsy when told there's
> no such thing as assignment, and run away screaming at the first
> mention of the word "monad."

Sure, compared to () and closures, you have more powerful weapons to
frighten unworthy newbies.


-- 
__Pascal Bourguignon__
From: Kenneth Tilton
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell
Date: 
Message-ID: <49ccdaf1$0$5916$607ed4bc@cv.net>
Pascal J. Bourguignon wrote:
> Larry Coleman <············@yahoo.com> writes:
> 
>> On Mar 26, 5:46 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>>> Larry Coleman <············@yahoo.com> writes:
>>>> For the record, I'm not actually part of the lisp crowd. I mainly lurk
>>>> here because the flame wars are much more interesting (and frequent)
>>>> than the ones on comp.lang.haskell.
>>> We'd be happy to lend them a few trolls, if only we could figure out how...
>> Having lurked on both groups for a while, I'm not sure it's even
>> possible. Haskell's approach to newbies is different. Newbies who are
>> willing to put in the work and approach it with an open mind are
>> welcomed. 
> 
> Same here.
> 
> 
>> Those who aren't mostly never show up in the first place
>> because of stuff like:
>>
>> product :: Num a => [a] -> a
>> product = foldr1 (*)
>>
>> Even if they get past that, they start to get antsy when told there's
>> no such thing as assignment, and run away screaming at the first
>> mention of the word "monad."
> 
> Sure, compared to () and closures, you have more powerful weapons to
> frighten unworthy newbies.
> 
> 

Are you forgetting our six-hundred pound gorilla dressed as an object 
model? And what about LOOP? That had even me hiding under the bed till I 
was ten. We only need those if they get past our first line of defense 
(you know) and make it across the barbed-wire filled moat of Emacs, 
Slime, and ASDF which latter after last night seems to be worse than i 
thought.

kt
From: Pascal J. Bourguignon
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell
Date: 
Message-ID: <7cy6urqctt.fsf@pbourguignon.anevia.com>
Kenneth Tilton <·········@gmail.com> writes:

> Pascal J. Bourguignon wrote:
>> Larry Coleman <············@yahoo.com> writes:
>>
>>> On Mar 26, 5:46 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>>>> Larry Coleman <············@yahoo.com> writes:
>>>>> For the record, I'm not actually part of the lisp crowd. I mainly lurk
>>>>> here because the flame wars are much more interesting (and frequent)
>>>>> than the ones on comp.lang.haskell.
>>>> We'd be happy to lend them a few trolls, if only we could figure out how...
>>> Having lurked on both groups for a while, I'm not sure it's even
>>> possible. Haskell's approach to newbies is different. Newbies who are
>>> willing to put in the work and approach it with an open mind are
>>> welcomed. 
>>
>> Same here.
>>
>>
>>> Those who aren't mostly never show up in the first place
>>> because of stuff like:
>>>
>>> product :: Num a => [a] -> a
>>> product = foldr1 (*)
>>>
>>> Even if they get past that, they start to get antsy when told there's
>>> no such thing as assignment, and run away screaming at the first
>>> mention of the word "monad."
>>
>> Sure, compared to () and closures, you have more powerful weapons to
>> frighten unworthy newbies.
>>
>>
>
> Are you forgetting our six-hundred pound gorilla dressed as an object
> model? And what about LOOP? That had even me hiding under the bed till
> I was ten. We only need those if they get past our first line of
> defense (you know) and make it across the barbed-wire filled moat of
> Emacs, Slime, and ASDF which latter after last night seems to be worse
> than i thought.

They're not frightening enough.
"monad", on the other hand, that is quite the monster!


-- 
__Pascal Bourguignon__
From: Kenneth Tilton
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell
Date: 
Message-ID: <49cce788$0$27770$607ed4bc@cv.net>
Pascal J. Bourguignon wrote:
> Kenneth Tilton <·········@gmail.com> writes:
> 
>> Pascal J. Bourguignon wrote:
>>> Larry Coleman <············@yahoo.com> writes:
>>>
>>>> On Mar 26, 5:46 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>>>>> Larry Coleman <············@yahoo.com> writes:
>>>>>> For the record, I'm not actually part of the lisp crowd. I mainly lurk
>>>>>> here because the flame wars are much more interesting (and frequent)
>>>>>> than the ones on comp.lang.haskell.
>>>>> We'd be happy to lend them a few trolls, if only we could figure out how...
>>>> Having lurked on both groups for a while, I'm not sure it's even
>>>> possible. Haskell's approach to newbies is different. Newbies who are
>>>> willing to put in the work and approach it with an open mind are
>>>> welcomed. 
>>> Same here.
>>>
>>>
>>>> Those who aren't mostly never show up in the first place
>>>> because of stuff like:
>>>>
>>>> product :: Num a => [a] -> a
>>>> product = foldr1 (*)
>>>>
>>>> Even if they get past that, they start to get antsy when told there's
>>>> no such thing as assignment, and run away screaming at the first
>>>> mention of the word "monad."
>>> Sure, compared to () and closures, you have more powerful weapons to
>>> frighten unworthy newbies.
>>>
>>>
>> Are you forgetting our six-hundred pound gorilla dressed as an object
>> model? And what about LOOP? That had even me hiding under the bed till
>> I was ten. We only need those if they get past our first line of
>> defense (you know) and make it across the barbed-wire filled moat of
>> Emacs, Slime, and ASDF which latter after last night seems to be worse
>> than i thought.
> 
> They're not frightening enough.
> "monad", on the other hand, that is quite the monster!
> 
> 

  We should give a tip of the hat to C++, they made constructors into 
chainsaw massacres. And I hear templates are fun.

Hey, what if we tell them McCLIM is the standard Lisp GUI? That should 
finish off any survivors. That and pathnames. I'd say logical pathnames 
but my President says we do not torture. Full marks to the TV feed for 
cutting to Bush when he said that, to W seemed to have been into the 
qualudes already and ... where was I?

kt
From: Elena
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell
Date: 
Message-ID: <5a818c89-d4d2-48dd-a80c-78299ec6db12@v38g2000yqb.googlegroups.com>
On Mar 27, 2:50 pm, Kenneth Tilton <·········@gmail.com> wrote:
>   We should give a tip of the hat to C++, they made constructors into
> chainsaw massacres.

Indeed. Every once and then some friends of mine ask why I'm not fond
of video games. I mean: I already live into a Resident Evil like world
40 hours a week, why should I be eager to have more such fun? Would
you?

> And I hear templates are fun.

Plenty of fun, I swear. If you thought only Perl tries to outsmart
you, think again. With C++ templates you better understand *every*
ramification of your templates expansion or you better be prepared for
a rude awakening. With template meta-programming, I suppose they are
building an Haskell-like compiler on top of C++ (currently it still
lacks TCO, though). Programs which write programs... it sounds
innovative, doesn't it?

C++ is a trinity of a kind. You get three languages within one, which
hardly share something (preprocessor, C++ itself, templates). That's
why most C++ programmers never manage to learn deeply their own
language - even when they are willing to do so - let alone learning
others. That's language lock-in, isn't it?

;-)

Cheers
From: Elena
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell
Date: 
Message-ID: <bb3256f7-7b0f-4a57-a22f-d7f70a17bade@v19g2000yqn.googlegroups.com>
On Mar 27, 3:46 pm, Elena <········@gmail.com> wrote:

> If you thought only Perl tries to outsmart
> you, think again.

Better: "If you thought only Perl tries to guess what you mean, think
again."

> Programs which write programs...

Better: "Compilers which write programs...". Programs which write
programs? Not quite there, still.
From: Rob Warnock
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell
Date: 
Message-ID: <3PudnUivkLUt6FDUnZ2dnUVZ_tOdnZ2d@speakeasy.net>
Elena  <········@gmail.com> wrote:
+---------------
| > Programs which write programs...
| 
| Better: "Compilers which write programs...". Programs which write
| programs? Not quite there, still.
+---------------

Welcome to Lisp! As the old saying goes (which
turns up in ~/.sigs in this group frequently):

    Lisp programmer available: Will write code
    that writes code that writes code for food.


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: GP lisper
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell
Date: 
Message-ID: <slrngsr6af.din.spambait@phoenix.clouddancer.com>
On Fri, 27 Mar 2009 19:56:16 -0500, <····@rpw3.org> wrote:
> Elena  <········@gmail.com> wrote:
> +---------------
>| > Programs which write programs...
>| 
>| Better: "Compilers which write programs...". Programs which write
>| programs? Not quite there, still.
> +---------------
>
> Welcome to Lisp! As the old saying goes (which
> turns up in ~/.sigs in this group frequently):
>
>     Lisp programmer available: Will write code
>     that writes code that writes code for food.

Not enough twisty little passages, maybe

Lisp programmer will code code that codes code for food.


-- 
If I owned this place and hell, I'd rent it out and live in hell.
From: ·······@sagepub.com
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell
Date: 
Message-ID: <uiqlp6ypa.fsf@sagepub.com>
GP lisper <········@CloudDancer.com> writes:

> On Fri, 27 Mar 2009 19:56:16 -0500, <····@rpw3.org> wrote:
>> Elena  <········@gmail.com> wrote:
>> +---------------
>>| > Programs which write programs...
>>| 
>>| Better: "Compilers which write programs...". Programs which write
>>| programs? Not quite there, still.
>> +---------------
>>
>> Welcome to Lisp! As the old saying goes (which
>> turns up in ~/.sigs in this group frequently):
>>
>>     Lisp programmer available: Will write code
>>     that writes code that writes code for food.
>
> Not enough twisty little passages, maybe
>
> Lisp programmer will code code that codes code for food.
>
I have always been fascinated by sentences such as 
Dogs dogs dog dog dogs dogs dog.
And 
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.

Now a new one comes to mind:

Code code codes codes code code codes.
From: Slobodan Blazeski
Subject: Re: Why Lisp Can't Offload its Trolls to Haskell
Date: 
Message-ID: <d9c77e3e-8e1d-44c3-9680-f2db32de4c5a@h28g2000yqd.googlegroups.com>
On Mar 28, 2:56 am, ····@rpw3.org (Rob Warnock) wrote:
> Elena  <········@gmail.com> wrote:
>
> +---------------
> | > Programs which write programs...
> |
> | Better: "Compilers which write programs...". Programs which write
> | programs? Not quite there, still.
> +---------------
>
> Welcome to Lisp! As the old saying goes (which
> turns up in ~/.sigs in this group frequently):
>
>     Lisp programmer available: Will write code
>     that writes code that writes code for food.
That's what I call Three Macro programmer (*)

P.S.
Actually I'm reading book by one of those let over lambda and it's fun
so far http://tourdelisp.blogspot.com/2009/03/first-tas.html

(*) http://c2.com/cgi/wiki?ThreeStarProgrammer
>
> -Rob
>
> -----
> Rob Warnock                     <····@rpw3.org>
> 627 26th Avenue                 <URL:http://rpw3.org/>
> San Mateo, CA 94403             (650)572-2607
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <a74133ae-7e23-439c-9ec9-d11d2abba7b9@a12g2000yqm.googlegroups.com>
On 26 Mar, 15:12, Larry Coleman <············@yahoo.com> wrote:
> For the record, I'm not actually part of the lisp crowd. I mainly lurk
> here because the flame wars are much more interesting (and frequent)
> than the ones on comp.lang.haskell.

Ha! Ha! Ha! I agree. Lispers are smart and funny people. Why outsiders
say c.l.l. is unfriendly?

I especially love when they make both funny and useful/insightful
remarks, as when Pascal B. posted a sketch of a NEW-DOG-COMMON-LISP
^_^
From: Kenneth Tilton
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <49cb7af0$0$27768$607ed4bc@cv.net>
Tamas K Papp wrote:
> On Thu, 26 Mar 2009 04:53:59 -0700, Elena wrote:
> 
>> On Mar 26, 11:33 am, Tamas K Papp <······@gmail.com> wrote:
>>> But why would I want to emulate smart pointers?  CL already has garbage
>>> collection, bounds checking, etc.  If I reimplemented these things
>>> using macros, then even Lisp programmers would smile and say: "Lo! That
>>> idiot is wasting his time instead of writing applications!".
>> Oh yeah, CL is perfect. I know, I know.
> 
> Whether CL is perfect is not relevant here.  I just pointed out that
> it already has the features that smart pointers provide, so emulating
> them in CL is quite pointless (except as an intellectual exercise).
> 
>> I'm not representative of the C++ programmer crowd at all, guaranteed.
> 
> I think that you are.  This is not the first time in this thread where
> you claim that you are special, I have not seen any evidence to
> support that.  It appears that thinking that you are an outlier makes
> you feel better, but please realize that it does not impress people.
> 
>> Pointless thread? Random stuff? We'll see. If I realize that the prize
>> is worth the trouble... I'm still thinking about it.
> 
> Yeah, whatever.  If you had spent 50% of the time you devoted to
> writing to CLL on learning Lisp, you could have made a decision
> already.  Clearly you don't want to do it, and exploring the reasons
> behind this is up to you and your therapist.

I just hope he has one. This has to be one of the more bizarrely 
elaborate trolls we have seen, which is fun for us but not so much a 
good sign for his mental health.

kt
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <0d8123c4-5807-41dd-a3d4-4e609d51159e@b16g2000yqb.googlegroups.com>
On 26 Mar, 13:54, Kenneth Tilton <·········@gmail.com> wrote:
> I just hope he has one. This has to be one of the more bizarrely
> elaborate trolls we have seen, which is fun for us but not so much a
> good sign for his mental health.

You right, my friend. I'd like to be different. I'd like so much :-(
From: Björn Lindberg
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <9mpfxh0v2qh.fsf@muvclx01.cadence.com>
Elena <········@gmail.com> writes:

> [Smart pointers are great]

> Nope, "with-open-THING" doesn't cut it (what if you forget using
> it?).

What if you forget to use your smart pointer?


Bj�rn Lindberg
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <67168d14-80e6-48c1-b00b-b85fc81cac16@w34g2000yqm.googlegroups.com>
On 26 Mar, 14:21, ·····@runa.se (Björn Lindberg) wrote:
> Elena <········@gmail.com> writes:
> > [Smart pointers are great]
> > Nope, "with-open-THING" doesn't cut it (what if you forget using
> > it?).
>
> What if you forget to use your smart pointer?
>
> Björn Lindberg

You grep your project folder for the '*' character. Results which are
not about multiplications are lines to fix. It's a shell one liner,
isn't it? What about CL?

BTW, I never forgot to use smart pointers and RAII, and indeed my
programs have never leaked one byte of memory as far as I can remember
(not counting a VC++  library bug which was as likely as a garbage
collector bug). Why? Because there tons of books talking about them,
and readily libraries implementing them. You know you are going to
leak resources if you don't manage them "smartly". However, that's a
modern C++ best practice. Where are modern CL best practices books?
From: Thomas A. Russ
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <ymi4oxgj6kq.fsf@blackcat.isi.edu>
Elena <········@gmail.com> writes:

> On 26 Mar, 14:21, ·····@runa.se (Bj��rn Lindberg) wrote:
> > Elena <········@gmail.com> writes:
> > > [Smart pointers are great]
> > > Nope, "with-open-THING" doesn't cut it (what if you forget using
> > > it?).
> >
> > What if you forget to use your smart pointer?
> >
> > Bj��rn Lindberg
> 
> You grep your project folder for the '*' character. Results which are
> not about multiplications are lines to fix. It's a shell one liner,
> isn't it? What about CL?

Grep for "(open\b"

> BTW, I never forgot to use smart pointers and RAII,

So I guess forgetting "with-open-THING" isn't something that would
happen to you either?  Or is it the case that you would only forget lisp
best practices, but not C++ ones.


-- 
Thomas A. Russ,  USC/Information Sciences Institute
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <818d4e7b-c2b2-4382-8c68-f689b021dc7b@c11g2000yqj.googlegroups.com>
On 26 Mar, 22:51, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Elena <········@gmail.com> writes:
> > On 26 Mar, 14:21, ·····@runa.se (BjŽörn Lindberg) wrote:
> > > Elena <········@gmail.com> writes:
> > > > [Smart pointers are great]
> > > > Nope, "with-open-THING" doesn't cut it (what if you forget using
> > > > it?).
>
> > > What if you forget to use your smart pointer?
>
> > > BjŽörn Lindberg
>
> > You grep your project folder for the '*' character. Results which are
> > not about multiplications are lines to fix. It's a shell one liner,
> > isn't it? What about CL?
>
> Grep for "(open\b"

Are resource allocation related functions always called "open"? I
didn't know that. That would be an useful convention.

Anyway, "with-open-THING" handle only local cases, just like simpler
smart pointers. What about shared resources? Yes, you can employ a
shared resource smart pointer. Yes, you can avoid circular references
too.

>
> > BTW, I never forgot to use smart pointers and RAII,
>
> So I guess forgetting "with-open-THING" isn't something that would
> happen to you either?  Or is it the case that you would only forget lisp
> best practices, but not C++ ones.

Well, if as I stated earlier all resource management macros are called
"with-open-THING", I wouldn't forget to use them.
From: gugamilare
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <8d2c4820-5328-4853-9599-efc035afc446@b16g2000yqb.googlegroups.com>
On 26 mar, 14:23, Elena <········@gmail.com> wrote:
> On 26 Mar, 14:21, ·····@runa.se (Björn Lindberg) wrote:
>
> > Elena <········@gmail.com> writes:
> > > [Smart pointers are great]
> > > Nope, "with-open-THING" doesn't cut it (what if you forget using
> > > it?).
>
> > What if you forget to use your smart pointer?
>
> > Björn Lindberg
>
> You grep your project folder for the '*' character. Results which are
> not about multiplications are lines to fix. It's a shell one liner,
> isn't it? What about CL?
>
> BTW, I never forgot to use smart pointers and RAII, and indeed my
> programs have never leaked one byte of memory as far as I can remember
> (not counting a VC++  library bug which was as likely as a garbage
> collector bug). Why? Because there tons of books talking about them,
> and readily libraries implementing them. You know you are going to
> leak resources if you don't manage them "smartly". However, that's a
> modern C++ best practice. Where are modern CL best practices books?

Well, CL is safe, so I think you want program hints rather than good
practices. Try "ANSI Common Lisp" and "On Lisp", from Paul Graham,
both very good books. Oh, yes, off course, after you read Practical
Common Lisp ( http://www.gigamonkeys.com/book/ ) if you didn't already.
From: Björn Lindberg
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <9mp8wmrthv9.fsf@muvclx01.cadence.com>
Elena <········@gmail.com> writes:

> On 26 Mar, 14:21, ·····@runa.se (Bj�rn Lindberg) wrote:
>> Elena <········@gmail.com> writes:
>> > [Smart pointers are great]
>> > Nope, "with-open-THING" doesn't cut it (what if you forget using
>> > it?).
>>
>> What if you forget to use your smart pointer?
>>
>> Bj�rn Lindberg
>
> You grep your project folder for the '*' character.

No, you do not understand. You forgot to use smart pointers. You
therefore did not think to grep your project folder. You have a
resource leak.

> BTW, I never forgot to use smart pointers and RAII, and indeed my
> programs have never leaked one byte of memory as far as I can remember

Then I bet you won't forget to use with-open-file instead of
opoen/close in CL either, if you would ever get around to writing
programs in it.


Bj�rn Lindberg
From: Matthias Buelow
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <731l05Fsn23mU1@mid.dfncis.de>
Elena <········@gmail.com> wrote:

>with RAII idiom, here is where C++ is unique and shines above every

RAII is naive even on paper...
In "Real Life" code, it simply doesn't exist.

Unless you completely plan your whole app beforehand and after
implementation, never touch it again. Or you have infinite time for
redesigning.
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <0f1e0d4d-ccd7-4dd6-9f69-2461bcbbd403@o36g2000yqh.googlegroups.com>
On 26 Mar, 16:23, Matthias Buelow <····@incubus.de> wrote:
> Elena <········@gmail.com> wrote:
> >with RAII idiom, here is where C++ is unique and shines above every
>
> RAII is naive even on paper...
> In "Real Life" code, it simply doesn't exist.

Hmmm... My C++ applications have never been "real life", then. I never
realized that. Maybe I happen to live in a Matrix. Thank you for
awakening me ;-)

>
> Unless you completely plan your whole app beforehand and after
> implementation, never touch it again. Or you have infinite time for
> redesigning.

This shows you are not a C++er. Never heard about "typedef"? Well,
just "typedef" your pointer types and when your resources managing
policy changes update the definition. Of course you'll have to update
some places, but you know, real life sometimes sucks. GC is not silver
bullet.

BTW, don't rush to learn C++, that would not be worth the trouble.
Been there, done that. Bye bye C++, hello... still thinking about it.


Cheers
From: Thomas A. Russ
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <ymi8wmsj6oe.fsf@blackcat.isi.edu>
Elena <········@gmail.com> writes:

> This shows you are not a C++er. Never heard about "typedef"? Well,
> just "typedef" your pointer types and when your resources managing
> policy changes update the definition. Of course you'll have to update
> some places, but you know, real life sometimes sucks. GC is not silver
> bullet.

It is for memory management problems.

I wonder why the Java designers decided that GC was superior to manual
memory management and even smart pointers?

-- 
Thomas A. Russ,  USC/Information Sciences Institute
From: Marco Antoniotti
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <528abb4c-7c58-4ef3-b195-b1583ec15397@r15g2000vbi.googlegroups.com>
On Mar 26, 10:49 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Elena <········@gmail.com> writes:
> > This shows you are not a C++er. Never heard about "typedef"? Well,
> > just "typedef" your pointer types and when your resources managing
> > policy changes update the definition. Of course you'll have to update
> > some places, but you know, real life sometimes sucks. GC is not silver
> > bullet.
>
> It is for memory management problems.
>
> I wonder why the Java designers decided that GC was superior to manual
> memory management and even smart pointers?
>

What was the saying?  "C programmers think that memory management is
too important to be left to the program; Lisp programmers think that
memory management is too important to leave it to the
programmer" (This is in Stroustroup's book).

Cheers
--
Marco
From: gugamilare
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <e60b2a87-99ff-46f9-8a86-5f1be85d68d1@j8g2000yql.googlegroups.com>
On 26 mar, 19:20, Marco Antoniotti <·······@gmail.com> wrote:
> On Mar 26, 10:49 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
> > It is for memory management problems.
>
> > I wonder why the Java designers decided that GC was superior to manual
> > memory management and even smart pointers?
>
> What was the saying?  "C programmers think that memory management is
> too important to be left to the program; Lisp programmers think that
> memory management is too important to leave it to the
> programmer" (This is in Stroustroup's book).
>
> Cheers
> --
> Marco

Agreed. For instance, it is faster for a GC to collect many small
objects than for the programmer manually collect each one of them
separated. And I believe this is rather general.

I read somewhere, don't ask me where, that two libraries that
implements genetic algorithm, one in CL, the other in C. C library was
faster... at first at least. But, comparing performances through time,
CL remained at the same constant speed, while C performance dropped
and become very slower than CL. Guess what: C doesn't have garbage
collection, so the memory it uses has an increasing number of "memory
holes", which is a BAD thing.

A program written in C without GC is known to lose up to 50% of the
performance through time if it generates too much garbage.
From: Elena
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <b8c69fb7-4e31-47a1-9d3b-f2c0b326ae8e@v19g2000yqn.googlegroups.com>
On 26 Mar, 22:49, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Elena <········@gmail.com> writes:
> > This shows you are not a C++er. Never heard about "typedef"? Well,
> > just "typedef" your pointer types and when your resources managing
> > policy changes update the definition. Of course you'll have to update
> > some places, but you know, real life sometimes sucks. GC is not silver
> > bullet.
>
> It is for memory management problems.

Exactly. Smart pointers are about resource management problems
instead. Memory is just one of the resources you have to handle in a
program. Here is the C++ trade off: you manage just the memory and the
language will manage every other resource in a way you can control and
fine tune. Here is the GCed languages trade off: you manage every
resource but the memory.

> I wonder why the Java designers decided that GC was superior to manual
> memory management and even smart pointers?

I think that Java was designed for the (replaceable) average
(corporate) programmer. Having an averagely skilled programmer manage
memory is a recipe for disaster indeed. And maybe overkill.
Furthermore, having manual or semi-automatic memory management in
applets does make for security holes. Badly memory managed programs
crash and burn. Badly resource managed programs just fail. Indeed
there is a deal.

I do agree that GC is very useful: if you run out of memory then
you're doomed. But it's not silver bullet. If I'd have to choose among
the manual apprach, smart pointers and GC, for a general purpose use,
I'd leave out the manual approach in a blink.

I do also agree that RAII is difficult, but it serves its purpose.
Maybe a RAII + GC approach would be the best deal.
From: Matthias Buelow
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <73464bFt5khnU2@mid.dfncis.de>
Elena <········@gmail.com> wrote:

>Hmmm... My C++ applications have never been "real life", then. I never
>realized that. Maybe I happen to live in a Matrix. Thank you for
>awakening me ;-)

Maybe you have never had to work on other people's software (who might
never have heard the term 'RAII', something which is quite likely,
actually.)

>> Unless you completely plan your whole app beforehand and after
>> implementation, never touch it again. Or you have infinite time for
>> redesigning.
>This shows you are not a C++er. Never heard about "typedef"? Well,

Ah, the mighty typedef! Resolving all (re-)design problems in one go.
Now, you really should tell those "software engineering" folks about
that. 

>BTW, don't rush to learn C++, that would not be worth the trouble.

Generally, I would agree (although I'm getting paid for programming in
C++.)

Sorry for the OT crap.
From: eric-and-jane-smith
Subject: Re: Common Lisp's fixable issues?
Date: 
Message-ID: <twNyl.103447$Rg3.7207@newsfe17.iad>
Elena <········@gmail.com> wrote in news:2d451024-19d8-4a74-ae40-
············@h5g2000yqh.googlegroups.com:

> ...   Nope, "with-open-THING" doesn't cut it (what if
> you forget using it?).  ...

Spending your time writing applications doesn't cut it either.  What if you 
forget to write them?