>From the Revenge of the Nerds http://www.paulgraham.com/icad.html
"Python copies even features that many Lisp hackers consider to be
mistakes."
What are they?
Alok
Alok <···········@gmail.com> wrote:
>>From the Revenge of the Nerds http://www.paulgraham.com/icad.html
>
> "Python copies even features that many Lisp hackers consider to be
> mistakes."
>
> What are they?
Why ask us? This is comp.lang.lisp, not comp.lang.python
Do you expect everone to know Python?
Stefan Scholl <······@no-spoon.de> writes:
>>
>> "Python copies even features that many Lisp hackers consider to be
>> mistakes."
>>
>> What are they?
>
> Why ask us? This is comp.lang.lisp, not comp.lang.python
I expect that he's wondering which features in Lisp are generally
considered mistakes. The only one which really leaps to mind is that
argument order isn't exactly the sanest thing out there (NTH/AREF and so
forth). But I'm not really a Lisp hacker--just a programmer.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Marmite is a black tarry yeast extract used to encourage New Zealand children
to grow large and strong. The usual method is to feed it to them on toast,
resulting in them growing very quickly, so that they might become big and
strong enough to stop their parents from doing this. --Rupert Boleyn
Stefan Scholl wrote:
> Alok <···········@gmail.com> wrote:
> >>From the Revenge of the Nerds http://www.paulgraham.com/icad.html
> >
> > "Python copies even features that many Lisp hackers consider to be
> > mistakes."
> >
> > What are they?
>
> Why ask us? This is comp.lang.lisp, not comp.lang.python
>
> Do you expect everone to know Python?
No, but I was hoping for responses about features that Lisp hackers
consider to be mistakes.
Besides I know of <a href="http://www.norvig.com"> atleast one Lisp
hacker </a> who now <a
href="http://sztywny.titaniumhosting.com/2006/07/23/stiff-asks-great-programmers-answers/">
likes Python before Lisp </a>. But don't think <a
href="http://groups.google.com/groups/search?enc_author=GVwrTBAAAACxLilPA0Tt4NN3FgHHUrjv&scoring=d"
> he has much time to read or, write to, cll </a>.
Alok
On Thu, 07 Sep 2006 14:08:59 -0700, Alok wrote:
<snip>
What's with the HTML? Usenet is plain text.
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Chris Barts wrote:
> On Thu, 07 Sep 2006 14:08:59 -0700, Alok wrote:
>
> <snip>
>
> What's with the HTML? Usenet is plain text.
>
Well, I wanted to associate words or phrases with URLs and used HTML to
do it. Also, I guessed that some Usenet readers (
http://www.microsoft.com/outlook ) can link embedded HTML tagged
content.
Alok
Alok wrote:
> No, but I was hoping for responses about features that Lisp hackers
> consider to be mistakes.
I'm not a real Lisp hacker, but here's a few of my favorites:
Mistake 1:
(eq 'x 'X)
returns t
I like the mathematical convention "for x in X, ...".
Mistake 2:
(let ((t 1))
(operation))
causes an error
The local t should mask the global constant inside the let statement;
calls inside the let to functions defined outside the let should revert
to using the global constant.
Mistake 2b:
(setq car 3) will result in (eql car 3) in all (useful) packages.
Vehicles are a common part of daily life.
Mistake 2c:
(defmethod + ((a (eql 'hi)) (b (eql 'bye)))
(format t "Hello, goodbye."))
causes an error
This makes operator extensions (say for vectors and matrices) awkward.
Mistake 3:
Not standardizing any new features (e.g. POSIX support) in many years.
Mistake 4:
Not providing a simple, standard interface for direct memory
manipulation, thus giving C a foothold that Lisp simply doesn't satisfy.
Mistake 4b:
Not standardizing a subset of the language (e.g. no macros, minimal
garbage collection) for use on small/embedded devices. A host
environment could precompile macros and such for use on this reduced subset.
Whether any of these made it into Python, I don't know -- its been too
many years since I toyed with it -- I'm not a syntactical indentation
kind of guy. Whitespace is for my visual enjoyment, not something to be
dictated by a dumb compiler.
- Daniel
D Herring <········@at.tentpost.dot.com> writes:
>
> I'm not a real Lisp hacker, but here's a few of my favorites:
>
> Mistake 1:
> (eq 'x 'X)
> returns t
> I like the mathematical convention "for x in X, ...".
OTOH, without the case-folding Lisp would be unusable today. Can you
imagine having to write:
(DEFUN foo (x y)
(IF x
y
NIL))
Ugh!
--
Robert Uhl <http://public.xdi.org/=ruhl>
For 93 million miles, there is nothing between the sun and my shadow
except me. I'm always getting in the way of something...
Robert Uhl wrote:
> D Herring <········@at.tentpost.dot.com> writes:
>> I'm not a real Lisp hacker, but here's a few of my favorites:
>>
>> Mistake 1:
>> (eq 'x 'X)
>> returns t
>> I like the mathematical convention "for x in X, ...".
>
> OTOH, without the case-folding Lisp would be unusable today. Can you
> imagine having to write:
>
> (DEFUN foo (x y)
> (IF x
> y
> NIL))
>
> Ugh!
Simple solution; change all the keywords in common-lisp-user to be
lowercase. Require people to fix old code which doesn't respect case
sensitivity. I wasn't born when this mistake was made; we should fix
this for future generations.
- Daniel
> * Robert Uhl <·········@ABFCNZtznvy.pbz> [2006-09-07 21:38:24 -0600]:
>
> D Herring <········@at.tentpost.dot.com> writes:
>>
>> I'm not a real Lisp hacker, but here's a few of my favorites:
>>
>> Mistake 1:
>> (eq 'x 'X)
>> returns t
>> I like the mathematical convention "for x in X, ...".
>
> OTOH, without the case-folding Lisp would be unusable today. Can you
> imagine having to write:
>
> (DEFUN foo (x y)
> (IF x
> y
> NIL))
$ clisp -q -norc -modern
[1]> (eq 'x 'X)
nil
[2]> (defun foo (x y)
(if x
y
nil))
foo
[3]> (foo 1 2)
2
[4]>
http://clisp.cons.org/impnotes/package-case.html
http://clisp.cons.org/impnotes/clisp.html#opt-modern
--
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://dhimmi.com http://palestinefacts.org http://pmw.org.il
http://memri.org http://openvotingconsortium.org http://ffii.org
Heredity, n: the reason your children are bright.
Robert Uhl <·········@NOSPAMgmail.com> writes:
> D Herring <········@at.tentpost.dot.com> writes:
>>
>> I'm not a real Lisp hacker, but here's a few of my favorites:
>>
>> Mistake 1:
>> (eq 'x 'X)
>> returns t
>> I like the mathematical convention "for x in X, ...".
>
> OTOH, without the case-folding Lisp would be unusable today. Can you
> imagine having to write:
>
> (DEFUN foo (x y)
> (IF x
> y
> NIL))
>
> Ugh!
>
I can imagine having to write this:
(defun foo (x y)
(if x
y
nil))
so, what's the point ?
--
Thomas Samson
<cshields> wow, I feel welcome
<klieber> oh, sorry about that.
Robert Uhl <·········@NOSPAMgmail.com> writes:
> D Herring <········@at.tentpost.dot.com> writes:
>>
>> I'm not a real Lisp hacker, but here's a few of my favorites:
>>
>> Mistake 1:
>> (eq 'x 'X)
>> returns t
>> I like the mathematical convention "for x in X, ...".
>
> OTOH, without the case-folding Lisp would be unusable today. Can you
> imagine having to write:
>
> (DEFUN foo (x y)
> (IF x
> y
> NIL))
Just capslock and write:
(DEFUN FOO (X Y)
(IF X
Y
NIL))
;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This machine is a piece of GAGH! I need dual Opteron 850
processors if I am to do battle with this code!"
> * D Herring <········@ng.gragcbfg.qbg.pbz> [2006-09-07 22:28:18 -0500]:
>
> Alok wrote:
>> No, but I was hoping for responses about features that Lisp hackers
>> consider to be mistakes.
>
> I'm not a real Lisp hacker, but here's a few of my favorites:
>
> Mistake 1:
> (eq 'x 'X)
> returns t
> I like the mathematical convention "for x in X, ...".
http://clisp.cons.org/impnotes/clisp.html#opt-modern
http://clisp.cons.org/impnotes/package-case.html
> Mistake 2:
> (let ((t 1))
> (operation))
> causes an error
> The local t should mask the global constant inside the let statement;
> calls inside the let to functions defined outside the let should revert
> to using the global constant.
nope, this is not an error.
binding constants is wrong - they are not variables.
> Mistake 2b:
> (setq car 3) will result in (eql car 3) in all (useful) packages.
> Vehicles are a common part of daily life.
this actually works.
what is the error?
> Mistake 2c:
> (defmethod + ((a (eql 'hi)) (b (eql 'bye)))
> (format t "Hello, goodbye."))
> causes an error
> This makes operator extensions (say for vectors and matrices) awkward.
this is a performance optimization: if + were a generic function,
compilers would not be able to inline it, i.e., compile (+ 1 2) into a
single assembly instruction.
> Mistake 3:
> Not standardizing any new features (e.g. POSIX support) in many years.
as have been said here over and over - standardization is an expensive
process.
most implementation provide an interface to POSIX functions
(e.g., http://clisp.cons.org/impnotes/syscalls.html) -
pick the one you like and stick with it.
> Mistake 4:
> Not providing a simple, standard interface for direct memory
> manipulation, thus giving C a foothold that Lisp simply doesn't satisfy.
again, some implementations may offer that.
> Mistake 4b:
> Not standardizing a subset of the language (e.g. no macros, minimal
> garbage collection) for use on small/embedded devices. A host
> environment could precompile macros and such for use on this reduced
> subset.
again, some implementations may offer tree shaking &c.
I think you are confusing "standard" with "implementation".
most other languages offer a single implementation which defines the
language. CL is provided by half a dozen vendors (commercial and FLOSS)
who offer different extensions - in addition to the standard core.
I suggest that you decide what you want to do (e.g., "GUI game
development for windows" or "web applications") and then chose the
implementation that matches your needs and stick with it.
(if you want to worry about portability proactively, you may want to
keep platform-dependent code separate and look for portable extensions).
--
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://israelunderattack.slide.com http://openvotingconsortium.org
http://mideasttruth.com http://memri.org http://pmw.org.il http://camera.org
.sigs are like your face - rarely seen by you and uglier than you think
Sam Steingold <···@podval.org> writes:
>> Mistake 2c:
>> (defmethod + ((a (eql 'hi)) (b (eql 'bye)))
>> (format t "Hello, goodbye."))
>> causes an error
>> This makes operator extensions (say for vectors and matrices) awkward.
>
> this is a performance optimization: if + were a generic function,
> compilers would not be able to inline it, i.e., compile (+ 1 2) into a
> single assembly instruction.
In order for a compiler to translate (+ 1 2) into a single assembly
instruction much has to be inferred from the enclosing environment to
ensure that the translation is safe and correct. If + was defined as
a generic function nothing would preclude the compiler from performing
the same analysis and making the same translation. In fact, since the
+ operator is exported from the COMMON-LISP package, implementing this
specialization is a more constrained problem than specializing the at
call-sites of user-defined generic functions.
At any rate, the + function is inherently generic. Making it a
generic function in the CLOS sense would be more costly to users than
to CPUs.
Sam Steingold <···@podval.org> writes:
>> The local t should mask the global constant inside the let statement;
>> calls inside the let to functions defined outside the let should revert
>> to using the global constant.
>
> nope, this is not an error.
> binding constants is wrong - they are not variables.
I disagree with Lisp notion of constness (and specialness etc.)
being the property of a symbol instead of a variable.
Creating a local variable should not take into account any outer
meaning of that symbol.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> Sam Steingold <···@podval.org> writes:
>
>>> The local t should mask the global constant inside the let statement;
>>> calls inside the let to functions defined outside the let should revert
>>> to using the global constant.
>> nope, this is not an error.
>> binding constants is wrong - they are not variables.
>
> I disagree with Lisp notion of constness (and specialness etc.)
> being the property of a symbol instead of a variable.
>
> Creating a local variable should not take into account any outer
> meaning of that symbol.
That's true, but this is actually extremely easy to fix.
(defmacro define-constant (name value)
(let ((internal-name (copy-symbol name)))
`(progn
(defconstant ,internal-name ,value)
(define-symbol-macro ,name ,internal-name))))
Symbol macros can be locally shadowed. (Symbol macros are probably one
of the most underrated features of Common Lisp.)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Fri, 08 Sep 2006 22:55:09 +0200, Pascal Costanza wrote:
> (Symbol macros are probably one of the most underrated features of
> Common Lisp.)
And yet they're one of the only uses for (the things called) macros in
non-Lisp languages.
Of course, they're implemented so badly (cpp is a kludgy hack, and nobody
seems to have anything else that's better) they besmirch the name 'macro'
to programmers in general. Even Perl programmers, who have the ability to
do similar things to what Lisp macros provide via BEGIN blocks [1], avoid
the term.
(This is set to change in Perl 6, which will apparently have Lisp-like
macros that may return either text strings to be parsed or ASTs[2].)
[1] Look at Lingua::Romana::Perligata
<http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html> for an
amusing example of how far this can be carried.
[2] <http://dev.perl.org/perl6/doc/design/syn/S06.html>
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Pascal Costanza <··@p-cos.net> wrote:
+---------------
| (defmacro define-constant (name value)
| (let ((internal-name (copy-symbol name)))
| `(progn
| (defconstant ,internal-name ,value)
| (define-symbol-macro ,name ,internal-name))))
+---------------
One of the things I like about this group is that you always learn
something new, in this case a non-trivial use for COPY-SYMBOL
[instead of GENSYM]. I've been using the following rather clunky
macro for some time -- mainly in the REPL -- to define "global
lexical variables":
(defmacro deflex (var val &optional (doc nil docp))
(let* ((s0 (symbol-name '#:*storage-for-deflex-var-))
(s1 (symbol-name var))
(s2 (symbol-name '#:*))
(s3 (symbol-package var))
(shadow-var (intern (concatenate 'string s0 s1 s2) s3)))
`(progn
(defparameter ,shadow-var ,val ,doc)
,@(when docp (list `(setf (documentation ',var 'variable) ,doc)))
(define-symbol-macro ,var ,shadow-var))))
But that whole *STORAGE-FOR-DEFLEX-VAR-${whatever}* hack was only
there for debugging, to make MACROEXPAND, error messages, and
the like print something useful instead of some random gensym.
I think the following -- modelled on your DEFINE-CONSTANT -- does
the job just as well but is much cleaner:
(defmacro deflex (var val &optional (doc nil docp))
(let* ((shadow-var (copy-symbol var)))
`(progn
(defparameter ,shadow-var ,val ,doc)
,@(when docp (list `(setf (documentation ',var 'variable) ,doc)))
(define-symbol-macro ,var ,shadow-var))))
Used like so:
> (deflex foo 13 "A sample global lexical")
FOO
> (defun foo () foo)
FOO
> (let ((foo 57))
(list foo (foo)))
(57 13)
> (describe 'foo)
FOO is an internal symbol in the COMMON-LISP-USER package.
It is a symbol macro with expansion: #:FOO.
Macro documentation:
A sample global lexical
> (describe (macroexpand 'foo))
FOO is an uninterned symbol.
It is a special variable; its value is 13.
Special documentation:
A sample global lexical
>
-Rob
p.s. Originally I had only DEFLEX, defined as above using
DEFPARAMETER to (re)bind the shadow variable every time the
DEFLEX is executed [as when a file is reLOADed], like Scheme's
top-level DEFINE, but I found that I also occasionally needed
a version that provided DEFVAR behavior rather than DEFPARAMETER,
so I called it DEFLEXVAR. I'm now wondering if I got it backwards,
that instead it's DEFLEX that should have DEFVAR behavior, and
(say) DEFLEXICAL should have DEFPARAMETER behavior. Opinions?
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
D Herring <········@at.tentpost.dot.com> writes:
> Mistake 2c:
> (defmethod + ((a (eql 'hi)) (b (eql 'bye)))
> (format t "Hello, goodbye."))
> causes an error
> This makes operator extensions (say for vectors and matrices) awkward.
This may seem attractive for very experimental programming, but many
would agree that those are the very situations where the development
time cost of shadowing + and the runtime cost of generic function
dispatch is negligible and the method you have offered would not be
considered prohibitive.
I have often found operator overloading to be an unfortunate annoyance
for linear algebra: the methods I would like to invoke depend more on
the shape of the arguments than on their gross type. After one has
gone to the trouble of creating specialized types to reflect machine
idioms or specialized algorithms at the class level, all of the
mathematics becomes hidden under a dense layer of code. Yuck.
Carl Shapiro wrote:
> D Herring <········@at.tentpost.dot.com> writes:
>
> > Mistake 2c:
> > (defmethod + ((a (eql 'hi)) (b (eql 'bye)))
> > (format t "Hello, goodbye."))
> > causes an error
> > This makes operator extensions (say for vectors and matrices) awkward.
>
> This may seem attractive for very experimental programming, but many
> would agree that those are the very situations where the development
> time cost of shadowing + and the runtime cost of generic function
> dispatch is negligible and the method you have offered would not be
> considered prohibitive.
>
> I have often found operator overloading to be an unfortunate annoyance
> for linear algebra: the methods I would like to invoke depend more on
> the shape of the arguments than on their gross type. After one has
> gone to the trouble of creating specialized types to reflect machine
> idioms or specialized algorithms at the class level, all of the
> mathematics becomes hidden under a dense layer of code. Yuck.
There is no operator in Common Lisp, '+ is just a function.
So if you are okay with generic function, then generic '+ function
should be okay too.
It's probably taste issue.
Regarding performance, even with current '+ being normal function, you
still have to do (declare fixnum) to get a really fast code, so I see
no problem of doing the same thing when '+ is generic function to get
the performance.
Regarding CLOS, it seems like Common Lisp doesn't quite eat its own dog
food. Many function that could have been generic, was designed as
multiple macro or function.
WITH-XXX, LOOP or even ITERATE macros. Sometime macro is too easy to
create that it encourage you not to think carefully. You can use macro
to, in some sense, copy paste your code, but if you step back and think
about design, sometimes macro is not needed at all and you can have
easier to read code.
----
I may add Package issue in Common Lisp.
As recently discussed, Common Lisp got the concept of nick name
backward. Nick name of a package should be decided by the user of that
package, not the package itself, otherwise, you will still face package
nick name clash.
The EXPORT mechinism of package deals with symbol, which has no
namespace. This means you cannot have FOO function, FOO class or FOO
slot in the same package and be able to export only one namespace of
them.
----
Too many phase of value.
The concept of compile-time, load-time and run-time is one source of
confusion.
Many bug comes down to forgetting to surround a form with (eval-when
(:compile-toplevel ...)...).
Surely this many evaluation time is more powerful and is useful for
doing many trick. But I doubt it is really needed.
I cannot see the case where you really need a function/class to exists
only at compile time, I mean, in case that it is not acceptable to have
this code floating around at runtime.
Being able to calculate things at compile time is a neat trick but,
with a simple asdf script, I don't think you'll need it that much.
Compare the need to be able to evaluate things at compile time and the
need to have standard ffi/posix interface, I'll probably use the latter
feature more.
Plus It only adds to the degree of difficulty to do thing right. Most
language has the simplified version of only load time. which is easier
to understand.
D Herring wrote:
> Alok wrote:
> > No, but I was hoping for responses about features that Lisp hackers
> > consider to be mistakes.
>
> I'm not a real Lisp hacker, but here's a few of my favorites:
>
<lots of bizarre stuff snipped>
> Mistake 3:
> Not standardizing any new features (e.g. POSIX support) in many years.
>
> Mistake 4:
> Not providing a simple, standard interface for direct memory
> manipulation, thus giving C a foothold that Lisp simply doesn't satisfy.
>
> Mistake 4b:
> Not standardizing a subset of the language (e.g. no macros, minimal
> garbage collection) for use on small/embedded devices. A host
> environment could precompile macros and such for use on this reduced subset.
Couldn't agree with those last three more. Hopefully things will
improve in the future.
D Herring <········@at.tentpost.dot.com> writes:
> Alok wrote:
>> No, but I was hoping for responses about features that Lisp hackers
>> consider to be mistakes.
>
> I'm not a real Lisp hacker, but here's a few of my favorites:
>
> Mistake 1:
> (eq 'x 'X)
> returns t
> I like the mathematical convention "for x in X, ...".
Your mistake! You forgot to put:
(SETF (READTABLE-CASE *READTABLE*) :UPCASE)
in your startup file. Then:
(EQ 'x 'X) --> NIL
> Mistake 2:
> (let ((t 1))
> (operation))
> causes an error
> The local t should mask the global constant inside the let statement;
> calls inside the let to functions defined outside the let should
> revert to using the global constant.
Your mistake! You forgot to put:
(SHADOW 'T)
(DEFPARAMETER T 'CL:T)
in your startup file.
> Mistake 2b:
> (setq car 3) will result in (eql car 3) in all (useful) packages.
> Vehicles are a common part of daily life.
I don't see what's wrong with that, but in any case, it's your mistake!
Just put:
(SHADOW 'CAR)
in your startup file.
> Mistake 2c:
> (defmethod + ((a (eql 'hi)) (b (eql 'bye)))
> (format t "Hello, goodbye."))
> causes an error
> This makes operator extensions (say for vectors and matrices) awkward.
Your mistake!
You forgot to put;
(shadow '+)
(defmethod + ((a t) (b t)) (cl:+ a b))
in your startup file.
> Mistake 3:
> Not standardizing any new features (e.g. POSIX support) in many years.
Your fault! You didn't do anything about it! Just put a couple of
millions on the table, and hire the people to do this standardizing
work!
> Mistake 4:
> Not providing a simple, standard interface for direct memory
> manipulation, thus giving C a foothold that Lisp simply doesn't
> satisfy.
See Mistake 3. Personnaly, I've had got no problem to write
RAW-MEMORY:PEEK-BYTE and RAW-MEORY:POKE-BYTE functions.
> Mistake 4b:
> Not standardizing a subset of the language (e.g. no macros, minimal
> garbage collection) for use on small/embedded devices. A host
> environment could precompile macros and such for use on this reduced
> subset.
Actually, the current standard is specified in such a way that you can
easily make an implementation for small and embedded devices. For
example, the standard doesn't specify a garbage collector. You can
have NO garbage collector on a small and embedded device. Why would
you have a garbage collector anyways when you only have 128 bytes of
RAM? Another point is that about half of the functions are speficied
such as they can be implemented merely doing:
(setf (symbol-function 'delete) (symbol-function 'remove))
...
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This machine is a piece of GAGH! I need dual Opteron 850
processors if I am to do battle with this code!"
Pascal Bourguignon wrote:
> D Herring <········@at.tentpost.dot.com> writes:
> > Alok wrote:
> > Mistake 3:
> > Not standardizing any new features (e.g. POSIX support) in many years.
>
> Your fault! You didn't do anything about it! Just put a couple of
> millions on the table, and hire the people to do this standardizing
> work!
Millions aren't needed. The Scheme community have got along fine
standardizing their language with no great budget just by exchanging
drafts of the spec online.
This is one area where Common Lisp lags. Part of the problem is people
see standardisation as creating something new, which is need not be.
What it really should be is standardising things that have become
commonly used already. Things like FFI fall into this category and
really should be standardized.
The problem is just one of the perception of Lispers though, hopefully
it will change in the future.
Rob Thorpe wrote:
> Pascal Bourguignon wrote:
>> D Herring <········@at.tentpost.dot.com> writes:
>>> Alok wrote:
>
>>> Mistake 3:
>>> Not standardizing any new features (e.g. POSIX support) in many years.
>> Your fault! You didn't do anything about it! Just put a couple of
>> millions on the table, and hire the people to do this standardizing
>> work!
>
> Millions aren't needed. The Scheme community have got along fine
> standardizing their language with no great budget just by exchanging
> drafts of the spec online.
There are probably hidden costs. Scheme has a lot of backing from
academic folks, and they get paid by universities or other funding
sources. It's hard to tell though what this means in terms of how much
money indirectly goes into Scheme standardization.
> This is one area where Common Lisp lags. Part of the problem is people
> see standardisation as creating something new, which is need not be.
> What it really should be is standardising things that have become
> commonly used already. Things like FFI fall into this category and
> really should be standardized.
>
> The problem is just one of the perception of Lispers though, hopefully
> it will change in the future.
I encourage everyone to use http://cdr.eurolisp.org/ as a starting place
for exchanging specifications.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Rob Thorpe wrote:
>> Pascal Bourguignon wrote:
>>> D Herring <········@at.tentpost.dot.com> writes:
>>>> Alok wrote:
>>
>>>> Mistake 3:
>>>> Not standardizing any new features (e.g. POSIX support) in many years.
>>> Your fault! You didn't do anything about it! Just put a couple of
>>> millions on the table, and hire the people to do this standardizing
>>> work!
>>
>> Millions aren't needed. The Scheme community have got along fine
>> standardizing their language with no great budget just by exchanging
>> drafts of the spec online.
>
> There are probably hidden costs. Scheme has a lot of backing from
> academic folks, and they get paid by universities or other funding
> sources. It's hard to tell though what this means in terms of how much
> money indirectly goes into Scheme standardization.
Even more important, Scheme isn't standardized in the same way as Common
Lisp. The Revised Reports and the RFIs have no force outside the
willingness of implementors to follow them (to a greater or lesser
degree). Making an ANSI or ISO standard Scheme would likely also cost
millions.
It comes to mind that having an ANSI standard CL is in some ways a
psychological obstacle to developing de facto or "community" standards
for CL extensions/changes/libraries/etc: no matter how widely adopted
such community standards become (and things like asdf and asdf-install
probably qualify at this point) they will never be perceived as having
the same prestige as something with an ANSI imprimatur.
paul
Paul Wallich wrote:
> Pascal Costanza wrote:
> > Rob Thorpe wrote:
> >> Pascal Bourguignon wrote:
> >>> D Herring <········@at.tentpost.dot.com> writes:
> >>>> Alok wrote:
> >>
> >>>> Mistake 3:
> >>>> Not standardizing any new features (e.g. POSIX support) in many years.
> >>> Your fault! You didn't do anything about it! Just put a couple of
> >>> millions on the table, and hire the people to do this standardizing
> >>> work!
> >>
> >> Millions aren't needed. The Scheme community have got along fine
> >> standardizing their language with no great budget just by exchanging
> >> drafts of the spec online.
> >
> > There are probably hidden costs. Scheme has a lot of backing from
> > academic folks, and they get paid by universities or other funding
> > sources. It's hard to tell though what this means in terms of how much
> > money indirectly goes into Scheme standardization.
>
> Even more important, Scheme isn't standardized in the same way as Common
> Lisp. The Revised Reports and the RFIs have no force outside the
> willingness of implementors to follow them (to a greater or lesser
> degree). Making an ANSI or ISO standard Scheme would likely also cost
> millions.
Maybe, but I doubt it. There is already an IEEE standard for Scheme.
The per-se cost depends on the amount of work already done. Standards
that simply enforce already established practice are easy to deal with,
standards that attempt to create new practices less so. Making a
Scheme standard under a different name would just require minor
document revision.
The additional cost of having a big name backer is different. In the
world of communications that I work in there are organizations falling
over themselves to back standards. This probably isn't the same for
programming.
> It comes to mind that having an ANSI standard CL is in some ways a
> psychological obstacle to developing de facto or "community" standards
> for CL extensions/changes/libraries/etc: no matter how widely adopted
> such community standards become (and things like asdf and asdf-install
> probably qualify at this point) they will never be perceived as having
> the same prestige as something with an ANSI imprimatur.
It depends, Schemers don't like the IEEE standard for scheme, even
though it has the more impressive imprimatur. I don't think it's a big
problem having a standard that isn't backed by a big body, so long as
it's an add-on to the older standard rather than a full replacement.
Rob Thorpe <·············@antenova.com> wrote:
+---------------
| Schemers don't like the IEEE standard for scheme, even
| though it has the more impressive imprimatur.
+---------------
That's because IEEE Standard Scheme is virtually identical to
R4RS Scheme, rubber-stamped by IEEE [and priced up in the sky!!],
whereas almost all current Scheme implementations are based on R5RS.
And that's not even mentioning SRFIs... ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Thorpe <·············@antenova.com> wrote:
> Millions aren't needed. The Scheme community have got along fine
> standardizing their language with no great budget just by exchanging
> drafts of the spec online.
ANSI? ISO? ECMA?
D Herring <········@at.tentpost.dot.com> writes:
> Alok wrote:
> > No, but I was hoping for responses about features that Lisp hackers
> > consider to be mistakes.
>
> I'm not a real Lisp hacker, but here's a few of my favorites:
...
Generally speaking, please learn about readtable casing, shadow,
shadowing import, and packages. Afterward you should realize that
most of your comments are due to your current naivete.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
D Herring <········@at.tentpost.dot.com> writes:
> Mistake 2c:
> (defmethod + ((a (eql 'hi)) (b (eql 'bye)))
> (format t "Hello, goodbye."))
> causes an error
> This makes operator extensions (say for vectors and matrices)
> awkward.
As others have pointed out, this is partly due to performance concerns
(that may or may not be moot with modern computers and compilers), but
also partly due to the fact that Common Lisp systems, unlike many
other languages, are designed to run several applications *within the
same image*. Thus, having functions that you can not be sure have not
been changed by other applications in the image, may be a bad
idea. For example, assume the `*' function was generic - now assume
that some program needing vectors overloaded it to mean the
dot-product of two vectors (a scalar), that might be represented as
arrays. Now imagine some other program or library, that takes a bunch
of numbers, and uses `*' to perform operations on them. If the user,
or some application, erroneously feeds this library with vectors
instead of numbers, the `*' function will not complain that its
arguments are not numbers, but instead just calculate their dot
product - a scalar, but almost certainly also a value that will be
senseless to the application.
The lack of generic functions in the ANSI standard is meant to ensure
that a portable application can assume that the CL image is as the
standard dictates, and that it has not been modified by any other
applications that might have been loaded. Generic functions should
only be used in conjunction with a solid contract for their exact
behavior (or the ability to completely control them), and not as
syntactical sugar, as they are in languages such as C++ or C#.
--
\ Troels "Athas"
/\ Henriksen
Troels Henriksen <·····@sigkill.dk> writes:
> D Herring <········@at.tentpost.dot.com> writes:
>
>> Mistake 2c:
>> (defmethod + ((a (eql 'hi)) (b (eql 'bye)))
>> (format t "Hello, goodbye."))
>> causes an error
>> This makes operator extensions (say for vectors and matrices)
>> awkward.
>
> As others have pointed out, this is partly due to performance concerns
> (that may or may not be moot with modern computers and compilers), but
> also partly due to the fact that Common Lisp systems, unlike many
> other languages, are designed to run several applications *within the
> same image*. Thus, having functions that you can not be sure have not
> been changed by other applications in the image, may be a bad
> idea. For example, assume the `*' function was generic - now assume
> that some program needing vectors overloaded it to mean the
> dot-product of two vectors (a scalar), that might be represented as
> arrays. Now imagine some other program or library, that takes a bunch
> of numbers, and uses `*' to perform operations on them. If the user,
> or some application, erroneously feeds this library with vectors
> instead of numbers, the `*' function will not complain that its
> arguments are not numbers, but instead just calculate their dot
> product - a scalar, but almost certainly also a value that will be
> senseless to the application.
Actually, the package system appears to deal with this handily:
(defpackage :foo (:use :cl))
(in-package :foo)
(defmethod baz ((x int))
(+ x 1))
(baz 2) -> 3
(defpackage :bar (:use :cl))
(in-package :bar)
(defmethod baz ((x string))
(subseq x 1 2))
(baz "123") -> "2"
(baz 2) -> ERROR
So this may not be a problem after all.
> The lack of generic functions in the ANSI standard is meant to ensure
> that a portable application can assume that the CL image is as the
> standard dictates, and that it has not been modified by any other
> applications that might have been loaded.
But the standard _does_ specify certain generic functions; PRINT-OBJECT
leaps to mind...
--
Robert Uhl <http://public.xdi.org/=ruhl>
I don't want kids who are thinking about going into mathematics
to think that they have to take drugs to succeed. --Paul Erdos
Robert Uhl wrote:
>> The lack of generic functions in the ANSI standard is meant to ensure
>> that a portable application can assume that the CL image is as the
>> standard dictates, and that it has not been modified by any other
>> applications that might have been loaded.
>
> But the standard _does_ specify certain generic functions; PRINT-OBJECT
> leaps to mind...
Yes, and this is because they make only sense when they can be extended
by client programs.
The reason why not more functions are specified to be generic is
probably rather one of those issues that weren't handled because of lack
of time. The ANSI standard doesn't preclude "regular" functions to be
generic, though. A CL implementation would be perfectly conforming if it
made all functions generic.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <································@comcast.com>,
D Herring <········@at.tentpost.dot.com> wrote:
> Mistake 2c:
> (defmethod + ((a (eql 'hi)) (b (eql 'bye)))
> (format t "Hello, goodbye."))
> causes an error
> This makes operator extensions (say for vectors and matrices) awkward.
That's relatively easy to fix:
(shadow '+)
(defmethod + (arg &rest args) (if args (apply #'cl:+ arg args) arg))
(defmethod + ((arg string) &rest args)
(if args (concatenate 'string arg (apply '+ args)) arg))
? (+ 1 2.3 4/5)
4.1
? (+ "foo" "baz" "bar")
"foobazbar"
? (+ "foo" 2)
> Error: value 2 is not of the expected type SEQUENCE.
> While executing: LENGTH
> Type Command-. to abort.
See the Restarts� menu item for further choices.
1 >
Aborted
?
But that path leads to some difficult design questions:
What should (- "foobaz" "foo") do? What about (* "foo" 2)? Should that
be "foofoo"? And if so, should (/ "foofoo" 2) be "foo"? And if so,
what should (/ "foosnoz" 2) be? How about (* 2.3 (sqrt -1) "foo")?
rg
Ron Garret <·········@flownet.com> writes:
> In article <································@comcast.com>,
> D Herring <········@at.tentpost.dot.com> wrote:
>
> > Mistake 2c:
> > (defmethod + ((a (eql 'hi)) (b (eql 'bye)))
> > (format t "Hello, goodbye."))
> > causes an error
> > This makes operator extensions (say for vectors and matrices) awkward.
>
> That's relatively easy to fix:
>
> (shadow '+)
> (defmethod + (arg &rest args) (if args (apply #'cl:+ arg args) arg))
> (defmethod + ((arg string) &rest args)
> (if args (concatenate 'string arg (apply '+ args)) arg))
Of course, this also subtly changes the required number of arguments to
the "+" function. In CL, the lambda list for + should really be (&rest
args), so that you can call it with no arguments at all:
USER> (+)
0
In fact, the no-argument case is one reason why + can't actually be a
generic function, since there are no required arguments on which to
dispatch.
Now, as to why it is useful to have + accept no arguments: It
simplifies the use of + in higher-order functions such as REDUCE, where
you don't have to worry about what happens in the boundary cases of
applying + to lists of length zero or one.
> But that path leads to some difficult design questions:
>
> What should (- "foobaz" "foo") do? What about (* "foo" 2)? Should that
> be "foofoo"? And if so, should (/ "foofoo" 2) be "foo"? And if so,
> what should (/ "foosnoz" 2) be? How about (* 2.3 (sqrt -1) "foo")?
Some of this would be easier if one had a generic binary + instead.
That may, in fact, be a better way of introducing generic functions to
the standard arithmetic functions anyway.
--
Thomas A. Russ, USC/Information Sciences Institute
On Mon, 11 Sep 2006 17:16:21 +0200, Thomas A. Russ <···@sevak.isi.edu>
wrote:
> USER> (+)
> 0
and (*)
1
yes. The invariants. + 0 yields the same value and * 1 too.
(+ 1 2 3 (+)) or (* 1 2 3 (*))
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"John Thingstad" <··············@chello.no> writes:
> On Mon, 11 Sep 2006 17:16:21 +0200, Thomas A. Russ <···@sevak.isi.edu>
> wrote:
>
>
> > USER> (+)
> > 0
>
> and (*)
> 1
>
> yes. The invariants. + 0 yields the same value and * 1 too.
>
> (+ 1 2 3 (+)) or (* 1 2 3 (*))
I did wonder a bit about why this was only true for + and * and not also
for - and /. I'm guessing it has to do with special case treatment of
the single argument case, when a unary operation is performed. Still
one could still have the degenerate case defined. Oh, well, it could be
a bit confusing though:
(- 3) = (- (-) 3) = (- 0 3 (-)) /= (- 3 (-))
--
Thomas A. Russ, USC/Information Sciences Institute
Stefan Scholl wrote:
> Alok <···········@gmail.com> wrote:
> >>From the Revenge of the Nerds http://www.paulgraham.com/icad.html
> >
> > "Python copies even features that many Lisp hackers consider to be
> > mistakes."
> >
> > What are they?
>
> Why ask us? This is comp.lang.lisp, not comp.lang.python
>
> Do you expect everone to know Python?
Situation: You don't want to/can't answer a question.
Response: You point out you don't want to/can't answer the question.
Issue: The question was not directed at you.
Analogy:
Situation: In a crowded room, someone asks where the bean dip is.
Response: You yell at them because 'why would I know where it is'.
Further Response: After everyone looks at you and tilts their heads,
someone directs the questioner toward the bean dip.
My point: Does *everyone* need to know python in order for *someone*
to respond in a *constructive* way to this person's question?
My motivation: I'm a jerk like you.
Alok wrote:
>>From the Revenge of the Nerds http://www.paulgraham.com/icad.html
>
> "Python copies even features that many Lisp hackers consider to be
> mistakes."
>
> What are they?
I don't know Python enough to be able to judge this. But be careful with
the responses: Some people have a tendency to describe specific Lisp
features as mistakes which are actually appreciated by Lispers. Even
among Lispers, the opinions on what are design mistakes and what aren't
can vary heavily. This is especially the case when such discussions
involve different Lisp dialects.
There's no way around forming your own, hopefully informed opinion.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> There's no way around forming your own, hopefully informed opinion.
Sure there is: you can work on reducing the need to have an opinion. :)