Newbie questions
Nir Sullam
I am about to get my copy of Paul Graham's book (ANSI CommonLISP) and I am
very anxious.
Still , I have some questions:
FIRST:
Here in Israel , we have thousands of C\C++ programmers and so the
newspapers want ads are filled with requests for this kind of programmers ,
BUT never did I see a CLOS \ Lisp programmer want ad .!!!
If CLOS is so powerfull and (I read that) P Graham sold his software (in
CLOS) to Yahoo in 49 Million U$, How come CLOS is so obscure in the
programming community ?
SECOND:
I have Allegro CL 5.0 Lite and Lispworks Personal Edition.
None of the above can export to EXE in the Windows Environment,
Is there a program to do this (even in its demo version), As I haven't even
started programming in CLOS - I won't be going paying 600 U$ for a program
that I still do not need. How do CLOS beginners usually start programming.
CLISP is too primitively interfaced (still).
THIRD
I program AutoLISP in an IDE called VitalLISP and I came to like the way it
works. (automatic completion of symbols names) - I once downloaded FreeLISP
and then lost the copy. I can remeber that it reminded me of VitalLISP -
Can anybody tell me where can I find the latest version that Harlquin
released ?
TIA
Nir sullam
sySOFT CAD Solutions
Haifa.
Kent M Pitman
> Here in Israel , we have thousands of C\C++ programmers and so the
> newspapers want ads are filled with requests for this kind of programmers ,
> BUT never did I see a CLOS \ Lisp programmer want ad .!!!
>
> If CLOS is so powerfull and (I read that) P Graham sold his software (in
> CLOS) to Yahoo in 49 Million U$, How come CLOS is so obscure in the
> programming community ?
For a whimsy way to see an approximate answer, try this:
In the above, substitute "uranium" for "CLOS", "atomic power" for "Lisp",
"coal" for "C", "oil" for "C+", and "fuel sources" for "programmers" in
the above and see if it helps you understand the answer.
Is atomic power for everyday use? In principle it probably could be.
Look at atomic subs, for example. Pretty small-scale use of atomic
power. But as a practical reality, atomic power just isn't used the
same as fossil fuels. The market is not segmented that way. Does
that mean that coal and oil is the future and uranium the past? Not
nearly as clear. Observing usage stats is sometimes predictive, but
not always. The quick and easy availability of coal and oil has turned
an artificial distinction into a situation where two "would-be
competitors" appear to be different markets.
Not by necessity but more by what is now custom, Lisp tends to get used in
highly leveraged situations where other solutions don't work. Not so much
because it has to work that way, but because people usually reach for
something quick and easy and prevalant for ordinary problems. But C/C++
doesn't work for some sets of things because it doesn't scale well, and
since Lisp is designed to scale, it works better in really big situations.
Also, Lisp where it is used often it allows fewer people to do what
many would otherwise do. This means you often don't see large shops
of Lisp programmers.
The analogy isn't perfect, though. Contrary to prevailing myth, you
don't have to wear special clothing to handle Lisp. And it isn't unhealthy
to other products living downstream.
Hope this helps. Have a nice day.
Erik Naggum
| Here in Israel, we have thousands of C/C++ programmers and so the
| newspapers want ads are filled with requests for this kind of
you're comparing a commodities market with a luxury market. why?
| If CLOS is so powerfull and (I read that) P Graham sold his software (in
| CLOS) to Yahoo in 49 Million U$, How come CLOS is so obscure in the
| programming community?
because it's a luxury.
essentially, any damn fool can pretend to be a C/C++ programmer, as you
will very quickly find out if you _place_ one of those ads and try to
sort one or two good guys out from of the liars and incompetent fucks who
apply for the job. if you want to apply for jobs where the requirement
is Common Lisp, you will equally quickly find out that you can't fool
anyone. likewise, you can find a job at a hamburger joint without any
skills whatsoever, but if you want to look at how you produce equipment
used in hamburger joints that should be simple enough that any unskilled
person can operate it without causing himself damage or produce bad food,
you look at the end of the market that Common Lisp is good at helping --
you don't see many ads for hamburger joint equipment designers, either.
with all those ads for C/C++, it means companies are _desperate_ to hire
people who seem to know C/C++. why do you think this is? it's because
C/C++ are job-creating languages. let's take the development of the
telephone as an example: initially, there were human operators, and all
this worked great: but the more people wanted phones, the more people
were required to be operators, and the companies were scrambling for
operators, offering a lot of people work. then better technology came to
the rescue and released the work force tied up in operators to do other
necessary tasks. think of C/C++ programmers are human telephone
operators -- the more successful they are, the more of them are needed
(it is no accident the languages come from the biggest telephone company
in the United States, either). in contrast, the Common Lisp programmers
as designers of the automated telephone switching system, and the more
successful they are, the less investment will be in human operators.
| None of the above can export to EXE in the Windows Environment,
you're assuming that this is what you will need to produce. why?
| How do CLOS beginners usually start programming?
they play with their Lisp environments, and use Emacs as their main
interface to this environment unless they have a visual something that
does the same. it seems that you simply use your tools inefficiently,
but you should investigate how to interface several powerful tools with
eachother to make them work as one. they don't have to come as one form
the Single Vendor to work as one if they were designed well. (this may
well be very foreign to a Microsoft victim. :)
all programming languages are not alike. that you have found interest in
Common Lisp sets you out from the crowd. don't let the crowd run you
down just because you have found something much better. however, it is
essential to succeeding "on your own" that you can talk to people who
know how to do it. the only upside of a commodities market is that lots
of people use the commodity, and that they can talk a lot among
themselves. so try to find people in your community that you can talk to
about Lisp. posting here is a great start in this regard.
oh, by the way, C/C++ are quite interesting languages from a marxist
point of view, too (it being May 1 and all): they are so bad that any
professional who wants to do interesting work needs to learn new tools
all the time and have the employer pay for it. the means of production
are thus removed from the hands of the owners into the hands of the
workers in a very new way. if the employers were any smart, they would
not use languages that removed _all_ their investments in their people
this way, because it is as unhealthy for a market with disproportionate
power in the hands of employees as it is with disproportionate power in
the hands of employers. shortly, therefore, smart employers will figure
it all out and look for stable, solid languages where programmers don't
need to be paid to acquire this week's skill set simply in order _not_ to
quit for the job that requires it... C/C++ are very bad for business,
which is another reason why you see so many companies hiring: it's such a
terrible tool that managers who used to or taught how to manage industry
will throw people are failing projects.
advertising is a symptom of insufficient demand or insufficient supply.
in many ways, competition itself stems from insufficiency in solving a
problem. also remember that quality can never compete with quantity.
please remember this when you use the consequences of competition as a
measure of success: it never is. success is when you have no competition
and you ensure that you match the demand. then you can go and talk to
people with a confidence that the desperately competing people can't. it
is also sage advice to remain sufficiently above it all that you don't
become a pawn in the games of the marketers. in other words: resist the
temptations of the mass market in any area where it matters to you.
#:Erik
Georges KO
> newspapers want ads are filled with requests for this kind of
programmers ,
The same here in Taiwan, where you can add VB, assembly and
hardware stuff as well. tw.bbs.comp.lang is full of BC++, VC++, etc.
articles, one won't find Lisp stuff (haven't seen the word for ages).
But, anyway, that's not going to stop me learning it because it's
great and ...
> If CLOS is so powerfull and (I read that) P Graham sold his software
(in
> CLOS) to Yahoo in 49 Million U$, How come CLOS is so obscure in the
> programming community ?
... even if you cannot use it as your primary language, as it
really opens your mind to a different way of thinking and solving
problems. Though I haven't used Common Lisp yet in any project (only
SIOD and Emacs Lisp), I have make sure that people in my departement
have heard about it, especially management. As I may do some kind of
official presentation of it in the future, I think it would be a good
idea to invite people from marketing, sales and field engineering to
come.
Joshua Scholar
wrote:
>* advanced object system with multiple dispatch. You can forget half
> of the Pattern book when you have these.
Then I'm going to have to figure out this multiple dispatch thing!
>
>* dynamic development environment that allows for incremental change
>
I guess it saves a lot on building tools, testing programs and user
interfaces for them when you can just apply your functions manually,
I'm jealous.
>* closures in stead of function pointers or similar half baked measures.
I still don't see the difference between closures and objects. A
closure is just a function or set of functions with some trapped
variables, right?
Josh Scholar
Raymond Wiker
> I still don't see the difference between closures and objects. A
> closure is just a function or set of functions with some trapped
> variables, right?
The Devil is in the details... In Common Lisp you can easily
define a closure that contains(?) two or more functions that access
a set of values. To do the same in C++, you have to
1) define a struct/class to hold the closure data
2) define classes for each of the functions in the closure
3) instantiate an object for the closure data (from [1])
4) instantiate objects for each of the classes from [2]. Each
of these objects need a reference to the closure object,
passed via the constructor.
Note that the classes defined in [1] and [2] are named
classes; in Common Lisp, there is no need to introduce classes for the
functions, and the closure itself is anonymous.
Compare the following:
(defun f(a)
(cons
(lambda () (setq a (1+ a)))
(lambda () (setq a (+ a a)))))
(setq g (f 2))
(funcall (car g))
(funcall (car g))
(funcall (cdr g))
(funcall (cdr g))
(setq h (f 2))
(funcall (car h))
(funcall (car h))
(funcall (cdr h))
(funcall (cdr h))
with:
class F {
public:
friend class Car {
public:
Car (F& f) : a(F.a)
{}
int operator()()
{ return a++; }
private:
int& a;
}
friend class Cdr {
public:
Cdr(F& f) : a(F.a)
{}
int operator()()
{ return a*=2; }
private:
int& a;
}
F(aa) : a(aa), car(this), cdr(this)
{}
private:
int a;
Car car;
Cdr cdr;
};
main()
{
F g(2);
F h(2);
cout << g.car() << endl;
cout << g.car() << endl;
cout << g.cdr() << endl;
cout << g.cdr() << endl;
cout << h.car() << endl;
cout << h.car() << endl;
cout << h.cdr() << endl;
cout << h.cdr() << endl;
}
--
Raymond Wiker, Orion Systems AS
+47 370 61150
Philip Morant
to think this?
I've dallied with functional languages before. I did LISP, and I did ML.
LISP was interesting, but ultimately impractical. The left and right
parenthesis keys wore out on my keyboard before I finished my second
program. Give me C++ any day. This sensible language spreads the load
out much more evenly across _all_ the number-keys in the top row of my
keyboard.
Johan Kullstam
> On Sat, 01 May 1999 06:14:09 GMT, cba...@2xtreme.net (Christopher R.
> Barry) wrote:
>
> >>... But C/C++
> >> doesn't work for some sets of things because it doesn't scale well, and
> >> since Lisp is designed to scale, it works better in really big situations.
>
> I REALLY should know better than to fall for the bait...
>
> C++ scales very well, thank you. C doesn't - that was the point of
> adding object oriented extensions.
it may have been the point, but imho it hasn't succeeded.
just to take one point, compare lisp macros to C++ templates or
preprocessor macros. lisp wins this contest handily.
in C++ templates are rock stupid and can only be used if you could
have mechanically swapped out the types in your editor and stamped out
multiple copies. the situatation for the different types must be
*exactly* the same.
lisp macros let you inspect and digest the arguments and do different
things depending on circumstances. if an algorithm shares 99% (or 1%)
of the same stuff, you can make a macro to share what you can and
special case what you cannot.
i think macros (amongst other things) are key to scaling.
--
johan kullstam
Erik Naggum
| This sounds like prejudice and bigotry to me.
some people see something they can hate whenever they get the chance.
| LISP was interesting, but ultimately impractical. The left and right
| parenthesis keys wore out on my keyboard before I finished my second
| program. Give me C++ any day. This sensible language spreads the load
| out much more evenly across _all_ the number-keys in the top row of my
| keyboard.
I'm truly relieved. I actually appreciate it when the people who hate me
are certified nut cases.
#:Erik
Pierre R. Mai
> lisp macros let you inspect and digest the arguments and do different
> things depending on circumstances. if an algorithm shares 99% (or 1%)
> of the same stuff, you can make a macro to share what you can and
> special case what you cannot.
>
> i think macros (amongst other things) are key to scaling.
Yes, and to connect to the other thread, parts of the MOP, Open
Implementation and Aspect Oriented Programming seem indeed to be the
extensions of that principle[1].
Regs, Pierre.
Footnotes:
[1] Although I find the names a bit hypey, but I guess in these days
you have to call Lisp macros "Dynamic Compilation Optimizers" or
"Semantic Oriented Transformations" to get your point across, with all
the mainstream hype around.
--
Pierre Mai <pm...@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Pierre R. Mai
> I've dallied with functional languages before. I did LISP, and I did ML.
> LISP was interesting, but ultimately impractical. The left and right
> parenthesis keys wore out on my keyboard before I finished my second
> program. Give me C++ any day. This sensible language spreads the load
> out much more evenly across _all_ the number-keys in the top row of my
> keyboard.
Hmm, I think you're a month and 2 days late, but just for the fun of
it:
If the spread of wear on the keys of your keyboard is the sole concern
in your programming, then either you are the sad victim of very shoddy
keyboards, or you have not understood what programming[1] is all about ;)
Regs, Pierre.
(Hmm, maybe I should get that saying trademarked and put on some nice
mugs. Anyone want to pre-order?)
Footnotes:
[1] That is in the sense of system and program construction, and not
some of the other things people currently seem to think programming
is, or might be...
Lyman S. Taylor
>
> On 01 May 1999 16:59:58 +0200, Lieven Marchand <m...@bewoner.dma.be>
> wrote:
>
> >* advanced object system with multiple dispatch. You can forget half
> > of the Pattern book when you have these.
> Then I'm going to have to figure out this multiple dispatch thing!
I think what he was trying to convey was not that you forget the
"patterns part" of the pattern's book, but the OTHER half of the
book. The periodic C++ kludges that you need to implement
some of those patterns.
For example the Vistor pattern, to a certain extent, IS multiple dispatch.
You don't have to hack up some explicit representation for it.
[ It is a matter open to debate as to how much CLOS and a dynamic
language make those patterns "simplistic" to implement.
You can find one side of the debate here:
http://www.norvig.com/design-patterns/
I also think the GoF (Gang of Four) probably picked a set of patterns
that include a larger set of things that C++ doesn't do well. Since
those
folks are one of their primary audiences, you might as well pick
patterns
that have a high "wow, doing that was so much more painful before"
effect. :-)
]
> >* closures in stead of function pointers or similar half baked measures.
>
> I still don't see the difference between closures and objects. A
> closure is just a function or set of functions with some trapped
> variables, right?
Closures are anonymous. You don't have to enlarge your global namespace
to use them. I suppose you could use nested classes to aviod conflicts.
However, that is using the outer class more as a "namespace" mechanism
than
as an "object" mechanism. Those aren't necessarily the same thing.
(defun add-n ( n )
#'(lambda (x) (+ n x)))
(mapcar (add-n 2) '( 1 2 3 4))
In C++, the mapcar equivalent could invoke a prespecified function on
the "closure object" to each value of the num-list to the "computation".
It would have to "know" what type of closure it is and what the "name"
of that function is.
In Lisp, the environment takes care of creating these sorts of "objects"
and of throwing them away when they aren't needed anymore. Therefore,
there is less "overhead" the user needs to worry about. Also, the
function
being passed is any function, closure or otherwise. There is no carefully
orchestrated mating dance you have to go through to use them.
It isn't that they aren't substitutable for each other... it is required
drudgery involved. On the flip side, closures make for awkward classes,
too.
---
Lyman
Lieven Marchand
> in C++ templates are rock stupid and can only be used if you could
> have mechanically swapped out the types in your editor and stamped out
> multiple copies. the situatation for the different types must be
> *exactly* the same.
>
Actually, C++ templates are Turing complete.
Yes, somebody actually implemented a Turing machine with them.
Then again, somebody did the same with vi macros.
--
Lieven Marchand <m...@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
Lieven Marchand
> >* dynamic development environment that allows for incremental change
> >
>
> I guess it saves a lot on building tools, testing programs and user
> interfaces for them when you can just apply your functions manually,
> I'm jealous.
>
Not only that. If you've made an error and try to do something that
doesn't make sense like adding a number to a symbol or taking the car
of an atom, your program doesn't happily do that to dump core some 5
functions deeper; no, you get put in a nice debugger where you can
inspect the whole call stack, the arguments of your function etc. and
after you've made the necessary adjustments you can even continue the
computation or restart from higher up the call stack.
Christopher R. Barry
> The left and right parenthesis keys wore out on my keyboard before I
> finished my second program. Give me C++ any day. This sensible
> language spreads the load out much more evenly across _all_ the
> number-keys in the top row of my keyboard.
You should swap "( )" and "[ ]", even if you are not a Lisp
programmer, since the parenthesis keys are used far more. Even in C
and C++ with all the "[ ]" and "{ }", a quick hack to count the
occurence of each character in a large source tree shows that the
parenthesis beat out the others combined comfortably. I regret not
having done this earlier.
If you are using X, add the following to your .Xmodmap (some unixes
have a different file like .xmodmaprc, I think):
!!! Lisp parenthesis bindings
!!! =========================
keysym 9 = 9 bracketleft
keysym 0 = 0 bracketright
keysym bracketleft = parenleft braceleft
keysym bracketright = parenright braceright
Then run "$ xmodmap .Xmodmap", or restart X. Manually running "$
xmodmap SOME_FILE" where SOME_FILE contains the above will always work
if you can't figure out your system's xmodmap startup file.
Christopher
Lieven Marchand
> Here in Israel , we have thousands of C\C++ programmers and so the
> newspapers want ads are filled with requests for this kind of programmers ,
> BUT never did I see a CLOS \ Lisp programmer want ad .!!!
>
> If CLOS is so powerfull and (I read that) P Graham sold his software (in
> CLOS) to Yahoo in 49 Million U$, How come CLOS is so obscure in the
> programming community ?
I think you've answered your own question in a way. Newspaper
advertising is a mass medium. It is appropriate to reach mass
audiences. The Lisp programming community is not that large and so job
announcements get distributed through other channels. I have
personally had job announcements through email, by friends or people
who get asked by their management to search for additional Lisp
programmers.
I've never seen newspaper ads for brain surgeons but I'm fairly
certain that a competent brain surgeon has no trouble finding a job.
please-reply...@thank.you
<kull...@ne.mediaone.net> wrote:
>lisp macros let you inspect and digest the arguments and do different
>things depending on circumstances. if an algorithm shares 99% (or 1%)
>of the same stuff, you can make a macro to share what you can and
>special case what you cannot.
I'm new to Lisp but am interested in macros. I'm wondering
if Lisp macros can be invoked by code that is in a
non-standard syntax, such that the macro processes the
syntax to make it work. For example, can a macro be called
by its name followed by a sequence of whitespace delimited
arguments with some defined pattern to end the list of
arguments, and the number of arguments found would
determine the macro processing? Or can a macro be
invoked by an arbitrary expression in an arbitrary syntax,
such that the parts of the expression would be the macro
arguments? The macro definition would have to define the
syntax, and there would have to be some way for the compiler
to recognize that syntax from knowledge of that macro.
And can you do things like rename the parenthesis characters
so some other character or symbol would represent them in
ordinary Lisp syntax?
Or if not that kind of stuff, what kind of stuff can you do
with Lisp macros?
Pierre R. Mai
> Actually, C++ templates are Turing complete.
>
> Yes, somebody actually implemented a Turing machine with them.
>
> Then again, somebody did the same with vi macros.
Yes, they are Turing complete (and have a syntax, if used to that
effect, that makes Turing machines look appealing in comparison),
but you'll still have huge problems using them to do more than
simple renaming operations on the C++ template itself. That IMHO
is the most hillarious thing about templates: In the effort to
create a very restricted kind of "macro system", C++ ended up with
a Turing complete macro language that still isn't overly useful for
usage in C++.
If they had written some sophisticated m4 macrology[1], it might have
been more useful, and less work... IMHO templates are just bondage &
discipline all over again.
Regs, Pierre.
Footnotes:
[1] Not that I condone use of m4 for this purpose ;) Today I'm more
convinced than ever, that "Thou shalt not have a macro language other
than thine language itself", or words to this effect...
Barry Margolin
<please-reply...@thank.you> wrote:
>I'm new to Lisp but am interested in macros. I'm wondering
>if Lisp macros can be invoked by code that is in a
>non-standard syntax, such that the macro processes the
>syntax to make it work. For example, can a macro be called
>by its name followed by a sequence of whitespace delimited
>arguments with some defined pattern to end the list of
>arguments, and the number of arguments found would
>determine the macro processing? Or can a macro be
>invoked by an arbitrary expression in an arbitrary syntax,
>such that the parts of the expression would be the macro
>arguments? The macro definition would have to define the
>syntax, and there would have to be some way for the compiler
>to recognize that syntax from knowledge of that macro.
A macro's parameters are the subexpressions of the expression of which it's
the head. For instance, in the expression (push <expression> <place>), the
PUSH macro will be given the unevaluated expressions <expression> and
<place> as its parameter. Since the function definition containing the
macro invocation will already have been processed lexically by the reader,
all the objects will have been read into internal data types.
This means that a macro can define arbitrary semantics to its syntax, but
it can't change the lexical nature of the language. For an example of a
macro that defines a pretty complex syntax of its own, see LOOP.
>And can you do things like rename the parenthesis characters
>so some other character or symbol would represent them in
>ordinary Lisp syntax?
These things can be done using reader macros. These are functions that are
invoked by the reader when it encounters a specific character during
lexical analysis. See the I/O chapter of CltL or the CLHS for details.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Brent A Ellingson
: * Philip Morant <p.mo...@edina.co.uk>
: | LISP was interesting, but ultimately impractical. The left and right
: | parenthesis keys wore out on my keyboard before I finished my second
: | program. Give me C++ any day. This sensible language spreads the load
: | out much more evenly across _all_ the number-keys in the top row of my
: | keyboard.
: I'm truly relieved. I actually appreciate it when the people who hate me
: are certified nut cases.
It is actually important to me that I believe Philip was joking when he
wrote this. Despite all the evidence to the contrary, I've managed to
convince myself that no-one in the world is that clueless. It will
destroy my world construct if people I respect take the above comments
by Philip seriously.
Erik, please don't take him seriously.
--
Brent Ellingson (bell...@badlands.NoDak.edu)
"It is amazing how complete is the delusion that beauty is goodness."
-- Leo Tolstoy
Joshua Scholar
>jo...@removethisbeforesending.cetasoft.com (Joshua Scholar) writes:
>
>> I still don't see the difference between closures and objects. A
>> closure is just a function or set of functions with some trapped
>> variables, right?
>
You're thinking in LISP.
There are lots of ways of doing this stuff in C++, none of which take
the 30 line to define that you took. When we really want all the
generality of a closure (which we rarely do) we use a template class
that will combine any function pointer with an object pointer to make
a closure that contains both and, (since all such templates are
derived from a single root), they can be passed around like anonymous
functions.
In any case, no matter what you do, the simple mapping from a closure
is one object = one activation record.
class f
{
int a;
public:
f(int _a):a(_a){}
int operator++() { return ++a; }
int Times2() { return a*=2; }
};
void main()
{
f g(2);
//when you really want all the generality of a closure
IntClosure<f> car(g, &f::operator ++);
IntClosure<f> cdr(g, &f::Times2);
cout << car() << endl;
cout << cdr() << endl;
//Note that the type isn't stuck being specific to this template
//instantiation
IntClosureBase *anyClosure = &car;
cout << (*anyClosure)() << endl;
//but most of the time you just want functions
cout << ++g << endl;
cout << ++g << endl;
cout << g.Times2() << endl;
cout << g.Times2() << endl;
//sometimes just having the function pointers is enough
int (f::*fn)();
fn = &f::operator ++();
cout << (g.*fn)() << endl;
fn = &f::Times2();
cout << (g.*fn)() << endl;
}
Off the top of my head, the template for closures of this type
signature would look like this:
class IntClosureBase
{
public:
virtual int operator() = 0;
};
template <class T> IntClosure : public IntClosureBase
{
T *object;
int (T::*function)();
public:
IntClosure(T* _o,(T::*_f)()):object(_o),function(_f){}
virtual int operator() { return (object->*function)(); }
};
We don't really call our template "Closures" but I'm being LISP
friendly.
Josh Scholar
Stig Hemmer
> I'm new to Lisp but am interested in macros. I'm wondering if Lisp
> macros can be invoked by code that is in a non-standard syntax, such
> that the macro processes the syntax to make it work.
[My answer is about Common Lisp, not Lisp in general]
A macro cannot change the basic syntax of parentesis, whitespace etc.
It is still damn powerful and very, very useful.
A macro _character_ on the other hand, can change anything.
So you cannot say
(with-angle-brackets <+ 2 <* 3 4>>)
But you _can_ say
?<+ 2 <* 3 4>>
by properly defining the meaning of "?"
For example, I have defined
?(func-name arg1 arg2)
to mean
(my-funcall #'func-name arg1 arg2)
Stig Hemmer,
Jack of a Few Trades.
Erik Naggum
| It is actually important to me that I believe Philip was joking when he
| wrote this. Despite all the evidence to the contrary, I've managed to
| convince myself that no-one in the world is that clueless.
the evidence to the contrary is overwhelming: there is no limit to
cluelessness, and no reason to presume cluelessness is a joke: failing to
realize that the clueless aren't joking is how most politicians manage to
pull their tricks on all of us.
| It will destroy my world construct if people I respect take the above
| comments by Philip seriously.
that's harsh, but I think you should just convince yourself otherwise.
#:Erik
Chris Double
> There are lots of ways of doing this stuff in C++, none of which take
> the 30 line to define that you took.
>
> [... example snipped... ]
One problem with your approach is returning the closure objects you
created:
IntClosure< afunc()
{
f g(2);
IntClosure<f> car(g, &f::operator ++);
return car;
}
This would result in a dangling reference to the destructed 'g' object
- as 'g' would have gone out of scope.
I miss closures and lambda functions the most when using some of the
stl algorithms. For example:
class Person
{
string getName();
};
vector<Person*> people = ...;
// Find a person with the name 'John':
vector<Person*>::iterator it = find_if(
people.begin(),
people.end(),
compose(
bind2nd(equal_to<string>(), string("John")).
mem_fun(&Person::getName)));
I would much prefer writing an anonymous function inline:
vector<Person*>::iterator it = find_if(
people.begin(),
people.end(),
method(Person* p) { return p->getName() == "John"; } );
Excuse the ugly syntax.
The main problem with closure simulators in C++ is the memory
management and providing access to the local variables without having
to create a class which copies and stores them.
Chris.
Espen Vestre
> You should swap "( )" and "[ ]", even if you are not a Lisp
> programmer, since the parenthesis keys are used far more.
My norwegian keyboard favours lisp over the C-syntax family of
languages, since {[]} are almost ultimately unaccessible ;-)
Having to type shift-8 and shift-9 isn't a big deal though, I
think my stiff left arm is caused by EscapeMetaAltControlShifts
- ingenious ideas for remapping emacs control combinations are
very welcome (is it possible, on a sun keyboard, to use the
caps lock as an ordinary modifier?).
--
espen
Raymond Wiker
> On 03 May 1999 12:39:47 +0200, Raymond Wiker <ray...@orion.no> wrote:
> > Compare the following:
> > (defun f(a)
> > (cons
> > (lambda () (setq a (1+ a)))
> > (lambda () (setq a (+ a a)))))
[ ... ]
> There are lots of ways of doing this stuff in C++, none of which take
> the 30 line to define that you took. When we really want all the
> generality of a closure (which we rarely do) we use a template class
> that will combine any function pointer with an object pointer to make
> a closure that contains both and, (since all such templates are
> derived from a single root), they can be passed around like anonymous
> functions.
>
> In any case, no matter what you do, the simple mapping from a closure
> is one object = one activation record.
>
> class f
> {
> int a;
> public:
> f(int _a):a(_a){}
> int operator++() { return ++a; }
> int Times2() { return a*=2; }
> };
>
> void main()
> {
> f g(2);
>
> //when you really want all the generality of a closure
>
> IntClosure<f> car(g, &f::operator ++);
> IntClosure<f> cdr(g, &f::Times2);
As somebody else already noted, this may give you a dangling
reference if you allow g to go out of scope. My version had the same
problem, so I won't stress this (although it *obviously* means that
in the general case, you have to build some sort of memory management
into your closure classes.)
Hum. If you count parentheses in the IntClosure* classes and
class f, you actually get a larger number than the 11 in my (borrowed)
Lisp example. There goes another argument against Lisp :-)
Also keep in mind that IntClosure is not sufficient; you have
to add similar classes if you want closures with other/different data
than just a single int, and also if you want "enclosed" functions with
other operation signatures.
Joshua Scholar
>jo...@removethisbeforesending.cetasoft.com (Joshua Scholar) writes:
>
>> There are lots of ways of doing this stuff in C++, none of which take
>> the 30 line to define that you took.
>>
>> [... example snipped... ]
>
>One problem with your approach is returning the closure objects you
>created:
>
>IntClosure< afunc()
>{
> f g(2);
>
>
> IntClosure<f> car(g, &f::operator ++);
> return car;
>}
>
>This would result in a dangling reference to the destructed 'g' object
>- as 'g' would have gone out of scope.
>
I know that, I was just simplifying the model. Most problems seem to
have fairly simple lifetimes, but I have templates that help me with
the ones that don't. My most common use for counted pointers, by the
way, is sharing an object between threads (I made the counting
atomic).
I've have yet to have a problem where I had to put all of these
templates together, but if you wanted all of the flexibility of gd
here it would be:
class IntClosureBase : public Counted
{
public:
virtual int operator() = 0;
};
template <class T> IntClosure : public IntClosureBase
{
CountedPtr<T> object;
int (T::*function)();
public:
IntClosure(CountedPtr<T> _o,(T::*_f)()):object(_o),function(_f){}
virtual int operator() { return ((*object).*function)(); }
};
class f : public Counted
{
int a;
public:
f(int _a):a(_a){}
int operator++() { return ++a; }
};
CountedPtr<IntClosureBase> foo()
{
CountedPtr<IntClosureBase> car =
(IntClosureBase *)new IntClosure<f>(new f(2),
&f::operator ++);
cout << ++ *car << endl;
return car;
}
>... compose(
> bind2nd(equal_to<string>(), string("John")).
> mem_fun(&Person::getName)) ..
I've never seen an expression like this. Perhaps I misunderstand, but
it looks to me like you're fighting the language in order to get
anonymous functions, FORGET ANONYMITY! You're sacrificing readable
syntax just in order to not name something - that's a rip off. So the
function needs a name, so what?
Josh Scholar
P.S In case it helps, here is the counted pointer classes and
templates (specialized for windows multitasking):
struct Counted
{
LONG refCount;
Counted():refCount(0){}
};
template <class T> class CountedPtr
{
protected:
T *letter;
public:
void decRefCount()
{
if (letter)
{
if ( InterlockedDecrement(&letter->refCount) <= 0)
{
delete letter;
letter = NULL;
}
}
}
void incRefCount()
{
if (letter)
{
InterlockedIncrement(&letter->refCount);
}
}
CountedPtr():letter(NULL){}
CountedPtr(const CountedPtr<T> &w);
CountedPtr(const T *w);
operator T *(){ return letter; }
operator const T *()const{ return letter; }
CountedPtr<T> & operator=(const T *w);
CountedPtr<T> & operator=(const CountedPtr<T> &w);
operator bool() const
{ return letter!=NULL; }
int operator !() const
{ return letter==NULL; }
int operator==(const CountedPtr&r)
{ return letter == r.letter; }
const T & operator*() const
{ return *letter; }
T & operator*()
{ return *letter; }
T * operator->()
{ assert(letter); return letter; }
T * operator->()const
{ assert(letter); return letter; }
~CountedPtr();
};
template <class T> CountedPtr<T> & CountedPtr<T>::operator=(const T
*w)
{
if (w) InterlockedIncrement(& (const_cast<T *>(w)->refCount));
decRefCount();
letter= const_cast<T *>(w);
return *this;
}
template <class T> CountedPtr<T> & CountedPtr<T>::operator=(const
CountedPtr<T> &w)
{
return *this = (const T *)w;
}
template <class T> CountedPtr<T>::CountedPtr(const CountedPtr<T> &w)
:letter(const_cast<T *>(w.letter))
{ incRefCount(); }
template <class T> CountedPtr<T>::CountedPtr(const T *w):letter((T
*)w)
{ incRefCount(); }
template <class T> CountedPtr<T>::~CountedPtr()
{ decRefCount(); }
Joshua Scholar
> Also keep in mind that IntClosure is not sufficient; you have
>to add similar classes if you want closures with other/different data
>than just a single int, and also if you want "enclosed" functions with
>other operation signatures.
Which is an advantage if you believe in type checking!!!!
I WANT the compiler to make sure that every function is only used with
compatable parameters!
Joshua Scholar
Raymond Wiker
This is probably not very helpful, but anyway... Simple type
compatibility is the only C++ can check statically - for example, you
can have a function that expects as an argument a value from {1, 2,
5}. There's no way you can check this statically, which means that you
ultimately have to resort to run-time checking, which (as with
closures) is more painful to do in C++ than in Common Lisp.
My point? I do not think that the advantages of a dynamic type
system are worth trading in for a flawed static type system.
Philip Morant
There's not such a huge difference between all these different computer
landwiches. After all, they all get compiled down to machine code
eventually. Sure, some landwiches bring useful abstractions to the
science, and, naturally, some more so than others. To anyone who reads
this newsgroup, LISP seems to be the biz because of the quality and
usefulness of the said abstractions (by the way, what is all this stuff
about Turing-completeness?). But, given that it all boils down to
machine instructions in the end, what price do we pay for all the
convenience we gain? There has to be one.
C and C++ map more closely to the Chicken Pulley Unit's
instruction set than any other high-level landwich. You could write a
LISP compiler in C, but you'd have quite a problem if you wanted to
write a C compiler using LISP. Isn't it clear, if you think a priori
(and, recalling a previous argument on comp.lang.lisp, 13 March 1999,
started by David Hanley, I think that a posteriori reasoning is less
convincing here), that C++ is always going to be the landwich of choice
for writing fast code? Try asking the folk down at Counterpane. They
count every one of the CPU clock cycles that make their algorithm go.
See if they'll switch from Assembly landwich to LISP.
Eventually, there will come a point in human history (if we
don't greenhouse ourselves all to death first) where all the necessary
functionality has been provided. People will only write new code to
indulge themselves. When this happens, the only serious work will be
the optimisation of what has already been done. Programs will edited
until they can be formally verified, and then all the dead wood will be
taken out. It seems to me that the more abstractions that a program
uses, the more work will be involved in optimising it.
-----Original Message-----
From: Erik Naggum [mailto:er...@naggum.no]
Posted At: 04 May 1999 01:07
Posted To: lisp
Conversation: Newbie questions
Subject: Re: Newbie questions
Espen Vestre
> Eventually, there will come a point in human history (if we
> don't greenhouse ourselves all to death first) where all the necessary
> functionality has been provided. People will only write new code to
> indulge themselves.
I've heard this argument, or variants of it, for 20 years now.
It has been partly responsible from scaring good students away
from CS studies, because some smartasses thougth that the demand for
good programmers would *sink* (while all the existing mediocre
programmers were out there IRL providing Y2K trouble and other
kinds of "functionality").
But you're certainly giving it a new twist: You're trying to use
it as an argument for writing *less* *abstract* code!
I can only *sigh* :-[
--
espen
Marc Battyani
Philip Morant <p.mo...@edina.co.uk> wrote in message
news:54EC8A7BBA7FD111AE40006097706C7A10F94D@TREBBIANO...
...
> (and, recalling a previous argument on comp.lang.lisp, 13 March 1999,
> started by David Hanley, I think that a posteriori reasoning is less
> convincing here), that C++ is always going to be the landwich of choice
> for writing fast code? Try asking the folk down at Counterpane. They
> count every one of the CPU clock cycles that make their algorithm go.
> See if they'll switch from Assembly landwich to LISP.
I you are into real fast code you can't beat the VHDL language which
translate
directly to hardware.
The LISP + VHDL association is hard to beat!
You can also see C++ as a portable assembly language and generate it from
LISP.
We use LISP to convert lots of legacy C++ objects into COM objects.
Marc Battyani
Ian Wild
>
> You could write a
> LISP compiler in C, but you'd have quite a problem if you wanted to
> write a C compiler using LISP.
Haven't you got this arse about face?
I can't see how you'd even /start/ writing a Lisp
compiler in C...
Tim Bradshaw
> You're thinking in LISP.
> There are lots of ways of doing this stuff in C++, none of which take
> the 30 line to define that you took. When we really want all the
> generality of a closure (which we rarely do) we use a template class
> that will combine any function pointer with an object pointer to make
> a closure that contains both and, (since all such templates are
> derived from a single root), they can be passed around like anonymous
> functions.
I can't understand your definition, which I elided, but each of these
things needs a separate declaration right? You need to say for each
thing which other things you want it to close over and what the types
are and so on for a hundred miles. You can use templates to make it
only 50 miles, perhaps.
In Lisp you don't need any of that, functions just close over
everything that is lexically apparent to them, there is no syntax at
all. In Lisp functions are instances of anonymous classes which you
define on the fly.
--tim
Tim Bradshaw
> I've dallied with functional languages before. I did LISP, and I did ML.
> parenthesis keys wore out on my keyboard before I finished my second
> program. Give me C++ any day. This sensible language spreads the load
> out much more evenly across _all_ the number-keys in the top row of my
> keyboard.
Actually, what most Lisp people do nowadays is simply take all those
useless function keys that modern keyboards have and define them as
paren keys. Only a few weeks training is needed to even out the wear
patterns by round-robining on all those spare keys. I have 30 or 40
extra function keys on my keyboard to solve this problem. I believe
people are also working on `hot-swappable' keyboards: if one of the
paren keys fails, it's dynamically mapped to an unused key (one of the
function keys usually), and you can carry right on typing while an
engineer is called to swap out the failed key.
The tragic mistake made by the lisp machines was not to realise that
large numbers of general-purpose keys can be used for Lisp quite
efficiently given a sufficiently smart keyboard compiler, and instead
to provide special hardware-support for really good paren keys. They
were fun to use, and the keyboards fitted on a single desk unlike
modern ones, but they were obviously ultimately doomed.
Of course, C++ will probably have this kind of dynamic keyboard
technology within a few years.
--tim
Marco Antoniotti
Philip Morant <p.mo...@edina.co.uk> writes:
...
> C and C++ map more closely to the Chicken Pulley Unit's
> instruction set than any other high-level landwich. You could write a
> LISP compiler in C, but you'd have quite a problem if you wanted to
> write a C compiler using LISP.
Are you kidding or clueless? I hope the first. Otherwise may the
NAGGUM be unleashed over you! :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Nick Levine
> works. (automatic completion of symbols names) - I once downloaded FreeLISP
> and then lost the copy. I can remeber that it reminded me of VitalLISP -
> Can anybody tell me where can I find the latest version that Harlquin
> released ?
Freelisp was withdrawn last year and replaced by the LispWorks Personal
Edition, see:
http://www.harlequin.com/products/ads/lisp/
Meta-Control-i completes symbols by looking them up in package tables.
Meta-/ is dynamic completion, looking symbols up in the current editor buffer.
- nick
Kent M Pitman
http://world.std.com/~pitman/pfaq/cross-posting.html ]
I know it's all most too much to hope for, but I nevertheless wish
this discussion will be moved off of comp.lang.lisp.
If people want to debate the merits of a good AI language, then I think
comp.ai is adequate for that. Indeed, questions about what the "right
language" is are always best answered in a forum appropriate to the need.
See my pfaq entry above for a longer-winded explanation of why I think
it's a bad idea to drag down comp.lang.lisp in this discussion.
If this were a comp.lang.lisp-only discussion, there are things I would say
relevant to this topic, but I don't want to get involved in some vast
multi-forum flamefest whose purpose seems more to consume resources than
to hear a coherent answer.
JMO.
Link Davis
everything, such as the hard-to-hit keys you're talking about. You can also
program Dragon Dictate to paste in several lines of code. Beats either
typing it from scratch or cut-n-paste.
Tim Bradshaw <t...@tfeb.org> wrote in message
news:ey34slt...@lostwithiel.tfeb.org...
Christopher R. Barry
> Having to type shift-8 and shift-9 isn't a big deal though, I
> think my stiff left arm is caused by EscapeMetaAltControlShifts
> - ingenious ideas for remapping emacs control combinations are
> very welcome (is it possible, on a sun keyboard, to use the
> caps lock as an ordinary modifier?).
Swapping Control_L and Caps_Lock is extremely common. If you want to
do that, then [copy and paste from the xmodmap manpage]:
One of the more irritating differences between keyboards
is the location of the Control and Shift Lock keys. A
common use of xmodmap is to swap these two keys as fol
lows:
!
! Swap Caps_Lock and Control_L
!
remove Lock = Caps_Lock
remove Control = Control_L
keysym Control_L = Caps_Lock
keysym Caps_Lock = Control_L
add Lock = Caps_Lock
add Control = Control_L
I personally made Caps_Lock run "complete", though I've yet to
massively overhaul completion.el or write my own thing from scratch
like I've been meaning to do Any Day Now. I originally wanted to make
Caps_Lock do "complete" and shift-Caps_Lock do the actual
uppercase-lock, but making shift-CapsLock distinguishable from plain
old Caps_Lock to X seems all but impossible. I instead in extremely
kludgy fashion swapped F6 and Caps_Lock. Bleah.
Christopher
Bagheera
but the people on comp.ai would have us believe that this is the correct
forum (see recent threads on comp.ai).
I think it is a conspiracy to undermine the two groups
(shifty look)
The proper forum for language debates is undoubtedly comp.programming
--
Bagherra <jae...@frenzy.com>
http://www.frenzy.com/~jaebear
"What use is it to have a leader who walks on water
if you don't follow in their footsteps?"
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Bagheera
Raymond Wiker <ray...@orion.no> wrote:
> jo...@removethisbeforesending.cetasoft.com (Joshua Scholar) writes:
> > On 04 May 1999 10:44:14 +0200, Raymond Wiker <ray...@orion.no> wrote:
> > > Also keep in mind that IntClosure is not sufficient; you have
> > >to add similar classes if you want closures with other/different data
> > >than just a single int, and also if you want "enclosed" functions with
> > >other operation signatures.
> > Which is an advantage if you believe in type checking!!!!
> > I WANT the compiler to make sure that every function is only used with
> > compatable parameters!
> This is probably not very helpful, but anyway... Simple type
> compatibility is the only C++ can check statically - for example, you
> can have a function that expects as an argument a value from {1, 2,
> 5}. There's no way you can check this statically, which means that you
> ultimately have to resort to run-time checking, which (as with
> closures) is more painful to do in C++ than in Common Lisp.
I think what josh is getting at is that in C++, it prevents you
from stuffing an 8byte value into a two byte parameter. If you
don't have type checking for this sort of thing, you can easily
overflow your calling stack, which is a bad no-no. Basically it
is a matter of the program protecting itself from the programmer.
I'm sure there are lots of ways to shoot yourself in the foot with
Lisp. C++ is a concerted effort to reduce that possibility of
self-destruction. Sure I can get around alot of the constructs
that offer protection in C++, but a properly versed programmer is
not likely to "hang themselves" with the rope the language gives
them.
True, Lisp gives you the option of run-time program correction...
but sometimes requirements don't allow that comfort.
My whole take on it?
"Tastes Great....Less Filling"
Paolo Amoroso
wrote:
> Or if not that kind of stuff, what kind of stuff can you do
> with Lisp macros?
You may check the best source on Common Lisp macros:
"On Lisp - Advanced Techniques for Common Lisp"
Paul Graham
Prentice Hall, 1994
ISBN 0-13-030552-9
Paolo
--
Paolo Amoroso <amo...@mclink.it>
Paul Rudin
> (by the way, what is all this stuff
> about Turing-completeness?).
Turing completeness is the property of being able to implement the
same algorthims as a Turing machine. There are good reasons why this
is a limit on the algorthims that can possibly be implemented on a
computer.
[Incidentally, this is the smallest set of functions that includes the
zero function; the successor function and is closed under projection,
composition, (primitive) recursion, and minimalisation.]
Most computer languages in use today are Turing complete, so if you
can do it in one language, you can do it in another, it's just a
question of how much effort is involved. IIRC, one interesting
exception is the Charity language; programs in which are guaranteed to
terminate.
Christopher R. Barry
> I know it's all most too much to hope for, but I nevertheless wish
> this discussion will be moved off of comp.lang.lisp.
>
> If people want to debate the merits of a good AI language, then I think
> comp.ai is adequate for that.
Sadly, it isn't. "LISP can't do such and such that C++ can" is all you
hear. There are very few knowledgable Lisp types reading comp.ai, or
posting at any rate.
> Indeed, questions about what the "right language" is are always best
> answered in a forum appropriate to the need.
If you discuss Lisp in any forum other than comp.lang.lisp you'll just
get people that talk about "LISP being slow" and "LISP has no STL or
virtual functions or interfaces" and blah blah....
> If this were a comp.lang.lisp-only discussion, there are things I
> would say relevant to this topic, but I don't want to get involved
> in some vast multi-forum flamefest whose purpose seems more to
> consume resources than to hear a coherent answer.
Things were turning entirely into a discussion of Lisp vs. C++ and the
only group I know of that has people knowledgable enough of both to
make statements based on extensive experience with each instead of
heresay and what they remember reading about "LISP" in some magazine
article 10 years ago is comp.lang.lisp.
comp.ai should have been removed from the delivery headers though.
Christopher
Duane Rettig
> In article <87aevld...@foobar.orion.no>,
> Raymond Wiker <ray...@orion.no> wrote:
> > jo...@removethisbeforesending.cetasoft.com (Joshua Scholar) writes:
> > > On 04 May 1999 10:44:14 +0200, Raymond Wiker <ray...@orion.no> wrote:
> > > > Also keep in mind that IntClosure is not sufficient; you have
> > > >to add similar classes if you want closures with other/different data
> > > >than just a single int, and also if you want "enclosed" functions with
> > > >other operation signatures.
> > > Which is an advantage if you believe in type checking!!!!
> > > I WANT the compiler to make sure that every function is only used with
> > > compatable parameters!
> > This is probably not very helpful, but anyway... Simple type
> > compatibility is the only C++ can check statically - for example, you
> > can have a function that expects as an argument a value from {1, 2,
> > 5}. There's no way you can check this statically, which means that you
> > ultimately have to resort to run-time checking, which (as with
> > closures) is more painful to do in C++ than in Common Lisp.
>
> I think what josh is getting at is that in C++, it prevents you
> from stuffing an 8byte value into a two byte parameter. If you
> don't have type checking for this sort of thing, you can easily
> overflow your calling stack, which is a bad no-no. Basically it
> is a matter of the program protecting itself from the programmer.
This sounds more like an anti-Forth argument, rather than an anti-lisp
argument. There is no such danger of overflowing the call-stack in
lisp due to argument mismatches; there are far more efficient ways
to accomplish stack overflows ...
> I'm sure there are lots of ways to shoot yourself in the foot with
> Lisp. C++ is a concerted effort to reduce that possibility of
> self-destruction. Sure I can get around alot of the constructs
> that offer protection in C++, but a properly versed programmer is
> not likely to "hang themselves" with the rope the language gives
> them.
Interesting take. I personally find lisp very robust.
> True, Lisp gives you the option of run-time program correction...
Not only run-time correction, but _programmed_ run-time correction...
> but sometimes requirements don't allow that comfort.
What times are those?
> My whole take on it?
>
> "Tastes Great....Less Filling"
And my take: If you shoot yourself in the foot in lisp, your foot
hurts. If you shoot yourself in the foot in C++, you die.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Sunil Mishra
> Kent M Pitman <pit...@world.std.com> writes:
>
> > I know it's all most too much to hope for, but I nevertheless wish
> > this discussion will be moved off of comp.lang.lisp.
> >
> > If people want to debate the merits of a good AI language, then I think
> > comp.ai is adequate for that.
>
> Sadly, it isn't. "LISP can't do such and such that C++ can" is all you
> hear. There are very few knowledgable Lisp types reading comp.ai, or
> posting at any rate.
I used to read comp.ai. Got tired of the inane topics and the general
disregard for the state of the art in AI research. (Some called this
position elitist when the issue was brought up, IIRC.) There were far too
many posters with little knowledge of the history of AI making just plain
inaccurate statements. One thing that struck me was the number of posts
that contained little more than private musings based on nothing but
uninformed intuition. In short, too little signal, too much noise. Having
it moderated might improve things... We'll see.
Aside for my personal reasons for avoiding comp.ai, if you think about it,
AI is not really tied to lisp that strongly. Lisp (or any other language)
should ideally not be a topic of discussion if your concern is AI. The
issue should be techniques. Anyone going down the path of "mine is better
than yours" should definitely be rebuked, but (as Kent has so appropriately
pointed out) handing the problem to comp.lang.lisp is certainly not the
solution. Nothing as far as I can tell will change a closed mind.
> > Indeed, questions about what the "right language" is are always best
> > answered in a forum appropriate to the need.
>
> If you discuss Lisp in any forum other than comp.lang.lisp you'll just
> get people that talk about "LISP being slow" and "LISP has no STL or
> virtual functions or interfaces" and blah blah....
>
> > If this were a comp.lang.lisp-only discussion, there are things I
> > would say relevant to this topic, but I don't want to get involved
> > in some vast multi-forum flamefest whose purpose seems more to
> > consume resources than to hear a coherent answer.
>
> Things were turning entirely into a discussion of Lisp vs. C++ and the
> only group I know of that has people knowledgable enough of both to
> make statements based on extensive experience with each instead of
> heresay and what they remember reading about "LISP" in some magazine
> article 10 years ago is comp.lang.lisp.
As true as that may be, I doubt any of them would be really interested in
what we have to say. I have found a similar attitude as the C++ advocate
had over here. I had a short discussion about lisp with a student well
versed in C/C++, and the functional style really bugged him. He could not
believe that anyone could do decent software engineering without type
checking, and nothing I said would make a difference to him. It seems as
though breaking out of that school of thought is *really* hard. Are there
any software engineers (research oriented or otherwise) that take the lisp
model of writing a program seriously, other than for prototyping etc? (This
is not a rhetorical question.)
Sunil
Joshua Scholar
[Followup to comp.lang.lisp]
On 05 May 1999 06:55:35 +1200, Chris Double <ch...@cnd.co.nz> wrote:
>...
>But getting back to the main subject. You mentioned in a previous post
>that you didn't see a use for closures. Yet you have the counted
>pointer and closure classes that you've created to try and emulate
>some of the functionality. This sort of thing is much easier to use
>and much more general if it is provided by the language itself. In
>Dylan the transform code above is:
>
>destination := map(curry(\+, 1), source);
>
>Chris.
You're right. I first played with closures in languages that didn't
have object libraries (versions of CLisp and Scheme), and I got the
impression that people mostly used closures in places where a regular
object would do just fine. Places where instead of passing a few
closures, you could pass a whole object and the code knows exactly
what object functions it wants to call. Since there is a lot of
overlap and closures take less keystrokes and namespace people
probably still do use closures mostly in places where simple objects
would do.
Of course you can simulate any subset of the semantics of a closure
with objects, but since people started arguing that supporting a lot
of them took too many keystrokes I ended up trying to "prove" that I
could use templates to define objects that have ALL of the semantics
of a closure, including the anonymity of the functions and the
lifetime issue of a shared activation record.
This wasn't my original point - I think that the exact combination of
semantics of a closure is rarely needed.
And for what little it's worth, the templates we use at work are not
called "Closures" I just renamed them in order to draw a parallel.
And then I felt a little sheepish that I had said "What are closures
for?" and then simply shown that I could create closures in C++. I
know you don't quite agree because you object to "polluting" the
namespace. But my point of view on that is that what is named and
what isn't is always very arbitrary, depending on your approach and
style, and if it also depends on what language you are using, so be
it. The cost of a name is basically nil, I'm not going to make a big
deal out of it.
Josh Scholar
Tim Bradshaw
> C and C++ map more closely to the Chicken Pulley Unit's
> instruction set than any other high-level landwich. You could write a
> LISP compiler in C, but you'd have quite a problem if you wanted to
> write a C compiler using LISP.
Symbolics had C, Fortran and I think pascal compilers written in, erm,
Lisp.
I was really disappointed when I found they had an X implementation,
only to discover when looking at the source that it was just MIT X,
compiled with their C compiler.
--tim
Joshua Scholar
[Followup to comp.lang.lisp]
Well Bagheera didn't state the problem quite right. The overall point
is that type checking saves you from tons and tons of late night typos
and logic errors.
And the time is when you have to deliver working code in the morning
and there isn't enough budget for more than a week more of testing!
So any error that gets into the code is far too many. It happens all
the time in the game business.
<evil voice> WELCOME TO MY WORLD. HA HA HA HA HA! </evil voice>
Passing the wrong parameter, parameters in the wrong order, the wrong
subfield etc. are common typos and often caught by the compiler -
especially if you design your class interfaces to catch as much as
possible. In code that rarely runs or isn't expected to run under
normal conditions, this sort of correctness checking is very
important.
Joshua Scholar
Erik Naggum
| I think what josh is getting at is that in C++, it prevents you from
| stuffing an 8byte value into a two byte parameter. If you don't have
| type checking for this sort of thing, you can easily overflow your
| calling stack, which is a bad no-no. Basically it is a matter of the
| program protecting itself from the programmer.
this is not what static types are about. having static types _allows_ a
compiler to skimp on (some) run-time type checking in the belief that all
or most of the necessary type checking can be performed compile-time.
this is, of course, as ridiculous a desire as wanting the compiler to
prove the program free of any other bug, and has confused people to no
end about what types are.
the important property of static types is not what would happen if you
took it away, but what happens when you introduce it: you can take away
some fences that you presume the compiler took care of, but the only
actual consequence is that you leave open the whole area of precisely the
kind of bugs you mistakenly associate with languages and compilers with
dynamic types. even in the machine language, there are types and
associated operations on them. some of the types may look very much the
same when stored as bits in machine memory, but that is really an
artifact of a context-dropping human viewer -- the archetypical example
is the C notion of a pointer and its interchangeability with integers of
some size. the stored pointer doesn't become an integer any more than a
parked car becomes a source of money when broken into by a thief -- in
both cases, it's how you use it that matters, and we have laws and
regulations that say that parked cars are just that and not sources of
money. if you willfully transgress these laws, you can turn a parked car
into a source of money, but most people know they're doing something
wrong when they do this, and even the lowliest thief who knows this is
morally superior to the C programmer who abuses the bits of a pointer as
an integer and takes it for granted.
any form of representation is subject to interpretation by a conscious
mind that imputes meaning to the inherently meaningless. if, however,
you partition the otherwise confusing representation space into various
categories and make certain that you know which category something is of
even at run-time, you don't get into the kinds of silly troubles that
C/C++ fans think static typing got them out of: they never happen in the
first place. or, to be more precise, any powerful system will allow you
to break the rules, but it has to be on purpose, not by silly mistake,
which is, unfortunately, what C/C++ give you absent static type checks.
so, "if you don't have type checking for this sort of thing", you move
that type checking into the run-time, instead, and you _can't_ overflow
your calling stack. I'd argue that _dynamic_ typing is how a program
protects itself from the programmer, and static typing that makes a whole
lot of errors and problems _arise_.
| I'm sure there are lots of ways to shoot yourself in the foot with Lisp.
how did you acquire your certainty about this who know nothing about what
to do if you don't do static typing? (hint: if you want to destroy the
world through Lisp, you have to work hard at it. if you want to destroy
the world through C/C++, simply derefence a stray pointer or _forget_ to
check for NULL, which is _manual_ run-time type checking.)
| C++ is a concerted effort to reduce that possibility of self-destruction.
it must be Slobodan Milosovic's favorite programming language, then.
| True, Lisp gives you the option of run-time program correction... but
| sometimes requirements don't allow that comfort.
you know, I'm a little irritated by the ignorant newbies who come here
and on other lists and aske all sorts of inane questions, but it beats
having to deal with ignorants who think they now enough to make blanket
statements.
#:Erik
Joshua Scholar
[Followup-to comp.lang.lisp]
>....
>| C++ is a concerted effort to reduce that possibility of self-destruction.
>
> it must be Slobodan Milosovic's favorite programming language, then.
>
Oh, grow up.
>| True, Lisp gives you the option of run-time program correction... but
>| sometimes requirements don't allow that comfort.
>
> you know, I'm a little irritated by the ignorant newbies who come here
> and on other lists and aske all sorts of inane questions, but it beats
> having to deal with ignorants who think they now enough to make blanket
> statements.
>
>#:Erik
Once again, grow up.
Joshua Scholar
Chris Double
> >... compose(
> > bind2nd(equal_to<string>(), string("John")).
> > mem_fun(&Person::getName)) ..
>
> I've never seen an expression like this. Perhaps I misunderstand, but
> it looks to me like you're fighting the language in order to get
> anonymous functions, FORGET ANONYMITY!
I don't think using standard library functions and idioms could be
called 'fighting the language'. With the exception of 'compose' of
course. 'compose' never made it into the standard but was in the
original STL and is provided by the SGI STL libraries. 'bind2nd',
'mem_fun' and 'equal_to' are in the standard and the sort of code
above is a reasonably common idiom in standard C++ - certainly not
'fighting the language'.
> You're sacrificing readable syntax just in order to not name
> something - that's a rip off. So the function needs a name, so
> what?
The amount of overhead in writing a function or class member to
perform small operations can be larger than you realise. Every time I
want to do something like the above i'd have to write a function, give
it a name, pollute some namespace somewhere to do it. It also removes
locality of code. The function to do the comparison for the specific
string won't be located near where it is done. If I want to add one to
every item in a vector I don't want to write a new function just to do
this. I want to be able to 'inline' some code to make it easier to
read:
vector<int> source = [...];
vector<int> destination;
transform(
source.begin(),
source.end(),
back_inserter(destination),
bind1st(plus<int>(), 1));
I could write an iterative loop to do the above but there is more
likelyhood of error (getting loop termination incorrect, etc). Better
to reuse the standard library components.
for(vector<int>::iterator it = source.begin();
it != source.end();
++it)
{
destination.push_back(*it + 1);
Erik Naggum
| Oh, grow up.
:
| Once again, grow up.
it is amusing to give simple people something trivial to hold on to and
watch them completely miss everything more challenging than kindergarten
responses. you were tested, Joshua, and you failed, unsurprisingly.
next time, do yourself a favor and consider getting the jokes and the
ridicule and respond to the issues you now conveniently elided. that
would _show_ us that you have yourself grown up.
it appears that you belong in comp.ai, still. followups redirected.
#:Erik
Kent M Pitman
> Well Bagheera didn't state the problem quite right. The overall point
> is that type checking saves you from tons and tons of late night typos
> and logic errors.
Nothing in CL forbids you from type-declaring every variable. Knock
yourself out. Don't forget to send bug reports when the compiler
fails to use them well or flag problems, so your vendor will know
you care.
But the language itself already supports this. It's simply up to the
market to decide if this is what stands between it and success. I doubt
it is, but you're welcome to make the case otherwise.
> And the time is when you have to deliver working code in the morning
> and there isn't enough budget for more than a week more of testing!
> So any error that gets into the code is far too many. It happens all
> the time in the game business.
This is a pure engineering choice. To the extent you want to make it,
you're right. But there are many things in the world that you don't
know well enough at code-writing time and still have to code up.
If the very same compiler won't compile until the code is type-safe,
that code can't be delivered. What is right depends on your need
(based on your personal requirements, project requirements, and
customer needs).
I won't try to tell you not to write declarations if you won't try to
tell me that I must write them. As to the question of how they are
used, the language is designed in a way that it doesn't affect the
semantics--it's purely a performance issue, to be sorted out by
individual vendors as they see fit. There are a lot of vendors. Surely
one of them will care. Or grab CMU CL and start from there. It cared
a lot about declarations.
> <evil voice> WELCOME TO MY WORLD. HA HA HA HA HA! </evil voice>
>
> Passing the wrong parameter, parameters in the wrong order, the wrong
> subfield etc. are common typos and often caught by the compiler -
Yes, already done. But remember also that passing the wrong parameter
may not be fatal. Error handlers may catch it. The code may be going to
get updated before it's run. The caller may be wrong or the callee.
I would not like to see any of these flexibilities removed.
> especially if you design your class interfaces to catch as much as
> possible.
Lisp is a language for being flexible. That is why it has survived
all these years. I think it's fine for you to give up your flexibility
on a case by case basis, but please don't confuse your personal need
with a design theory. None of the things you're saying are false but
neither are they "uniquely determined points of view".
> In code that rarely runs or isn't expected to run under
> normal conditions, this sort of correctness checking is very
> important.
You don't say what your point is.
This sounds like fodder for bug reports. IMO, There is nothing wrong
with the language in this regard. You're welcome to disagree, but
please be specific about what you'd like to see done instead so that
people (including myself) can evaluate whether your perfect world
infringes theirs.
Erik Naggum
| The overall point is that type checking saves you from tons and tons of
| late night typos and logic errors.
well, type checking is necessary, but it appears that you don't know the
difference between compile-time and run-time type checking, and assume
that without compile-time type checking, there wouldn't be any. _that_
would be a source of tons and tons of typos and logic errors. however,
the ridiculously simple-minded static type checking in C++ restrict you
to a single line of inheritance, has no universal supertype, and offers
no way to know the type of an object at run-time except by embedding it
in a class and using RTTI. that is sufficiently inconvenient that the
customary way to deal with multiple types of return values is to use an
"invalid value", like the infamous NULL pointer.
| Passing the wrong parameter, parameters in the wrong order, the wrong
| subfield etc. are common typos and often caught by the compiler -
| especially if you design your class interfaces to catch as much as
| possible. In code that rarely runs or isn't expected to run under normal
| conditions, this sort of correctness checking is very important.
it sounds like you think you're telling people something new. why? this
is so obvious it's been taken care of in much better than to require the
programmer to declare the types of _all_ objects _explicitly_, which is,
unsurprisingly, a major source of typos and logic errors, not to mention
recompilation and header file (interface) changes that need to propagate
to other team members.
oh, by the way, since I see your favorite argument coming: knowing C++ is
part of growing up. discarding C++ is a matter of course once you have
grown up. explicit type declarations is useful for new programmers the
same way bicycles for kids have support wheels. few kids argue against
their removal.
#:Erik
Joshua Scholar
I want to make it clear that I haven't been trying to argue that C++
is better than LISP.
What happened is that I stumbled into a thread on comp.ai where a few
people, a couple of whom I know enough about to respect, were arguing
that LISP is more appropriate than C++ for AI.
Now in my work (game programming) I don't really have a choice, I more
or less have to use C++.
What I wanted to find out is what exactly were the reasons that some
preferred LISP so that I could abstract those strengths or methods
into my work, under the limitations I work under.
Unfortunately I got sidetracked by an evangelist who was more
interested in convincing me to use a specific language than in talking
about programming techniques and I also ended up trying to defend and
explain the limitations I work under - none of which is actually an
attack on the usefulness of LISP. The strongest thing I have to say
is that my company is not going to be willing to let its programmers
use LISP, that some of the reasons for this are quite valid and that I
haven't been given enough ammunition to challenge anyone's opinion on
the matter.
So everyone who thinks been defending LISP from a detractor, you can
calm down, that's not what is going on.
Joshua Scholar
Christopher Browne
An X implementation written in a Lisp would indeed be extremely
interesting. Definitely would need some interesting compilation
techniques to stay fast; it would doubtless trample some bugs out of
existence.
--
"Microsoft builds product loyalty on the part of network administrators and
consultants, [these are] the only people who really count in the Microsoft
scheme of things. Users are an expendable commodity." -- Mitch Stone 1997
cbbr...@hex.net- <http://www.hex.net/~cbbrowne/lsf.html>
Kent M Pitman
> What I wanted to find out is what exactly were the reasons that some
> preferred LISP so that I could abstract those strengths or methods
> into my work, under the limitations I work under.
http://world.std.com/~pitman/PS/Hindsight.html
It's not a full list, but it might be helpful to you.
(Someone noted after I wrote this article, that I'd failed to mention
automatic storage management (gc) in the article; kind of a glaring
omission. Oh well..)
Paul Rudin
> Nothing in CL forbids you from type-declaring every variable.
It might be nice to have some standard, succinct syntax for this.
Maybe something like:
(defun foo\integer (lyst\cons x\integer ...)
...)
Steve Gonedes
Chris Double <ch...@cnd.co.nz> writes:
< I miss closures and lambda functions the most when using some of the
< stl algorithms. For example:
<
< class Person
< {
< string getName();
< };
<
< vector<Person*> people = ...;
<
< // Find a person with the name 'John':
< vector<Person*>::iterator it = find_if(
< people.begin(),
< people.end(),
< compose(
< bind2nd(equal_to<string>(), string("John")).
<
< I would much prefer writing an anonymous function inline:
<
< vector<Person*>::iterator it = find_if(
< people.begin(),
< people.end(),
< method(Person* p) { return p->getName() == "John"; } );
<
< Excuse the ugly syntax.
<
< The main problem with closure simulators in C++ is the memory
< management and providing access to the local variables without having
< to create a class which copies and stores them.
<
< Chris.
You can get local functions with gcc. Can't imagine what I would do
without them.
void
build_families (List *fontlist)
{
HashTable fonthash;
void *hash_font (const char *file) {
return puthash
((*function_table [font_file_type (file)].function) (file),
fonthash);
}
InitializeHashTable (fonthash);
map_list (fontlist, (void (*) (void *))hash_font);
}
I think that g++ allows this as well.
Tim Bradshaw
> Passing the wrong parameter, parameters in the wrong order, the wrong
> subfield etc. are common typos and often caught by the compiler -
> especially if you design your class interfaces to catch as much as
> possible. In code that rarely runs or isn't expected to run under
> normal conditions, this sort of correctness checking is very
> important.
This is a good argument. It would be more convincing if there was
empirical evidence that C++ systems are more robust than CL ones
developed in similar circumstances. Although I'm working from small
samples, I'd say the evidence is that C++ systems are several orders
of magnitude less robust than CL ones.
Also, of course, CL supports type declarations considerably more
precise than C++, and compilers are free to check those at compile
time. They typically don't, I guess because it turns out empirically
that this stuff doesn't help you much.
--tim
Joshua Scholar
>* Joshua Scholar wrote:
>
>> Passing the wrong parameter, parameters in the wrong order, the wrong
>> subfield etc. are common typos and often caught by the compiler -
>> especially if you design your class interfaces to catch as much as
>> possible. In code that rarely runs or isn't expected to run under
>> normal conditions, this sort of correctness checking is very
>> important.
>
>This is a good argument. It would be more convincing if there was
>empirical evidence that C++ systems are more robust than CL ones
>developed in similar circumstances. Although I'm working from small
>samples, I'd say the evidence is that C++ systems are several orders
>of magnitude less robust than CL ones.
>
Well, as I said in my last message, this whole subject is a sort of
deceptive detour away from my actual question. I wasn't trying to say
that CL is inferior in general, I was just sidetracked into defending
the limitations I have in my job as a game programmer - when that
wasn't my original question at all.
C++ has quite enough power to support all kinds of robust paradigms,
you just need to have the right tools and practices. My own personal
programming style emphasizes keeping myself out of trouble and
building the tools it takes to represent my problems abstractly. Many
programmers, for instance, find writing templates to be a forbiddingly
hard process - it was hard for me too for the first few years, but I
kept forcing myself to do it until it became second nature.
So I don't need empirical evidence that average programmers can write
robust C++, all I need to know is that the three programmers in my
office can.
You understood that my point was that when you don't have time to test
all of your control paths, having even a weak form of automatic code
verification is much more of a necessity than luxury. I keep hearing
that LISP supports building extensive layers on top of the language.
Perhaps you can build an advanced compile-time type checking and
constraint verification system on CL. Lint for CL.
If you want to support low level programmers (like Game programmers
and device driver programmers) then you could also add:
1. More limited extension to the object system that supports inline
methods (and therefor static linking)
2. A Modula like section of unsafe operations and memory management.
Sometime you need to get away from Nanny. This part you would probably
need the compiler source for.
I hear people say you should use the right tool for the job, but there
is no reason that one language couldn't be eventually extended to
cover all needs. And since the LISP community has always played with
features that the rest of the world considered too exotic or too
dangerous, it doesn't sound impossible that you'all could extend LISP
again. This time, for once, it would involve extending LISP downward
toward meeting the lower level languages instead of upward toward the
experimental horizons. It wouldn't do any harm, right?
Oh, and while you're at it, why not define a standard parser for
mathematical notation input. Lots of people are used to mathematical
notations and want to be able to program with them.
Joshua Scholar
Christian Lynbech
Christopher> An X implementation written in a Lisp ... would doubtless
Christopher> trample some bugs out of existence.
But wouldn't such a thing (a bug free X) render non-trivial amounts of
C programs useless :-)
As it has been said: you can promote a bug to a feature by documenting
it.
---------------------------+--------------------------------------------------
Christian Lynbech | Telebit Communications A/S
Fax: +45 8628 8186 | Fabrikvej 11, DK-8260 Viby J
Phone: +45 8628 8177 + 28 | email: c...@tbit.dk --- URL: http://www.telebit.dk
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
Marco Antoniotti
cbbr...@news.hex.net (Christopher Browne) writes:
> On 04 May 1999 13:30:47 +0100, Tim Bradshaw <t...@tfeb.org> wrote:
> >* Philip Morant wrote:
> >> C and C++ map more closely to the Chicken Pulley Unit's
> >> instruction set than any other high-level landwich. You could write a
> >> LISP compiler in C, but you'd have quite a problem if you wanted to
> >> write a C compiler using LISP.
> >
> >Symbolics had C, Fortran and I think pascal compilers written in, erm,
> >Lisp.
> >
> >I was really disappointed when I found they had an X implementation,
> >only to discover when looking at the source that it was just MIT X,
> >compiled with their C compiler.
>
> An X implementation written in a Lisp would indeed be extremely
> interesting. Definitely would need some interesting compilation
> techniques to stay fast; it would doubtless trample some bugs out of
> existence.
Ahem! CLX? Remember that in the beginning there were TWO
implementations of X, C/Xlib and CL/CLX.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Philip Lijnzaad
"Joshua" == Joshua Scholar <jo...@removethisbeforesending.cetasoft.com> writes:
Joshua> I was just sidetracked into defending the limitations I have in my
Joshua> job as a game programmer - when that wasn't my original question at
Joshua> all.
sorry to continue the side-track, and maybe this has been mentioned before,
but I seem to remember that Super Mario was developed/prototyped using a Lisp
system written/sold/resold? by Allegro Inc. And I would imagine that in
general Lisp is the perfect match for the games area, due to its immense
flexibility. You would have your high level code spit out assembler or so.
Joshua> C++ has quite enough power to support all kinds of robust paradigms,
Joshua> you just need to have the right tools and practices.
Many programs/programmers seem to do this by building there own dynamic
typing systems etc. into C or C++, which sounds like a bad case of re-use to
me.
Joshua> Many programmers, for instance, find writing templates to be a
Joshua> forbiddingly hard process - it was hard for me too for the first few
Joshua> years, but I kept forcing myself to do it until it became second
Joshua> nature.
(is C++ the right language if you need a few years to master it? Hell, even
lambda, mapcar, and closures are easier)
Joshua> Oh, and while you're at it, why not define a standard parser for
Joshua> mathematical notation input. Lots of people are used to mathematical
Joshua> notations and want to be able to program with them.
I remember seeing one a while ago on this newsgroup (or comp.lang.scheme);
I'm sure it's floating around somewhere, I'll try and see if I can find it.
Cheers,
Philip
--
The mail transport agent is not liable for any coffee stains in this message
-----------------------------------------------------------------------------
Philip Lijnzaad, lijn...@ebi.ac.uk | European Bioinformatics Institute
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
Espen Vestre
> Swapping Control_L and Caps_Lock is extremely common. If you want to
> do that, then [copy and paste from the xmodmap manpage]:
^^^^^^^^^^^^^^^
*blush*, and I always complain when people stick to their prejudices
instead of investigating the possiblities ;-) (my prejudice being
the false assumption that the caps lock key is "different")
Thank you! (now let's see what my left little finger thinks of this).
--
espen
Raymond Toy
Tim> Also, of course, CL supports type declarations considerably more
Tim> precise than C++, and compilers are free to check those at compile
Tim> time. They typically don't, I guess because it turns out empirically
Tim> that this stuff doesn't help you much.
CMUCL can handle these precise type declarations, and I've found that
it can help out quite a bit. If you declare something as, say,
(integer 0 42), it might be possible for the compiler to deduce that
all operations always result in a fixnum, and therefore use only
fixnum operators instead of resorting to a generic integer arithmetic
routine.
Ray
Johan Kullstam
> Oh, and while you're at it, why not define a standard parser for
> mathematical notation input. Lots of people are used to mathematical
> notations and want to be able to program with them.
lisp has infix syntax. while this may seem to be catering to the
machine, it is a small price to pay in order to reap the benefits of a
regular syntax. (writing the reader/parser is easier with infix, but
that's not the reason for using it.) you can make your own
`operators' (since they're all functions).
C++ restricts you to overloading the existing set of operators or
making functions (which are infix in C++ too). what if *two* (or
more) kinds of multiplication make sense? e.g., let A and B be 3x3
matrices. you might want to multiply them as matrices, or you may
wish to multiply element-wise. matlab has * and .* operators to
handle this. you can overload the * operator in C++ but good luck in
introducing a .* operator. ok, so you make a function or cast the
matrices to element-wise beasts and * away on that.
so far it's just silly notations, but what happens when you want to
scale up and use templates or macros? it is here that the
*everything* is infix in lisp that makes a big difference. the
function/operator occupies the same slot (i.e., first in a list) no
matter what it does. the lack of myriad special cases and syntax
contortions really pays off in the end since the macros can be more
ambitions in power and scope.
the annoymous functions and closures are also part of this. it's not
a matter of namespace pollution so much as awkward syntax. immagine a
C dialect in which you had no direct number constants, but were
obligated to first making a constant before you could use them.
instead of
int x,y;
....
y += x + 3
you had to do
const int three = 3;
int x,y;
....
y += x + three;
it works the same. but it's awkward. the definition of three wanders
away from the point you need it. and what if someone else made
const double three = 3.0;
somewhere else?
why shouldn't you be able to just write a function in the same way you
can just stick in a regular number constant? having to name every
function is just as tedious as having to name every numerical
constant. it's exactly the same.
in C and C++, functions are very much second class citizens. in lisp
they are bandied about just like any other kind of data. this allows
a level of abstraction - you can program at a higher level.
in mathematical notation, you can just introduce a function. many
times you operate on the functions as if they were mere elements.
consider, for example, functional analysis (to say nothing about more
esoteric abstraction such as you find in algebraic topology).
we could turn right around and ask of C++, why not define a standard
parser for mathematical notation input - like arbitrary functions.
Lots of people are used to mathematical notations - like functions -
and want to be able to program with them - just as easily as with
numbers or arrays of numbers.
--
johan kullstam
Pierre R. Mai
> Ahem! CLX? Remember that in the beginning there were TWO
> implementations of X, C/Xlib and CL/CLX.
Weren't we talking about the server side of X? Or have I again missed
something important?
Regs, Pierre.
--
Pierre Mai <pm...@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Joachim Achtzehnter
>
> > Well Bagheera didn't state the problem quite right. The overall
> > point is that type checking saves you from tons and tons of late
> > night typos and logic errors.
>
> yourself out. Don't forget to send bug reports when the compiler
> fails to use them well or flag problems, so your vendor will know
> you care.
It is true that one cannot fault the language for this. Nevertheless,
until vendors listen to and act on these 'bug reports' the problem
persists in practise. I agree strongly with Joshua that lack of static
type checking is one on the main disadvantages of (at least) the
commercial Common Lisp implementation I am familiar with.
> But the language itself already supports this. It's simply up to
> the market to decide if this is what stands between it and
> success. I doubt it is, but you're welcome to make the case
> otherwise.
Well, I tend to disagree. Adding static type checking (optional of
course) would go a long way towards convincing experienced C++/Java
programmers to take another look at Lisp. Of course, I can be certain
only about my own opinion, others may disagree. I have heard a
representative of a Lisp vendor seriously argue that Lisp code must
look as simple as Java code to be competitive. IMHO, static type
checking is an order of magnitude more important than that. :-)
> I won't try to tell you not to write declarations if you won't try
> to tell me that I must write them.
Sure, there is no need to take away this flexibility.
> > In code that rarely runs or isn't expected to run under
> > normal conditions, this sort of correctness checking is very
> > important.
>
> You don't say what your point is.
The point is probably this: A C++/Java compiler cannot catch all
errors, especially not design or logical errors, but at least it
catches most simple errors like typos, passing the wrong number of
arguments, passing a wrong argument, etc. With existing Lisp
implementations many such errors are detected only at runtime even
when declarations are used. This is less problematic with mainline
code which is likely to be run by the developer anyway, but typos in
sections of the source code that are less frequently run have the
habit of crashing in the hands of a user, or the QA department if
you're lucky. Yes, you should test all your code, but the kind of bug
we're talking about is often introduced by changes that are so
'obvious' that many developers don't imagine a bug may have been
introduced.
Joachim
--
joa...@kraut.bc.ca (http://www.kraut.bc.ca)
joa...@mercury.bc.ca (http://www.mercury.bc.ca)
Kent M Pitman
> > > Well Bagheera didn't state the problem quite right. The overall
> > > point is that type checking saves you from tons and tons of late
> > > night typos and logic errors.
> >
> > Nothing in CL forbids you from type-declaring every variable. Knock
> > yourself out. Don't forget to send bug reports when the compiler
> > fails to use them well or flag problems, so your vendor will know
> > you care.
>
> It is true that one cannot fault the language for this. Nevertheless,
> until vendors listen to and act on these 'bug reports' the problem
> persists in practise. I agree strongly with Joshua that lack of static
> type checking is one on the main disadvantages of (at least) the
> commercial Common Lisp implementation I am familiar with.
Then you should use the power of the marketplace. If you cannot get
enough people together to say that this is more important than other
things, then perhaps it is not. I mean this seriously. It is very
easy for people to complain about things CL doesn't do. I believe it
is helpful if you make a list of the things that are promised in the
next release of your favorite vendor and tell the vendor your decision
to purchase future copies is premised on their doing this thing
instead of something they've promised. I think most people either say
this and then purchase anyway (meaning they weren't really serious) or
aren't willing to say what they'd give up (meaning they think the
system has infinite resources).
> > But the language itself already supports this. It's simply up to
> > the market to decide if this is what stands between it and
> > success. I doubt it is, but you're welcome to make the case
> > otherwise.
>
> Well, I tend to disagree. Adding static type checking (optional of
> course) would go a long way towards convincing experienced C++/Java
> programmers to take another look at Lisp.
I really honestly and not facetiously think that if you believe this with
certainty, then you might consider getting a Lisp and putting your own
money and reputation on the line over this. Because the Lisp vendors are
doing this day in and day out, and they do not casually assign their
resources away from the thing you describe. They might be wrong, of course,
but if you really believe that there is a time-tested way to demonstrate
that.
Thought:
Nothing in the world is "important" or "unimportant".
Things are only "more important" and "less important" than other things.
Say what you think is less important and you'll know what your leverage
is to get this so-called more important thing.
> Of course, I can be certain
> only about my own opinion, others may disagree. I have heard a
> representative of a Lisp vendor seriously argue that Lisp code must
> look as simple as Java code to be competitive. IMHO, static type
> checking is an order of magnitude more important than that. :-)
So you mean you'd pay an order of magnitude more money? Or what do
you mean by that?
> > I won't try to tell you not to write declarations if you won't try
> > to tell me that I must write them.
>
> Sure, there is no need to take away this flexibility.
>
> > > In code that rarely runs or isn't expected to run under
> > > normal conditions, this sort of correctness checking is very
> > > important.
> >
> > You don't say what your point is.
>
> The point is probably this: A C++/Java compiler cannot catch all
> errors, especially not design or logical errors, but at least it
> catches most simple errors like typos, passing the wrong number of
> arguments, passing a wrong argument, etc. With existing Lisp
> implementations many such errors are detected only at runtime even
> when declarations are used. This is less problematic with mainline
> code which is likely to be run by the developer anyway, but typos in
> sections of the source code that are less frequently run have the
> habit of crashing in the hands of a user, or the QA department if
> you're lucky. Yes, you should test all your code, but the kind of bug
> we're talking about is often introduced by changes that are so
> 'obvious' that many developers don't imagine a bug may have been
> introduced.
Then maybe you should switch vendors. Tell other vendors that's what
it would take to get you to swtich. But making this checking a
requirement of the language would just mean there are fewer
implementations (since it would define some implementations not to be
valid). It would not suddenly create more resources to do these
changes. Standards are about codifying de facto practice, not about
forcing practice. The marketplace is where to make your feelings
known, either as a choosy purchaser or an aggressive vendor with a
vision. If you are willing to be neither, then I suggest you might
ask yourself what it means to say you hold these beliefs strongly. If
you think you are being one of those things (probably the choosy
customer) and you are finding it doesn't help, then perhaps you should
think about how to create a customer organization that better
represents your market segment, or think about whether there are
enough people for you really to be a market segment.
Markets are elusive. Just because you can't prove one is there doesn't
mean it's not--I'm not saying it's an easy business. But what I'm saying
is that wishing as you are doing doesn't make it so. The game is all
about resources. What resources vendors have and what products people give
financial resources in exchange for. If you don't affect that, you will
affect nothing. That is how markets work (and don't).
I apologize for the somewhat strained tone of this message. I don't
mean to jump on you personally. But this is kind of an exemplar of
something I hear from people from time to time that I never quite get
around to responding to and this was a good chance.
Joachim Achtzehnter
Agreed. By posting my opinion about this matter I hope to influence my
current vendor who may have an interest in my continued interest in
their product, as well as my vendor's competitors who may want to get
my business.
> If you cannot get enough people together to say that this is more
> important than other things, then perhaps it is not.
Certainly. But this is no reason to refrain form expressing ones
opinion.
> I mean this seriously. It is very easy for people to complain about
> things CL doesn't do.
Well, sorry for coming across as somebody who is whining. I am
critical of all programming languages that I've come across so
far. This doesn't mean one can't get work done with them. But being
able to get work done with a programming language is also no reason
not to try improving it (or its implementations). I am currently using
Lisp and appreciate its advantages. Don't see why I should not express
my opinion about its weaknesses.
> > I have heard a representative of a Lisp vendor seriously argue
> > that Lisp code must look as simple as Java code to be
> > competitive. IMHO, static type checking is an order of magnitude
> > more important than that. :-)
> So you mean you'd pay an order of magnitude more money? Or what do
> you mean by that?
The decision to use Lisp, and to pay money for an implementation and
how much, wasn't for me to make in this case. In any case I am talking
here about mindshare. How can Lisp grow its user base? This is not
simply a question of who is willing to pay how much for which
features. It is more a question of how many potential developers are
comfortable with the idea of developing in Lisp. The static typing
issue is important in my opinion, others may disagree.
> I apologize for the somewhat strained tone of this message.
No need to apologize, your response contained useful thoughts and was
quite civilized. But if I may say so, the same can't be said about
certain other posters in this thread. This is another point which can
easily put off some developers from considering a non-mainstream
language like Lisp. In C++ newsgroups one can have serious discussions
about possible language improvements, here one is attacked and called
an 'ignorant newbie' and worse names. Of course, one cannot blame the
language for this either... :-)
Raymond Toy
Joachim> persists in practise. I agree strongly with Joshua that lack of static
Joachim> type checking is one on the main disadvantages of (at least) the
Joachim> commercial Common Lisp implementation I am familiar with.
Get another implementation? I'm not that familiar with commercial
implementations on this topic, but certainly CMUCL can do a lot of
static type checking, roughly equivalent to any C/C++ compiler, and,
in some ways, a lot more.
Joachim> Well, I tend to disagree. Adding static type checking (optional of
Joachim> course) would go a long way towards convincing experienced C++/Java
Joachim> programmers to take another look at Lisp. Of course, I can be certain
Joachim> only about my own opinion, others may disagree. I have heard a
I always thought C++/Java programmers were turned off by the syntax,
not the lack of type checking. As a C/C++ programmer, I rather enjoy
not having to type everything when writing in Lisp.
Joachim> arguments, passing a wrong argument, etc. With existing Lisp
Joachim> implementations many such errors are detected only at runtime even
Joachim> when declarations are used. This is less problematic with mainline
Get a better implementation?
Joachim> you're lucky. Yes, you should test all your code, but the kind of bug
Joachim> we're talking about is often introduced by changes that are so
Joachim> 'obvious' that many developers don't imagine a bug may have been
Joachim> introduced.
I would say your software engineering process is broken in this case,
and no language will protect you from this kind of problem.
Ray
Joshua Scholar
wrote:
>
> Joachim> you're lucky. Yes, you should test all your code, but the kind of bug
> Joachim> we're talking about is often introduced by changes that are so
> Joachim> 'obvious' that many developers don't imagine a bug may have been
> Joachim> introduced.
>
It's not about 'obviousness' so much as pressure an lack of time.
>I would say your software engineering process is broken in this case,
Welcome to the real world. The only time I've ever seen an office
where the programmers had all the time they needed for designing,
documenting, debugging and other 'engineering' process tasks was in a
government job. But then I work in the games industry which is
entertainment after all - flakiness and ego are expected to be main
ingredients of both management and engineering here. Not that I'm
complaining - for one thing I fit right in :)
>and no language will protect you from this kind of problem.
>
>Ray
Oh, a language can help by making testing less necessary. It's a good
thing for it to be doing in any case.
Joshua Scholar
please-reply...@thank.you
<joa...@kraut.bc.ca> wrote:
>here about mindshare. How can Lisp grow its user base? This is not
>simply a question of who is willing to pay how much for which
>features. It is more a question of how many potential developers are
>comfortable with the idea of developing in Lisp. The static typing
>issue is important in my opinion, others may disagree.
I'm one of those who disagree. I've talked to a lot of
people about Lisp, and about the possibility of using
it in place of languages such as C++. None of them
ever mentioned static type checking to me as one of
their reasons for rejecting Lisp. The overwhelmingly
most common reason is the perception that Lisp is a
special purpose language for academic projects where
efficiency doesn't matter.
Joshua Scholar
wrote:
This is like the old parable about measuring the Emperor's nose. No
one has ever seen the Emperor, so any one person's opinion about the
length of his nose has no significance. The joke is that you try gain
significance by averaging the answers of many people.
I have actual reasons for not being able to use Lisp and you're saying
those reasons are not important because the average programmer (who's
ignorance of what compilers can do is apparently greater than mine)
gives different reasons.
So I'd think a better question than why people who don't know anything
about modern Lisp systems don't use them would be, what do Lisp
systems need in order to be useful to everyone who does know about
them.
There is nothing wrong with a Lisp being unsuited for many companies
except that the language could change so that it covers all needs.
Joshua Scholar
Erik Naggum
| Welcome to the real world. The only time I've ever seen an office where
| the programmers had all the time they needed for designing, documenting,
| debugging and other 'engineering' process tasks was in a government job.
I love it when people think theirs is the only corner of the world that
is worthy of the trademark Real World. one usually doesn't need any more
evidence to discard people than that.
I have had the opportunity to do everything I have wanted to do for my
client, and have been able to spend all the time I have wanted on what I
think is important to the end goal: that I shall be able to leave the
project and it shall continue to be operational for a long time to come.
only when my management has decided on some particular deadline for some
particular feature has this idyllic image been disturbed. this is not a
government project -- it's a financial news agency's distribution system,
where we care more about accuracy and fault tolerance than anything else.
#:Erik
Rob Warnock
+---------------
| lisp has infix syntax.
+---------------
I think you meant to say, "Lisp has PREFIX syntax".
(At least, I *hope* that's what you meant to say...)
-Rob
-----
Rob Warnock, 8L-855 rp...@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
Christopher R. Barry
> Johan Kullstam <kull...@ne.mediaone.net> wrote:
> +---------------
> | lisp has infix syntax.
> +---------------
>
> I think you meant to say, "Lisp has PREFIX syntax".
>
> (At least, I *hope* that's what you meant to say...)
I believe I remember seeing someone use an infix syntax package (in
this group?) and it looked something like #I(2 + foo * pi ...).
Christopher
Rob Warnock
+---------------
Uh... That's what Lisp *can* do, if *you* choose to write a reader macro
function that implements an infix parser and bind it to a dispatch character
(in this case, "I", which is undefined by default in standard CL) for the
non-terminating dispatching macro character "#" in *your* application program.
But it's not built into Lisp. Lisp's native syntax (in the absence of macro
characters) is prefix:
(+ 2 (* foo pi))
Johan Kullstam
> Johan Kullstam <kull...@ne.mediaone.net> wrote:
> +---------------
> | lisp has infix syntax.
> +---------------
>
> I think you meant to say, "Lisp has PREFIX syntax".
>
> (At least, I *hope* that's what you meant to say...)
oh yeah, thanks for fixing my think-o.
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!
Raymond Toy
Rob> Christopher R. Barry <cba...@2xtreme.net> wrote:
Rob> | I believe I remember seeing someone use an infix syntax package (in
Rob> | this group?) and it looked something like #I(2 + foo * pi ...).
Rob> +---------------
Rob> Uh... That's what Lisp *can* do, if *you* choose to write a reader macro
Rob> function that implements an infix parser and bind it to a dispatch character
There is the infix package in the CMU Lisp archives....
Ray
Christopher Browne
<joa...@kraut.bc.ca> wrote:
>Kent M Pitman <pit...@world.std.com> writes:
>>
>>
>> > Well Bagheera didn't state the problem quite right. The overall
>> > point is that type checking saves you from tons and tons of late
>> > night typos and logic errors.
>>
>> Nothing in CL forbids you from type-declaring every variable. Knock
>> yourself out. Don't forget to send bug reports when the compiler
>> fails to use them well or flag problems, so your vendor will know
>> you care.
>
>It is true that one cannot fault the language for this. Nevertheless,
>until vendors listen to and act on these 'bug reports' the problem
I agree strongly that the lack of static type checking is perceived
*by you and Joshua* as a main disadvantage of CL implementations.
One of the major problems with C++ is that it requires static
typechecking, which means that building generic functions requires the
contortions of templates, which have taken years to settle down enough
that compilers could coherently implement them. (And it is not at all
clear that template-based code is portable between different
template-implementation approaches.)
The fact that CL doesn't *force* you to restrict the manipulable types
at the time that you write the code means that you don't need
templates; you just need to go write CL code, and use it on whatever
datatypes you need to use it on.
You're not likely to get agreement that the problem *that you
perceive* represents a problem *in fact.*
>> But the language itself already supports this. It's simply up to
>> the market to decide if this is what stands between it and
>> success. I doubt it is, but you're welcome to make the case
>> otherwise.
>
>Well, I tend to disagree. Adding static type checking (optional of
>course) would go a long way towards convincing experienced C++/Java
>programmers to take another look at Lisp. Of course, I can be certain
>only about my own opinion, others may disagree. I have heard a
>representative of a Lisp vendor seriously argue that Lisp code must
>look as simple as Java code to be competitive. IMHO, static type
>checking is an order of magnitude more important than that. :-)
Adding in a requirement to put semicolons at the ends of statements,
and changing over to C++ syntax, might also go a long way towards
convincing C++/Java advocates to take another look at Lisp.
By the way, if static type checking is, as you say, an order of
magnitude more important than simplicity of appearance, would you then
pay an order of magnitude more for the Lisp implementation?
Money talks; if the Lisp vendors figure out that they can make ten
times as much (a decimal order of magnitude) in sales as a result of
implementing this functionality, then I don't think they'll sit back
on their haunches with some "religious" attitude about not doing it
because they think it's a silly idea; they'll say:
"Cool! If we invest $100,000 paying a developer or two to add static
type checking, and when our sales increase by an order of magnitude,
from $10M to $100M, this $100K investment will pay off handsomely!"
[Hint: The fact that they haven't done so means that they obviously
consider this "enhancement" to *not* be of that much economic value.]
>> I won't try to tell you not to write declarations if you won't try
>> to tell me that I must write them.
>
>Sure, there is no need to take away this flexibility.
>
>> > In code that rarely runs or isn't expected to run under
>> > normal conditions, this sort of correctness checking is very
>> > important.
>>
>> You don't say what your point is.
>
>The point is probably this: A C++/Java compiler cannot catch all
>errors, especially not design or logical errors, but at least it
>catches most simple errors like typos, passing the wrong number of
>arguments, passing a wrong argument, etc. With existing Lisp
>implementations many such errors are detected only at runtime even
>when declarations are used. This is less problematic with mainline
>code which is likely to be run by the developer anyway, but typos in
>sections of the source code that are less frequently run have the
>habit of crashing in the hands of a user, or the QA department if
>you're lucky. Yes, you should test all your code, but the kind of bug
>we're talking about is often introduced by changes that are so
>'obvious' that many developers don't imagine a bug may have been
>introduced.
I have a whopping lot more problems with things other than type
declarations.
Feel free to believe whatever you want about the "order of magnitude"
importance of static type checking. If you lose credibility as a
result of this belief, that's not my problem.
--
Where do you *not* want to go today? "Confutatis maledictis, flammis
acribus addictis" (<http://www.hex.net/~cbbrowne/msprobs.html>
cbbr...@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>
Christopher Browne
<mar...@copernico.parades.rm.cnr.it> wrote:
>> An X implementation written in a Lisp would indeed be extremely
>> interesting. Definitely would need some interesting compilation
>> techniques to stay fast; it would doubtless trample some bugs out of
>> existence.
>
>implementations of X, C/Xlib and CL/CLX.
Isn't that merely a CL implementation of Xlib?
That's hardly an "X implementation written in a Lisp;" that's merely a
wrapper for the X protocol written in a Lisp, and is not a
*remarkably* interesting thing.
Marco Antoniotti
cbbr...@news.hex.net (Christopher Browne) writes:
> On 05 May 1999 10:22:23 +0200, Marco Antoniotti
> <mar...@copernico.parades.rm.cnr.it> wrote:
> >cbbr...@news.hex.net (Christopher Browne) writes:
> >> An X implementation written in a Lisp would indeed be extremely
> >> interesting. Definitely would need some interesting compilation
> >> techniques to stay fast; it would doubtless trample some bugs out of
> >> existence.
> >
> >Ahem! CLX? Remember that in the beginning there were TWO
> >implementations of X, C/Xlib and CL/CLX.
>
> Isn't that merely a CL implementation of Xlib?
>
> That's hardly an "X implementation written in a Lisp;" that's merely a
> wrapper for the X protocol written in a Lisp, and is not a
> *remarkably* interesting thing.
I stand corrected. However, beside being interesting, why should a
X *server* be built in CL at this time in history?
Sam Steingold
>>>> On the subject of "Re: Newbie questions [Followup to comp.lang.lisp]"
>>>> Sent on 06 May 1999 00:42:56 +0000
>>>> Honorable Erik Naggum <er...@naggum.no> writes:
>> * jo...@removethisbeforesending.cetasoft.com (Joshua Scholar)
>> | Welcome to the real world. The only time I've ever seen an office where
>> | the programmers had all the time they needed for designing, documenting,
>> | debugging and other 'engineering' process tasks was in a government job.
>>
>> I love it when people think theirs is the only corner of the world that
>> is worthy of the trademark Real World. one usually doesn't need any more
>> evidence to discard people than that.
>>
>> I have had the opportunity to do everything I have wanted to do for my
>> client, and have been able to spend all the time I have wanted on what I
Is this why your CLEmacs (http://sourcery.naggum.no/emacs/clemacs.html)
project is dormant for almost 2 years now? :-)
Apparently it's not important to the end goal...
[No, you do not owe anyone anything, and I am not blaming you for
anything, and I am not whining &c &c &c.]
--
Sam Steingold (http://www.goems.com/~sds) running RedHat6.0 GNU/Linux
Micros**t is not the answer. Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
I may be getting older, but I refuse to grow up!
Bagheera
jo...@removethisbeforesending.cetasoft.com (Joshua Scholar) wrote:
> On 05 May 1999 18:44:31 -0400, Raymond Toy <t...@rtp.ericsson.se>
> wrote:
> >I would say your software engineering process is broken in this case,
>
> where the programmers had all the time they needed for designing,
> documenting, debugging and other 'engineering' process tasks was in a
> entertainment after all - flakiness and ego are expected to be main
> ingredients of both management and engineering here. Not that I'm
> complaining - for one thing I fit right in :)
must've been a good govt. job.
I've been working for the government for several years now
and I've only had 1 position where your situation held true.
But that was a group filled with young, idealistic, crusading
programmers that had little control enforced over them from
management. Maybe the younger generation just knows a better
way of getting the work done?
In general, though, all the jobs I have had have been flaky, with ego
maniacal managers and leads. I find this kind of atmosphere too
difficult to be productive in. Chaos begets chaos.
--
Bagherra <jae...@frenzy.com>
http://www.frenzy.com/~jaebear
"What use is it to have a leader who walks on water
if you don't follow in their footsteps?"
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
William Deakin
(LALR etc) out there somewhere. I had a look and couldn't find one.
Christopher R. Barry
> Christopher R. Barry <cba...@2xtreme.net> wrote:
>
> | I believe I remember seeing someone use an infix syntax package (in
> | this group?) and it looked something like #I(2 + foo * pi ...).
> +---------------
>
> Uh... That's what Lisp *can* do
That's kinda what I was getting at.
> Lisp's native syntax (in the absence of macro characters) is prefix:
>
> (+ 2 (* foo pi))
How enlightening.
Christopher
Joachim Achtzehnter
>
> > Joachim Achtzehnter <joa...@kraut.bc.ca> writes:
> >
> > It didn't bring down the whole application, I'll give you that. But
> > similar behaviour can be achieved with statically typed languages. The
> > point is that static typing can catch certain simple bugs ealier.
>
> I disagree that you can do this in practice in C++. Have fun trying.
> Trimmed comp.ai.
If there is one thing that gets me up a tree when discussing
programming languages, it is this pretentious believe some people have
that some requirement, feature, or behaviour can only be achieved
using their favourite language.
Contrary to what you say, isolating failures is not at all difficult
to achieve in C++ or other mainstream languages. Of course, if you
only look at monolytic systems typically emanating from Redmond, then
you are sure to crash the whole system when something goes wrong. As
an example of where we are heading, consider distributed systems
(using CORBA and other technlogies). More and more systems are built
as collections of components where every component does one thing and
one thing only. And this isn't exactly new either: On certain
mainframe systems of the past it was commonplace to implement every
transaction type as a separate program.
Anyway, this is all besides the point. How did we get distracted into
this discussion? The topic was whether more static type checking in
Common Lisp implementations would be a worthwhile improvement or
not. Nobody, at least not me, was claiming that other languages are
better than Lisp.
Joachim Achtzehnter
>
> One of the major problems with C++ is that it requires static
> typechecking, which means that building generic functions requires
> the contortions of templates, which have taken years to settle down
> enough that compilers could coherently implement them.
Yes, and they are still not as flexible as they should be. There is a
lot of research going on in the area of virtual types and
genericity. Don't be surprised to see a revision of C++ templates in
the future, or the emergence of a new language. In fact, the
discussion about adding genericity to Java has prompted a lot of
activity in this area of research. The point with all this is that
languages that are alive tend to learn from experience and improve
over time. I could say something about dead languages but this would
have an undesired effect in this newsgroup :-)
Note: this last sentence was meant to be a joke! Keep in mind that I
am using Lisp myself.
> Money talks; if the Lisp vendors figure out that they can make ten
> times as much (a decimal order of magnitude) in sales as a result of
> implementing this functionality, then I don't think they'll sit back
> on their haunches with some "religious" attitude about not doing it
> because they think it's a silly idea; they'll say:
>
> "Cool! If we invest $100,000 paying a developer or two to add static
> type checking, and when our sales increase by an order of magnitude,
> from $10M to $100M, this $100K investment will pay off handsomely!"
I don't share your believe in the power of the market to lead us to
paradise. If the market had this power would Lisp be the fringe
language it is? Would Microsoft be the most successful software
company?
> Feel free to believe whatever you want about the "order of
> magnitude" importance of static type checking.
Definitely.
> If you lose credibility as a result of this belief, that's not my
> problem.
Indeed.
Joachim Achtzehnter
>
> [talking failure isolation]
>
> I didn't say it was impossible in C++, just very difficult, to the
> point where most people don't do it. I don't hear you contradicting
> this point.
It is difficult only if you approach the design with the preconceived
notion that a system must be a single, monolytic program. But as I
said, my point wasn't to compare Lisp with C++. I was proposing
something that I consider an improvement for Lisp implementations (and
you are welcome to disagree). Even if Lisp is better than every other
programming language under the sun, we might still be able to improve
it, no?
> Nuff said.
Yes.
Erik Naggum
| If you did want to write a CL compiler in C, is there a formal grammar
| (LALR etc) out there somewhere. I had a look and couldn't find one.
you won't find one, either. formal grammars are useful for languages
that are designed to be unreadable and with constructs designed to be
impossible to represent at run-time. Lisp is designed to be readable and
source code to be representable at run-time, and so have a very different
way of thinking about its grammar. considering that all you will ever do
with a grammar is associate the first element of a list (a symbol) with a
rule for dealing with the rest of the list, you might as well design the
whole system using a recursive descent "parser".
Common Lisp's syntax is designed to be LL(1), and objects are read in
their entirety before any semantics are associated with them, quite
unlike languages designed to keep the sources unreadable to programs
written in those languages.
#:Erik
Gavin E. Gleason
CMUCL alows you to specify types, and I imagine that the commercial
compilers do as well. Just because it is not specified in ANSI
does not mean that it does not exist in most implementations... but
it would be nice if it were specified.
Gavin E. Gleason
Joshua Scholar
<bagh...@my-dejanews.com> wrote:
>In article <3730d086...@news.select.net>,
> jo...@removethisbeforesending.cetasoft.com (Joshua Scholar) wrote:
>> On 05 May 1999 18:44:31 -0400, Raymond Toy <t...@rtp.ericsson.se>
>> wrote:
>> >I would say your software engineering process is broken in this case,
>>
>> Welcome to the real world. The only time I've ever seen an office
>> where the programmers had all the time they needed for designing,
>> documenting, debugging and other 'engineering' process tasks was in a
>> government job. But then I work in the games industry which is
>> entertainment after all - flakiness and ego are expected to be main
>> ingredients of both management and engineering here. Not that I'm
>> complaining - for one thing I fit right in :)
>
>must've been a good govt. job.
>I've been working for the government for several years now
>and I've only had 1 position where your situation held true.
>But that was a group filled with young, idealistic, crusading
>programmers that had little control enforced over them from
>management. Maybe the younger generation just knows a better
>way of getting the work done?
>
>In general, though, all the jobs I have had have been flaky, with ego
>maniacal managers and leads. I find this kind of atmosphere too
>difficult to be productive in. Chaos begets chaos.
Two caveats:
1. I didn't say WHICH government. The department was Agriculture
Canada.
2. The manager I met was a flaky, ego maniacal man who insisted on
meticulous software engineering. But the only reason he could get
away with all he did (he was having programmer reinvent the wheel and
be WAY too fancy instead of buying off the shelf packages) was that he
didn't have to turn a profit.
Joshua Scholar
Paolo Amoroso
wrote:
> Now in my work (game programming) I don't really have a choice, I more
> or less have to use C++.
By the way, the Web site of Franz Inc. http://www.franz.com/ mentions that
their Common Lisp system is being used also for game development. The site
provides information about a couple such projects.
Paolo
--
Paolo Amoroso <amo...@mclink.it>
Pierre R. Mai
> Hmm. If you did want to write a CL compiler in C, is there a formal grammar
> (LALR etc) out there somewhere. I had a look and couldn't find one.
Given the complexity of the Common Lisp reader, and it's flexibility
(reader macros, read-time evaluation, etc.), I strongly doubt that any
parser generator will be able to handle this task out of the box. Of
course I haven't tried to do this, so I might be mistaken... ;)
Regs, Pierre.
--
Pierre Mai <pm...@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Pierre R. Mai
> I don't share your believe in the power of the market to lead us to
> paradise. If the market had this power would Lisp be the fringe
> language it is? Would Microsoft be the most successful software
> company?
*IT IS BECAUSE THE MARKET HAS THIS POWER* that Microsoft is the most
"successful" software company. It is the direct consequence of the
fact that most participants in the shrink-wrapped software market
don't really care about quality, safety, ease-of-use and TCO, their
whining not-withstanding. Free markets work like democracies: Given
responsible, ethical and intelligent customers / citizens, they can
create paradise. Of course, in most mass markets / communities, those
customers / citizens are in a stark minority, and thus paradise is
unatainable[1].
Back to Common Lisp:
If Lisp is about anything, it's about doing the right thing, or at
least trying very very hard to do so, and recognizing that to achieve
this, you have to move very carefully, yet move nonetheless. There
has gone much thought, and philosophical analysis, into nearly all of
the features you'll find in the current ANSI CL spec, and I expect the
same to happen with any other new ingredient that might be added to
that self-same standard in the future.
That high standard of doing the right thing, is the single most
outstanding reason that I'm working with CL. It is not the dynamism,
the machismo or the nice parenthesis. It is that I care about doing
the right thing, it is that my customers expect this of me (or else
they will not be my customers), and I trust Common Lisp to help me
achieve this.
So before we added some kind of (mandatory) compile-time type-checking
to Lisp, I'd want to be very sure that we are doing the right thing
here, that we've understood the issues at hand, the limitations,
the user's expectations, and the ability of implementations to
successfully implement this reliably.
Well, and C++/Java-style "type-checking" strikes me as being most
obviously not the right thing.
IMNSHO, IF C++ or Java programmers *really* cared about type-checking
at compile-time, they wouldn't be using those languages in the first
place. To care about type-checking, you'd want to have a sensible and
expressive type-system to start with. So you'd want at least something
like Ada, which also has bounds checking and a lot of other stuff you'd
want, or much better yet, you'd want something like the current crop of
typed pure functional languages, like Haskell or OPAL, etc., which not
only have expressive type-systems, and compile-time type-checking but
also type-inference, and at least in the case of OPAL, an algebraic
property language, which allows you to specify further properties of
your defined operations, to be checked at compile-time where possible.
That would be the course of action for C++ programmers that *really*
cared about compile-time type-checking.
Since the above mentioned languages don't have huge amounts of new
recruits either, it seems to me that most C++ programmers care about
compile-time type-checking like they care about OOP, or speed, or
portability, or most other things for that matter: It is a
must-have-it-and-exactly-this-way feature, yet they don't really know
what it is, or care about the underlying semantics or problems. As
long as the compiler acts like it's doing something, everything's just
fine. The sayings "Lisp programmers know the value of everything and
the cost of nothing" vs. "C++ programmers know the cost of everything,
yet the value of nothing" come to mind. And since the time of this
saying, I think CL programmers at least have gotten a long way to
knowing the cost of things, yet I still see no movement in the C++
community of starting to care about the value of things.
Since I've heard in this discussion that C++-style type-checking is
mostly helpful in uncovering simple mistakes in argument order, etc.,
(which strikes me as being as mostly unrelated to type-checking), I'd
suggest using environments that reduce the likelyhood of MAKING those
mistakes. Although I've not been prone to making those mistakes even
in languages like C++, in my Lisp environment, not only have I got the
arglist and documentation of every Lisp operator -- whether built-in or
user-defined -- at my finger-tips, but also the complete Hyperspec, all
just a keypress away. So if I'm only a tiny bit in doubt about
argument order, or semantics, I look them up. And guess what, I'm
quite a bit better at doing that kind of checking, than any compiler
I've yet seen (besides the SSC of course ;).
Of course I'd still be very willing to listen to the ideas and designs
of someone who *REALLY* cares about type-checking at compile-time. But
I fear that since the type systems of modern pure functional languages
are still a much researched area, meaningfully type checking a language
like CL seems to me to be worthy of a number of PhDs before the design
space is clearly understood.
Of course, a much more "simplistic" kind of type-checking can be
attained with CMU CL today... Not that I see most former C++ users
flocking to CMU CL instead of other CL implementations though...
Regs, Pierre.
Footnotes:
[1] Note that these ideas are over 2000 years old...
[2] In reality of course, it's the languages' communities that care,
and not the language itself ;)
Erik Naggum
| There is a lot of research going on in the area of virtual types and
| genericity. Don't be surprised to see a revision of C++ templates in the
| future, or the emergence of a new language. In fact, the discussion
| about adding genericity to Java has prompted a lot of activity in this
| area of research. The point with all this is that languages that are
| alive tend to learn from experience and improve over time.
I tend to think of this in terms of young people who learn something that
older people have known for decades. the world is getting increasingly
complex, so the effort needed to get up to speed also increases and young
people need to work harder to catch up. and when they do, they have a
steeper "gradient" than the older people they catch up with, so it is
only natural that they want to continue with their catch-up speed and go
on to do new stuff at a higher pace than they think the old people do.
that's why you find new languages picking up a lot of _experimental_
stuff that is "new" in some sense of the word, but which older people
know to be junk, because it's something they discarded long ago, and
people who catch up don't see where people retracked after going wrong,
only where they went and decided to proceed. similarly, new languages
will do a lot of "research" and get a lot of funding for concepts and
ideas that have previously been discarded. however, to make this fly,
they have to call it something else, the same way people who want to
"circumvent" patents have to do _something_ clever on their own that lets
them use somebody else's inventions. except that regurgitated research
uses somebody else's money by fooling people who don't know that it
didn't work the last time around.
and with all these new languages and regurgitated research, progress is
_actually_ moving a lot slower than it would have if people could just
stick to using other people's inventions instead of optimizing for their
own degrees and for funding fun research and publicity hunters.
| I don't share your believe in the power of the market to lead us to
| paradise. If the market had this power would Lisp be the fringe language
| it is? Would Microsoft be the most successful software company?
this is so mind-bogglingly over-simplified an attitude that I can't begin
to answer it, but Microsoft has succeeded because it moved technical
issues into _irrelevant_ positions. people do _not_ buy Microsoft's
shitware because they want quality, robustness, investment protection, or
the like, they buy it out of fear of not being able to keep up with the
competitors for their manpower and with companies they exchange files
with. Microsoft did, however, offer something of relevance a good number
of years ago: they gave the suits a computer on their own desk that the
computer people didn't control. _that_ was the relevant criterion that
propelled Microsoft into their leading role in the minds of the people
who decide life or death in business: the suits. like evolution, any
irrelevant property can mutate without control, and some day it might
prove to be relevant once sufficiently advanced.
I read Kent Pitman's incessant argumentation for the "market" to be a
strong voice to let the vendors know that certain issues are _relevant_
to their customers, because the market only decides what's relevant, the
irrelevant is taken for granted, and can be _anything_ that doesn't get
relevant one way or another. Kent's trying to influence that, and lots
of people are trying to let people know what kind of irrelevant issues
caused them to purchase virus distribution vehicles and security holes
from Microsoft along with the relevant ego-stroking abilities for suits.
#:Erik