Big Problem with LISP
Kaz Kylheku
hi all,
ive been using ansi clisp for 3 months now. I ran into a Big Problem in
the language which i think is indering its wider adoption.
i wrote some code (macros and such) to fix the Big Problem.
I'm too obtuse and inexperience realize that Big Problem is a nonissue
that doesnt affect anyone and that my code is wrong
Soon you will all point out how my "fix" introduces real problems and
not solve any. then i will pretend i new about them that all along, but the
problems are not imporrtant compared to Big Problem, or only some long-time
lisp weenies care about these problems whereas modern developers like me will
obviously be hindered by Big Problem much more than those other problems
your all asses and this group is a flaming hellhole,
not at all intelecutally open minded like other comp groups
u know what, i'm just going away without even revealing Big Problem or showing
my code.
screw you all
1960s called wanting its computer losers back haha
yours truly
Tamas K Papp
> [We haven't had a dose of this for a while, so let me fill in!]
>
> your all asses and this group is a flaming hellhole, not at all
> intelecutally open minded like other comp groups
>
> u know what, i'm just going away without even revealing Big Problem or
> showing my code.
Fortunately we have F#, which has already solved your Big Problem a
thousand times better than Lispers with their silly macros could ever
imagine. It is enough to look at Google Trends:
http://www.google.com/trends?q=big+problem
and you will see the light, so I am not going to lower myself to
writing any actual code. By the way, here is a solution in Ruby:
puts 'Big Problem is Solved!'
which shows that Ruby is way superior to CL.
T
Slobodan Blazeski
That's the spirit you already fallowed some of the recommendations
rules who just for convenience I listed below.Go on and you'll soon
become role model.
bobi
Simple rules to become a role model lisper:
1. Don't learn (*)lisp
2. Troll in comp.lang.lisp (check Gavino for examples)
3. Spam in comp.lang.lisp ( check our resident spammer for examples)
4. If you really decided to learn lisp. Learn some vapourware,
abandonware or marginalisedware lisp.
5. Don't do any search before you ask questions that were answered
for
at least 100000000000000000 times before.
6. If any of the seasoned lispers get's mad because you asked a
question that was already answered for at least 100000000000000000
times
before, start a blog whining about savages of comp.lang.lisp,
prefarably comparing it with eagle-scout community of you-name-it
langauge.
7. If you really started learning common lisp, stop at day two and
whine all the way long in this newsgroup how ugly it is.
8. Continue with lecturing Kent Pittman, Guy L. Steele, and the rest
of the ANSI committee what they were thinking while designing common
lisp and show them the right way it should be done.BTW I've heard
rumours that they were drank all the way through standardisation
process, and rolled dice whenever there was a dispute what features
would get in the standard.
9. Never do any programming in lisp, just hang up in c.l.l all day
long and brag nonsense
10. If you're really must program in lisp, do it like with your
previous favourite language, compiling files through command line,
loading scripts etc. Those things worked great with c and php what
the hell they shouldn't do the same with lisp?
11. Don't listen to experienced lispers. What the hell do they know
what you don't after using lisp for 50 years?
12. Criticize authors of lisp books, especially those who made their
books available as free downloads.
13. Don't buy lisp books.
14. Whine about how all the free lisp implemenattions suck and
commercial lisp are overpriced piece of shit.
15. Be abusive & unhelpfull to newbies
16. Don't write lisp libraries.
17. Whine how lisp lacks libraries in your favourite area.
18. If libraries you need exists, whine how low quality are they.
19. Don't bother to send bug reports to library authors, if they were
smart enough they would figure it out themselves.
20. Even if library you need exists, with good quality and under
acceptable license ,don't use it . Start from scratch creating your
own masterpiece.
(*) Whenever I say lisp in this newsgroup I mean common lisp. For
other meaning I use lisp family of languages
Kenneth Tilton
> (*) Whenever I say lisp in this newsgroup I mean common lisp. For
> other meaning I use lisp family of languages
Scheme wanting to be considered a Lisp is like Robert E. Lee wanting to
keep his commission in the United States Army.
hth,kenneth
budd...@gmail.com
Ok, I see there is common mood for flood and flame. Let me
participate.
> Continue with lecturing Kent Pittman, Guy L. Steele, and the rest of the ANSI committee what they were thinking while designing common
lisp and show them the right way it should be done
I don't know what they were thinking about. CL is not too bad, it is
acceptable. But time goes on and we see other languages appear. Lisp
is being eaten.
And now there is a list of what's wrong with lisp on my opinion (maybe
I'll update it in time).
1. Package system is poorly designed. I wrote this before. This can be
solved in terms of lisp:
- take ccl or sbcl
- make a portable reader
- improve package system behavior
Then next problem then will be a community most of which thinks
package system is OK
2. Lack of static typing and class scoping. Static typing is not only
for safety and speed (we can be careful and
lisp can derive types). The problem is with extra words we need to
type in and read.
(defstruct foo bar baz)
(defun get-data (f) (cons (foo-bar f) (foo-baz f)))
No solution other than static typing to get things as compact as we
have in statically typed languages:
type t = variant;
type foo = record bar:t; baz:t; end;
function get_data(f:foo):list;
begin
result:=cons(f.bar,f.baz);
end;
So, in CL we pay with either code verbosity (as with defstruct) of
with speed (as with CLOS slot accessors that are generic).
Of course, there is no contradiction of lisp ideology and multiple
dispatch with having class scoping. All we need is a fixed "with"
construct.
Also we might change order of compilation. If we make compiler two-
pass, it could parse defclass before doing other macroexpansions.
So, we might use macro (with-all-slots (instance class) . body) which
would bind all slot-names (or accessors) lexically. But there is no
such tradition, so this can't be used in practice. It'd be better if
we might write (declare (class-name instance)) (with-all-slots
instance . body)),
and this can be done by altering compiler, but there is no tradition
to use this approach.
3. Syntax and standard names are insane. In every right language,
there is an embedded compression: frequent words are short
(I,and,if,etc). Lisp is
sometimes grotesque verbose (symbol-macrolet, destructuring-bind,
concatenate 'string, merge-pathnames). You say I can define my short
constructs, but why
should I do this? This should have been done by language designers.
Could people communicate if "and" would spell as "one-with-the-
another" and every
family would invent one's own abbreviation? English would'nt survive
at all (and lisp is dying).
4. Reader extensions are poorly designed. Yeah, you can define [] and
{} readers easily, but there is no traditional way to make it's
definition
context-dependent. So, if two libraries define [], there is a
conflict.
5. Too much freedom for DSLs, too less for core of the language.
6. No sence in using parens only. I'm not a fan of C-like syntax, but
it is really more readable as different types of parens allow to
navigate
easier through a code. Code=data phylosophy do not contradict to infix
syntax. Prolog and Mathematica give an excellent examples of that.
7. Extended loop is ugly. Its adoption is a clear sign that CL goes
wrong way, as extended loop is not lispy at all.
8. asdf... Ah, no words.
9. CL is unsafe. (setf (car '(a)) 'b) and (defun x (&rest y) (setf
(car y) 'a)) are the trivial examples. No constant declarations, no
way to
protect oneself.
We might agree that CL is dying, that less and less people will become
lispers. Finally last lisper will die
and lisp will die too. But I'm, unhappily, a lisper and I'm not very
young. Lisp is dying and this means I'm losing profits from
investment I have made before in learning lisp.
What to do? I tried to fight.
Last time I have made some efforts to fix some of the issues:
I've designed see-packages macro (didn't implement it as it requires
making new lisp reader. I've seen no support here so
I'm unsure there is a reason to waste my time on it).
I've improved iterate to iterate-keywords and now I don't use extended
loop unless I must to. Noone cares.
I'm working on asdf improvements and it is clear this can be done.
Mostly it needs a user manual and some rather small add-ons.
No need to design new defsystems (such as mudballs).
Infix syntax would be fine, but emacs mode needs to be rewritten too.
It is hard work and I'm unsure I have the resources for
that at all. Worse is a need to redesign a printer. No sence to change
reader if printer would stay paren-based. So this looks like
unfixable problem. Ok, prefix syntax is not so bad if we might employ
{} and [].
Static typing can be added, I need more time to think of it. For now,
I think it could be some macro which introduces static
typing locally, but I'm not sure this can be done without global
changes into compile and/or overall source organization.
Reader can be improved with new #w dispatch macro I'm designing, e.g.
#wp package-name form-to-be-read-with-that-package
#w symbol-to-name-reader-macro (assigning readmacros to symbols
greatly extends a number of readmacros which could co-exist)
e.g.
#w sql:[ select * from foo ]
#w other-dsl:[ do-something-with-that-dsl ]
And there is still a free namespace for readmacros like #NwCHARS,
where n is a number and CHARS is a sequence of non-whitespace chars.
E.g. we might define
#wof body = `(with-open-file ,@body)
#wg body = `(with-gensyms ,@body)
#wx <xml > = read xml
#wsql () = read sql
#whtml text = read html
#w'single-quoted-string-as-in-javascript'
But... Even if I'll finish all that work, what would I get? People
would say I'm wrong, lisp is Ok, so I'll
need make a significant effort to promote this. It looks like it has
no sence and it is more reasonable
to switch to other languages.
E.g. I might use some JVM-based language or even C. The only feature
which is crucial and missing from mainstream languages is a defmacro.
But external lexical-based macroprocessors can be added to those
languages. There even are some for the Java.
Yeah, you can say now all the good words you always have to say to
your enemies. But problem is not with me, it is with lisp. The only
thing
we could do to save lisp from death is to review it. I've made a plan
and I think my mission is over. I'm an analyst and idea generator,
not
a manager or a promoter. I could participate to it or not, I don't
know.
This work is not too hard, I could do this alone in a year if payed (w/
o infix syntax which might be really hard). But evidently no-one going
to
pay me for that and I need to work to earn for living.
Pascal J. Bourguignon
budd...@gmail.com writes:
> 6. No sence in using parens only. I'm not a fan of C-like syntax, but
> it is really more readable as different types of parens allow to
> navigate easier through a code.
If you find it more readable, it would be quite easy to make emacs
display different parentheses at each level.
⎧⎡⎛ ⎞⎤⎫
⎨⎢⎜｛〚〘〖〔【『「《〈⦗⦑⦏⦍⦋⦃⦅⌊⌈⋋⋉⊣⁅{[()]}⁆⊢⋊⋌⌉⌋⦆⦄⦌⦐⦎⦒⦘〉》」』】〕〗〙〛｝⎟⎥⎬
⎩⎣⎝ ⎠⎦⎭
But can you spot where I interverted the matching parentheses?
I find it easier with:
(((((((((((((((((((((((((((((((((((((((())))))))))))))))))))))))))))))))))))))))
at least, there's no risk of parenthese mismatching, since any closing
parenthesis matches an operning one.
> Code=data phylosophy do not contradict to infix
> syntax. Prolog and Mathematica give an excellent examples of that.
Using only parentheses and prefix notation represents a big sparing of
means ("économie de moyens"), it's really much simplier, both for the
implementation and for the user-meta-programmer.
(first '(operator argument-x argument-y argument-z)) --> operator
(first (rest '(operator argument-x argument-y argument-z))) --> argument-x
You can SEE that the OPERATOR is in the first position.
With infix:
(operator '(argument-x operator argument-y operator argument-z)) --> operator
(first (arguments '(argument-x operator argument-y operator argument-z)) --> argument-x
there's a redundancy of the operator, it could easy be broken and
meaningless if you had different operators. While the OPERATOR
function can be as simple as FIRST, the function ARGUMENTS must be
much more complex, it may even need to know each of the OPERATORs with
their respective syntax. Therefore now defining new operators
(eg. with macros) becomes much more complex, since you have to declare
for them where to find the arguments infixed with syntactic elements.
> 7. Extended loop is ugly. Its adoption is a clear sign that CL goes
> wrong way, as extended loop is not lispy at all.
This point is self contradictory. Either LOOP is ugly, or CL goes
wrong, but it cannot be both at the same time.
If you think LOOP is nice, then the CL way (uniform prefix) could be
wrong. But if you think that LOOP is ugly, then the CL way is clearly
the right way.
> 9. CL is unsafe. (setf (car '(a)) 'b) and (defun x (&rest y) (setf
> (car y) 'a)) are the trivial examples. No constant declarations, no
> way to protect oneself.
This is not unsafe, this is just not portable. (Mostly because it may
have different semantics when interpreted than when compiled).
Therefore it's not conformant, but there's no unsafeness in that.
> We might agree that CL is dying, that less and less people will
> become lispers. Finally last lisper will die and lisp will die
> too. But I'm, unhappily, a lisper and I'm not very young. Lisp is
> dying and this means I'm losing profits from investment I have made
> before in learning lisp.
But this is clearly wrong. Just check the evolution of the number of
CL libraries during the last ten years, or the traffic in cll.
--
__Pascal Bourguignon__
Slobodan Blazeski
> Hi!
> Ok, I see there is common mood for flood and flame.
>Let me
> participate.
>
> > Continue with lecturing Kent Pittman, Guy L. Steele, and the rest of the ANSI committee what they were thinking while designing common
>
> lisp and show them the right way it should be done
>
> I don't know what they were thinking about. CL is not too bad, it is
> acceptable. But time goes on and we see other languages appear. Lisp
> is being eaten.
don't you start and design your own language? If you do great it
might become next python, or ruby or .. whatever. Else stop whining
(**). Currently common lisp is the best lisp around. Some other
dialects are better in some areas, but common lisp is the best
complete design.
cheers
bobi
(*)irony -
a-The use of words to express something different from and often
opposite to their literal meaning.
b-An expression or utterance marked by a deliberate contrast between
apparent and intended meaning.
c-A literary style employing such contrasts for humorous or rhetorical
effect.
(**) Whine- To complain or protest in a childish fashion.
Tamas K Papp
> I don't know what they were thinking about. CL is not too bad, it is
> acceptable. But time goes on and we see other languages appear. Lisp is
> being eaten.
Nice vacuous statement.
> 1. Package system is poorly designed. I wrote this before. This can be
You wrote of this before, but nobody agreed with you. Take the latter
as a hint.
> 2. Lack of static typing and class scoping. Static typing is not only
> for safety and speed (we can be careful and lisp can derive types). The
> problem is with extra words we need to type in and read.
>
> So, in CL we pay with either code verbosity (as with defstruct) of with
In case you haven't noticed yet, in CL you can eliminate extra
verbosity with macros.
> 3. Syntax and standard names are insane. In every right language, there
> is an embedded compression: frequent words are short (I,and,if,etc).
Another red herring. If you don't like the standard names, go right
ahead and redefine them.
> 5. Too much freedom for DSLs, too less for core of the language.
Do I understand it correctly that you are complaining about too much
freedom?
> 6. No sence in using parens only. I'm not a fan of C-like syntax, but it
Another vacuous statement. What do you mean by "no sense"?
> is really more readable as different types of parens allow to navigate
> easier through a code. Code=data phylosophy do not contradict to infix
Use your editor to indent and navigate through code.
> 7. Extended loop is ugly. Its adoption is a clear sign that CL goes
> wrong way, as extended loop is not lispy at all. 8. asdf... Ah, no
> words.
Well, then don't use it. Use iterate or write your own library.
> no way to protect oneself.
Use a condom.
> We might agree that CL is dying, that less and less people will become
No, I don't agree that Lisp is dying. But invite JH for a beer (or a
drink of fermented frogs, etc) and you could have a nice conversation
with him on this. Make sure you bring a laptop with internet access,
he will use Google trends.
> lispers. Finally last lisper will die and lisp will die too. But I'm,
I am only 28, and try to eat healthy and exercise. So you don't need
to worry about the last lisper dying for quite a bit :-)
> unhappily, a lisper and I'm not very young. Lisp is dying and this means
> I'm losing profits from investment I have made before in learning lisp.
Nope, you are not a lisper. You are using Lisp, but you don't _get_
it. You keep complaining about irrelevant things, propose fixes that
don't make things better, and then act surprised when you are ignored.
> What to do? I tried to fight.
You should have tried to just write programs instead.
> I've designed see-packages macro (didn't implement it as it requires
> making new lisp reader. I've seen no support here so I'm unsure there is
> a reason to waste my time on it).
Well, I presume that you solution is useful TO YOU, isn't it? In that
case your time is not wasted.
> I've improved iterate to iterate-keywords and now I don't use extended
> loop unless I must to. Noone cares.
I am interested in an improved iterate, but I dismissed you as a
whining nut, and decided that I would have to check your code
thorougly before using it, and currently I have no time for that. I
you convince the maintainer of iterate to integrate your stuff, I will
be using it.
> Infix syntax would be fine, but emacs mode needs to be rewritten too. It
> [...]
> Static typing can be added, I need more time to think of it. For now, I
> [...]
> Reader can be improved with new #w dispatch macro I'm designing, e.g.
> [...]
> But... Even if I'll finish all that work, what would I get? People would
> say I'm wrong, lisp is Ok, so I'll need make a significant effort to
> promote this. It looks like it has no sence and it is more reasonable
> to switch to other languages.
So go ahead, switch. I have seen you appear on c.l.l, and propose a
fundamental redesign to almost all parts of CL. Which is fine, but
you need to realize that changes are always costly, and you have to
convince others that they make sense - the burden of proof is on you.
I have not seen anything to that effect, you just keep complaining
that things are not "right". But for most people they are. Too bad.
> But problem is not with me, it is with lisp.
Ah.
> we could do to save lisp from death is to review it. I've made a plan
> and I think my mission is over. I'm an analyst and idea generator, not
No, you are neither an analyst nor an idea generator, you are a whiner
who acts hurt when he fails to make sense to others.
> This work is not too hard, I could do this alone in a year if payed
> (w/ o infix syntax which might be really hard). But evidently no-one
> going to pay me for that and I need to work to earn for living.
Dude, after what I have seen from you on c.l.l, I wouldn't employ you
even if you worked free, or paid for the privilege.
So I guess Lisp will not be saved after all, we are all doomed. Feel
free to switch to the current Blub, and write us a postcard from Blubland.
Tamas
budd...@gmail.com
looks like it is just not portable indeed, but I didn't make such
things under (speed 3) (safety 0) and dynamic-extent declaration. I'm
not sure some implementation won't fail.
> If you find it more readable, it would be quite easy to make emacs
> display different parentheses at each level.
It is interesting, but it is still worse than C. In C, we can look at
paren and say what does it mean. If it is a block boundary, index
expression boundary or function arglist boundary. If it is possible to
change view of parens in a lisp to be a function of its syntactic
sence, it'd be really great relief. Compare
(cond
((eq t t) (if t t (foo nil (foo nil))))
(t t))
and, say,
【cond
〔(eq t t) 【if t t (foo nil (foo nil))】〕
〔t t〕】
They should be always entered as a parens, of course.
But C-like infix form is no way worse:
cond {
eq(t,t) : if(t) t; else foo(nil,foo(nil));
t : t;
}
> (((((((((((((((((((((((((((((((((((((((())))))))))))))))))))))))))))))))))))))))
> at least, there's no risk of parenthese mismatching, since any closing
> parenthesis matches an operning one.
This can be done by editor. I admit that emacs is better than Delphi
(which fails to find "end"
corresponding to "begin") in this. Emacs supports many operations with
sexps as well as auto-indent.
So I think it would be no problem to change parens presentation until
editor fails to do lisp-specific
operations correctly.
Writing macros is by two orders of magnitude less frequent activity
than reading code.
Again, frequency principle: most frequent things should be the easiest
to do. It'd be
no problem if writing macros would be a bit esoteric. Now we have
reading lisp
esoteric and writing lisp nearly impossible w/o emacs instead.
> Using only parentheses and prefix notation represents a big sparing of
> means ("économie de moyens"), it's really much simplier, both for the
> implementation and for the user-meta-programmer.
> ...
> (operator '(argument-x operator argument-y operator argument-z)) --> operator
> (first (arguments '(argument-x operator argument-y operator argument-z)) --> argument-x
Just a bit harder in lispy notation. We might also print it in a
normalized infix notation.
a + 2*c(x) reads in (+ a (* 2 (c x))) and prints as
Plus(a,Multiply(2,c(x)))
It is rather natural that
operator(Quote(Plus(a,...))) => Plus
first(arguments(Quote(Plus(a,...)))) => a
I can even suggest a backquoting for infix notation:
#define unless (x,&body(body)) #quasiquote(if #unquote(x); else
#unquote(body))
// which is used as
unless (t) {
blah-blah;
}
This have no direct correspondance to possible lisp definition of
unless, as an effort is taken to be closer to C syntax. And there are
some problems related to parens treatment in C where (()) = ().
But I didn't spent many time on it.
And, if priority rules are consistent in a package, we could even try
to transform code at readtime, so that
if (a) then b; else c; would read in as (if a b c)
> Therefore now defining new operators
> (eg. with macros) becomes much more complex, since you have to declare
> for them where to find the arguments infixed with syntactic elements.
> > 7. Extended loop is ugly. Its adoption is a clear sign that CL goes
> > wrong way, as extended loop is not lispy at all.
>
> This point is self contradictory. Either LOOP is ugly, or CL goes
> wrong, but it cannot be both at the same time.
Lisp is lispy. Loop is non-lispy and hence, in context of lisp, ugly.
ANSI failed to propose anything
better than loop. This is not a contradiction, but this should point
to some problems within lisp itself.
> But this is clearly wrong. Just check the evolution of the number of
> CL libraries during the last ten years, or the traffic in cll.
Maybe I'm wrong, but I still can't find lisp job which is payed
adequately.
daniel....@excite.com
serious.
Really, "no one cares?" And, "I've seen no support here so I'm unsure
there is a reason to waste my time on it?" To top it off, this one
knocked me out:
This work is not too hard, I could do
this alone in a year if payed.... But
evidently no-one going to pay me for
that and I need to work to earn for
living.
I read Budden's post in the same spirit as I read Slobodan's and I
laughed hard for both! I credit Budden with an acute sense of humor.
On the other hand, if he was serious... well, in that case he has the
kindness of those who have already answered thoughtfully, and I've
made an embarrassing, but honest, mistake.
Tamas K Papp
> * Tamas K Papp <6trdpuF...@mid.individual.net> : Wrote on 22 Jan
>
> | Dude, after what I have seen from you on c.l.l, I wouldn't employ you
> | even if you worked free, or paid for the privilege.
>
> [I don't agree with what the OP says and do not use
> packages/libraries he wants to market. But]
>
> I don't think this part is fair. The little bits of code the OP
> actually posted did not seem unreasonable --- though I've only visually
> inspected them in the line-broken mauled form after passing through his
> NNTP provider
I don't have a problem with his code per se, but with his attitude,
and that should be enough to scare away any potential employer.
He wants to change the language in fundamental ways. Fine. People do
that, and Lisp is an ideal basis for building a new language because
you can use the reader, the compiler, etc. Mark Tarver wanted to do
it, and he came up with Qi, now at its second version and looks really
cool.
In contrast, budden _talks_ about grand changes, expects people to
join him in his crusade and acts hurt when that doesn't happen. He
should realize that even if he comes up with a new language that is a
significant improvement over CL (which has failed to manifest so far),
people won't switch on a whim. Those things take time, and it is
always the inventor of the new language who has to demonstrate its
usefulness (again, look at all the code Mark has written to
demonstrate how nice Qi is). Also, if people fail to show any
interest at all, perhaps the fault is not with them but the proposed
change, and there is no reason to whine about this.
Tamas
Pascal J. Bourguignon
>> This is not unsafe, this is just not portable. (Mostly because it may have different semantics when interpreted than when compiled).
> Standard says "consequences are undefined". This means unsafe. It
> looks like it is just not portable indeed, but I didn't make such
> things under (speed 3) (safety 0) and dynamic-extent declaration. I'm
> not sure some implementation won't fail.
>
>> If you find it more readable, it would be quite easy to make emacs
>> display different parentheses at each level.
> It is interesting, but it is still worse than C. In C, we can look at
> paren and say what does it mean. If it is a block boundary, index
> expression boundary or function arglist boundary.
But that is what makes C so complex, and so useless. This is exactly
this that makes C unusable for any meta-programming.
In C, distinctions are made between things that should not be distinct:
- statements are not expressions and expressions are not statement.
- for both statements and expressions, there's again a lot of
distinctions made between the various instances:
- array referencing is not a function call is not an operator application.
- alternative is not like a sequence is not like a loop.
(and it's even more complex with C++ where templates are like nothing else, etc).
Therefore if you wanted to make a meta-programming system over C, you
would be overwhelmed by the complexity and lost into these details.
To contrast, in Lisp, there is unification:
- there's no difference in form between structure access and
function calls or operator application.
- there's no difference in form between the various statements,
- there's no distinction made between expressions and statements:
everything is an expression.
This is what makes Lisp a very simple programming language, like the
unified theories of physics are very simple and elegant: a single
formula is needed to understand the whole universe.
And this is what makes Lisp a system manageable under
meta-programming; that's why it's so easy to write meta-programs in
Lisp.
> If it is possible to
> change view of parens in a lisp to be a function of its syntactic
> sence, it'd be really great relief. Compare
> (cond
> ((eq t t) (if t t (foo nil (foo nil))))
> (t t))
> and, say,
> 【cond
> 〔(eq t t) 【if t t (foo nil (foo nil))】〕
> 〔t t〕】
>
> They should be always entered as a parens, of course.
If you like this representation, and it is not stored in the files, I
don't mind it. I don't like it and find it disturbing. But it's only
a local percolation.
> But C-like infix form is no way worse:
>
> cond {
> eq(t,t) : if(t) t; else foo(nil,foo(nil));
> t : t;
> }
It's also envisageable to make emacs load and save sexp-files, while
presenting them in its buffer with various syntaxes such as a C or
Algol-like syntax.
But really, mind the problems you will have when you'll write a macro:
my-macro( cond {
eq(t,t) : if(t) t; else foo(nil,foo(nil));
t : t;
} );
(defmacro my-macro (form)
(second (second form)))
What will it return?
>> (((((((((((((((((((((((((((((((((((((((())))))))))))))))))))))))))))))))))))))))
>> at least, there's no risk of parenthese mismatching, since any closing
>> parenthesis matches an operning one.
> This can be done by editor.
Indeed it is done by the editor. So let's agree to forget about them
parentheses and think about more complex problems such as writing a
strong AI.
> Writing macros is by two orders of magnitude less frequent activity
> than reading code.
Nonetheless, the homoiconic principle is put to work both when reading
and when writing. Even more so probably when reading!
>> > 7. Extended loop is ugly. Its adoption is a clear sign that CL goes
>> > wrong way, as extended loop is not lispy at all.
>>
>> This point is self contradictory. Either LOOP is ugly, or CL goes
>> wrong, but it cannot be both at the same time.
> Lisp is lispy. Loop is non-lispy and hence, in context of lisp, ugly.
> ANSI failed to propose anything
> better than loop. This is not a contradiction, but this should point
> to some problems within lisp itself.
No. It points to some problems with time and resources.
>> But this is clearly wrong. Just check the evolution of the number of
>> CL libraries during the last ten years, or the traffic in cll.
> Maybe I'm wrong, but I still can't find lisp job which is payed
> adequately.
When you find a lisp job, it is well paid.
But making managers hire lisp programmers won't be attained by changing
fundamental lisp syntax and principles. This has been tried several
times over the 50 years of lisp history, and only sexp based lisps
survive.
--
__Pascal Bourguignon__
Alexander Lehmann
> In C, distinctions are made between things that should not be distinct:
>
> - statements are not expressions and expressions are not statement.
Yes, and no. A statement like "x = 7 + 3;" in C actually /is/ an expression
which evaluates to the R-value of 7+3, yet as a /side-effect/ stores the result
at the address pointed to by x. It's basically the ";" that hauls the
expression's R-value overboard.
However, I agree with most of what else you've written. :)
Bakul Shah
"Common Lisp is a new dialect of Lisp, a successor to MacLisp, influenced
strongly by ZetaLisp and to some extent by Scheme and InterLisp."
Jeff Schwab
> In C, distinctions are made between things that should not be distinct:
>
> - statements are not expressions and expressions are not statement.
>
> - for both statements and expressions, there's again a lot of
> distinctions made between the various instances:
> - array referencing is not a function call is not an operator application.
> - alternative is not like a sequence is not like a loop.
>
> (and it's even more complex with C++ where templates are like nothing else, etc).
C++ templates are the solution to the issues you mentioned, not part of
the problem. In C++ template metaprogramming (TMP), everything is
represented as a static type, and therefore can be accessed using
uniform syntax.
Compile-time C++ is also a pure functional language, a necessity imposed
by the immutable nature of C++ metadata. If you want to loop at
compile-time, you write a recursive template instantiation. The base
case is typically provided by a separate template instantiation, which
makes TMP look more like a logic programming language than lisp does.
The only real syntactic non-uniformity remaining is between the run-time
and compile-time subsets of C++, and the upcoming standard addresses
those with some new keywords, and with formal metatypes called
"concepts:" Each C++ type is a model of one or more concepts, much as
each object is an instance of one or more types.
The last frontier for C++ will be run-time metaprogramming, which has
been avoided in the standard so far because C++ goes out of its way to
avoid run-time overhead. With virtual machines and just-in-time
compilation gaining popularity, though, I think we'll eventually need
standard run-time metaprogramming constructs in C++. I'd look for those
in 5-10 years, when C++1x is under serious consideration. In the
meantime, there are just disparate libraries, like Boost.Any and Qt's
signal/slot mechanism.
Asgeir
I followed conscienciously all the Steps you described, but it doesn't
works ! I'm now a true newLISPer and all others lispers laught of me.
What can I do ?
thxbye
--
Asgeir
Christian Lynbech
budden> 5. Too much freedom for DSLs, too less for core of the language.
You can not have too much freedom. The idea that the biggest threat to
the beauty of the program is the programmer and hence the omnipotent
language designer should put in stops nd safeguards at every corner is a
viable an idea as the earth being flat or the wheel being useless.
budden> E.g. I might use some JVM-based language or even C. The only feature
budden> which is crucial and missing from mainstream languages is a defmacro.
budden> But external lexical-based macroprocessors can be added to those
budden> languages. There even are some for the Java.
You absolutely correct. Metaprogramming has been a study for language
researchers for decades and for all kinds of langauges, it was already
old when I was taking CS in the late 80's, yet it does not seem to
really have caught on anywhere else than in lisp. A cynic would think
that appealing to external tools for metaprogramming just isn't working
as well as when it is integrated into the language as it is with lisp.
------------------------+-----------------------------------------------------
Christian Lynbech | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
Kaz Kylheku
> [ ... ] Package system is poorly designed [ ... ]
> [ ... ] next problem then will be a community most of which thinks
> package system is OK [ ... ] Static typing is not only
> for safety and speed [ ... ] Syntax and standard names are insane.
> [ ... ] I'm not a fan of C-like syntax, but
> it is really more readable as different types of parens allow [ ... ]
> [ ... ] Too much freedom for DSLs, too less for core of the language
> [ ... ] We might agree that CL is dying.
Exactly, yes.
kod...@eurogaran.com
> budden> E.g. I might use some JVM-based language or even C. The only feature
> budden> which is crucial and missing from mainstream languages is a defmacro.
> budden> But external lexical-based macroprocessors can be added to those
> budden> languages. There even are some for the Java.
As Peter Seibel uses no remark, macros success in Lisp is intimately
related to the parens.
One produces the other.
>
> You absolutely correct. Metaprogramming has been a study for language
> researchers for decades and for all kinds of langauges, it was already
> old when I was taking CS in the late 80's, yet it does not seem to
> really have caught on anywhere else than in lisp.
This is a strange mistery: As we see programming -and the use of
computers- being
spread in every field imaginable, there hasn't been the same puissance
in its use for the very task of programming itself.
Programming should be done by programs.
Shockingly, that's not true, and constitutes a failure. Probably a
failure due to not adopting Lisp.
Pascal J. Bourguignon
> Pascal J. Bourguignon wrote:
>> In C, distinctions are made between things that should not be distinct:
>>
>> - statements are not expressions and expressions are not statement.
>
> Yes, and no. A statement like "x = 7 + 3;" in C actually /is/ an expression
> which evaluates to the R-value of 7+3, yet as a /side-effect/ stores the result
> at the address pointed to by x. It's basically the ";" that hauls the
> expression's R-value overboard.
x=7+3
is indeed an expression.
But:
x=7+3;
is not, it is a statement.
Thanks to this, indeed all expressions can be converted into
statements, but the reverse is not possible. There's no way to
convert a statement into an expression(*), and this is what is bad.
It's so bad actually, that at least for one instruction, the
alternative, they had to introduce a corresponding syntactic form as
expression: if(cond) e1 else e2 becomes (cond)?(e1):(e2)
Unfortunately, the C language designers were too busy developping
unix, and they didn't realize that they needed to convert all their
statements into expressions too and forget about statements. Well, if
they had learned about LISP to beginning with...
> However, I agree with most of what else you've written. :)
(*) IIRC, gcc 4 offers some extensions to use statements where
expressions are expected.
--
__Pascal Bourguignon__
Alexander Lehmann
> Thanks to this, indeed all expressions can be converted into
> statements, but the reverse is not possible. There's no way to
> convert a statement into an expression(*), and this is what is bad.
You're right, my fault.
budden
>related to the parens.
>One produces the other.
http://people.csail.mit.edu/jrb/jse/jse.pdf
and
http://jse.sourceforge.net/examples/index.html
This is an example of macroprocessor in java. It introduces
a code representation model and coordinated quasiquotation to Java.
One quote:
// Copyright (c) 2001-2003, Jonathan Bachrach, Tom White. See file
LICENSE.
import java.util.*;
public syntax unless {
case #{
unless (?:expression)
?:statement
}:
return #{
if (!(?expression)) {
?statement
}
};
}
Pascal J. Bourguignon
Just to let you understand what "local optimum" means:
(defmacro unless (expression statement)
`(if (not ,expression)
,statement))
And no, it's not about number of characters or l ines.
--
__Pascal Bourguignon__
Slobodan Blazeski
wrote:
conventional languages:
And with C++, you can change the semantics and the syntax, but only so
much: with a lot of work, you can make the dot on our horizontal line
move left or right, but it's a LOT of work, like pushing a dead horse
down the street. It's about that pleasant, too.
http://steve.yegge.googlepages.com/lisp-wins
So if some language makes something possible everybody will all avoid
it if it's inconvenient and poorly integrated within the rest of the
language.
If only experts could use it, no one will use it.
bobi
>
> --
> __Pascal Bourguignon__
budden
possibility to add external preprocessor to Java.
budden
(preprocessor). First of all,
you can't include {} block as a parameter (it'd be trivial and it
seems that GNU has this
extension). Also, you can't generate preprocessor directives from
macroexpansion.
This two disadvantages kill the very idea of MP in C. But both
problems are easy to fix:
there is still a free space in C space to add it. Better example is
m4, which is a great
relief from cpp pain. If m4 was initially launched with C instead of
cpp, C++ could never
get a chance to win any acception.
Dimiter "malkia" Stanev
As a great viable alternative to C++, while keeping the runtime speed of
it - check the Cern Labs CINT (C++ Interpreter) with their ROOT runtime.
basically it allows you do iterative C++ programming - define stuff on
the fly from a REPL, etc - you can also decide what gets compiled from
your native compiler, and what not. It has reflection/introspection
system - you can enumerate any variable, function, etc. - but once you
decide to compile that code back with your C++ compiler you are losing
it (well it's kind of #ifdef').
Check:
The CINT interpretter might be 10, 100 or 1000 slower than C++ compiled
code, but that might be fine during development, later just switch to
full C++. Just check it out - it might be better for you, than Common
Lisp. Yes those are the guys behind the Accelerator.
Then again I'm finding that Common Lisp can do all that, with a nearly
fixed slowdown of x2 - x4 to most extreme algorithms (compression,
floating point operations) than C++ - so it's middle ground, local
optimum - etc.
And in certain cases, handling hairy data, way better than C++ -
especially if someone is stupid enough to use std::string everywhere,
thinking that it would end up in a constant symbol pool, and it does not.
budden
for me even in its dynamic form. I think that my negative opinion
about C++ will never change. Lisp is thousand times better than C++
even if we admit all its disadvantages as impossible to fix. C is
better than C++ as it has less junk inside. It even looks reasonably
well designed.
Slobodan Blazeski
> Dear Slobodan Blazeski,
>
> I followed conscienciously all the Steps you described, but it doesn't
> works ! I'm now a true newLISPer and all others lispers laught of me.
>
> What can I do ?
thinking about you?
Friend of mine has one of those brick stone age cell phones. We always
laugh at him , but when we got into the tunnel his brick is the one
that holds signal. Or one neighbor has a Russian jeep, I don't
remember the brand, it's ugly gas guzzler and the ergonomics sucks but
it goes everywhere and doesn't have a problem to start even on the
coldest weather.
So if NewLisp is the right solution for your needs enjoy it, you
approval neither from me nor other lispers. Common Lisp is not one
solution fits them all.
bobi
William James
> [We haven't had a dose of this for a while, so let me fill in!]
>
> hi all,
Hi all,
>
> ive been using ansi clisp for 3 months now. I ran into a Big Problem
I've been using ANSI COBOL-Lisp
> in the language which i think is indering its wider adoption.
I think is hindering
> i wrote some code (macros and such) to fix the Big Problem.
I wrote
>
> I'm too obtuse and inexperience realize that Big Problem is a nonissue
inexperienced to realize that the Big Problem is a non-issue
> that doesnt affect anyone and that my code is wrong
that doesn't affect anyone and that my code is wrong.
>
> Soon you will all point out how my "fix" introduces real problems and
> not solve any. then i will pretend i new about them that all along,
does not solve any. Then I will pretend I knew about them all along,
> but the problems are not imporrtant compared to Big Problem, or only
important
> some long-time lisp weenies care about these problems whereas modern
> developers like me will obviously be hindered by Big Problem much
> more than those other problems
problems.
>
> your all asses and this group is a flaming hellhole,
You're all asses and this group is a flaming hellhole,
> not at all intelecutally open minded like other comp groups
intellectually open-minded like other comp groups.
>
> u know what, i'm just going away without even revealing Big Problem
You know what? I'm
> or showing my code.
>
> screw you all
Screw you all.
>
> 1960s called wanting its computer losers back haha
>
> yours truly
>
> nob...@ofno.consequence.com
budden
Kenneth Tilton
> Common Lisp is not one
> solution fits them all.
Ten more years in the monastery for you.
hth,kth
Kaz Kylheku
> Kaz Kylheku wrote:
>
>> [We haven't had a dose of this for a while, so let me fill in!]
>>
>> hi all,
>
> Hi all,
Man, just how mentally defective do you have to be to correct the obviously
deliberate errors in a humor posting?
When have I been known---consistently, in nearly every sentence of an
article---to omit capitalization and punctuation and exhibit blatantly poor
grammar and spelling?
Autism? Asperger's? What is this?
Tamas K Papp
Severe Jerk Syndrome. Etiology: mostly related to defective early
socialization and lack of proper parental intervention. As of today, no
cure exists.
T