Common Lisp's fixable issues?
Elena
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
Elena
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
Alessio Stalla
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
Kenneth Tilton
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
Kenneth Tilton
Don't use lists for everything. Everything else is fine.
> and if they have developed some workarounds.
defstruct and defclass
kt
Javier
> 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?
Kenneth Tilton
An obsession is born.
eric-and-jane-smith
07fb56...@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.
Javier
No, I asked because you are like a teenager, but without the "like".
eric-and-jane-smith
>>> 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?
Javier
And he is probably the oldest teenager in the planet.
> Have you ever done any?
Yes.
André Thieme
You can see Kenny Tilton here:
http://video.google.com/videoplay?docid=-1331906677993764413
André
--
Vend
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
Javier
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.
Patrick May
> 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)
John Thingstad
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
Javier
> 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).
Patrick May
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,
Javier
> Javier <jav...@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
Elena
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
Pascal Costanza
> 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/
Elena
> 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?
Rob Warnock
+---------------
| skrev Vend <ven...@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 <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Kenneth Tilton
> 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
Raffael Cavallaro
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
Pascal Costanza
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.?
Pillsy
> > 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
Pillsy
> 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
Kenneth Tilton
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.
Alberto Riva
>
> 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
Thomas M. Hermann
> 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 ===
Alberto Riva
I think this should be in the FAQ. Seriously.
Alberto
eric-and-jane-smith
727ef7...@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.
Kenneth Tilton
Mr-T?
We'll need modern mode to do it right.
hth,k
Marco Antoniotti
Exactly it took me *months* to figure out that Ruby 'inject' is
nothing else that 'fold' or 'reduce' in disguise. :{
Cheers
--
Marco
Marco Antoniotti
> eric-and-jane-smith wrote:
> > Pillsy <pillsb...@gmail.com> wrote in news:a4246f91-74d2-47e2-b956-
> > 727ef7a67...@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
Nicolas Neuss
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
Kenneth Tilton
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
Marco Antoniotti
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
Pascal J. Bourguignon
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__
Casper H.S. Dik
>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.
Kenneth Tilton
Can we ream them over if* again while we are at it?
kxo
nick_keigh...@hotmail.com
<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>
Marco Antoniotti
Don't give you-know-who ideas :)
Cheers
--
Marco
Marco Antoniotti
> On 23 Mar, 00:12, Elena <egarr...@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
TomSW
> p...@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
Pascal J. Bourguignon
However, and is _standard_ (#include <iso646.h>) so you can use it
even on project where your own #define are frowned upon. ;-)
--
__Pascal Bourguignon__
Matthias Buelow
> 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.
Raffael Cavallaro
>
> 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!
Thomas F. Burdick
> 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.
Javier
> 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....
Pascal Costanza
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/
Javier
> 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?
Marcus Breiing
> 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.
Javier
> 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?
j...@crispylogics.com
> André Thieme escribió:
>
>
>
>
>
> > Javier schrieb:
> >> eric-and-jane-smith escribió:
> >>> Javier <javu...@gmail.com> wrote innews:gq5ucb$sg4$1...@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
j...@crispylogics.com
> On 23 Mar, 01:23, Pascal Costanza <p...@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.~36r~)" 870180 1680085828711918828
16438) http://www.crispylogics.com
Tobias C. Rittweiler
> ;; 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.
Tobias C. Rittweiler
> 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.
Tobias C. Rittweiler
> 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.
Kenneth Tilton
> Pillsy <pill...@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.
Thomas A. Russ
> 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
Elena
> On 23 Mar, 00:12, Elena <egarr...@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 :-(
j...@crispylogics.com
wrote:
It doesn't sound silly when pronounced ;-)
Elena
> Elena wrote:
> > Therefore, in my path to learning Lisp I'm going to:
> > - using ! as a suffix to recognize destructive operations (Scheme);
>
> 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.
Elena
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*"? ^_^
Kenneth Tilton
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.
Elena
wrote:
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?" :-)))))
Marco Antoniotti
> On 23 Mar, 12:09, Marco Antoniotti <marc...@gmail.com> wrote:
>
> > On Mar 23, 11:22 am, Kenneth Tilton <kentil...@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
Elena
Heck!
Still adamant that Common Lisp hasn't any issue?
Kenneth Tilton
<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?!
Elena
> 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...
Kaz Kylheku
> 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
> package which renamed destructive procedures in a consistent way (e.g.
> "CONC!", "PUSH!", etc).
>
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.
Elena
> 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
^_^
Thomas F. Burdick
> 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.)
Wade
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
Raffael Cavallaro
> Would you like to kiss my ass or something like that?
spoken like a true troll.
Raffael Cavallaro
> Yes; these issues are in fact ``issues''.
>
> I.e. psychological problems to be taken up with your therapist.
[much wisdom snipped]
exactly.
Elena
> 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
Elena
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.
Kenneth Tilton
Wait. You're still coming to the annual dataflow conference in monte
carlo, yes? How is c4 coming?
kt
Kenneth Tilton
> On 23 Mar, 22:15, Kenneth Tilton <kentil...@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.
Raffael Cavallaro
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
Elena
> 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
Rob Warnock
+---------------
| 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 <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Elena
wrote:
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
Kenneth Tilton
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.
Raffael Cavallaro
[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)
.
Marco Antoniotti
Never said it hasn't. I repeat. Have you tried to look at
pathnames? :)
Cheers
--
Marco
Rob Warnock
+---------------
| Kenneth Tilton <kentil...@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.
...
Marcus Breiing
> 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.
Thomas F. Burdick
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
Thomas F. Burdick
wrote:
> "Thomas F. Burdick" <tburd...@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 :-)
Kenneth Tilton
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
Alessio Stalla
> On 23 Mar, 02:57, Kenneth Tilton <kentil...@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.
gugamilare
What? You are using push as if it were cons? That is not good.
Thomas F. Burdick
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.
Kenneth Tilton
> 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
Javier
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?"
nick_keigh...@hotmail.com
<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>