This is sort of a philisophical question like the one that was asked
of Deep Thought to which the answer was 42 but the actual question was
not known.
Obviously Common Lisp is Lisp. Scheme is also called Lisp as is Emacs
Lisp. In the past, there have been many dialects of Lisp. I don't
know if more than the above three are still in use, but they are all
called Lisp.
What makes Lisp Lisp? What is the car and cdr of it? Please don't
say cons ;-)
--
One Editor to rule them all. One Editor to find them,
One Editor to bring them all and in the darkness bind them.
(do ((a 1 b) (b 1 (+ a b))) (nil a) (print a))
David Steuber wrote:
> This is sort of a philisophical question like the one that was asked
> of Deep Thought to which the answer was 42 but the actual question was
> not known.
>
> Obviously Common Lisp is Lisp. Scheme is also called Lisp as is Emacs
> Lisp. In the past, there have been many dialects of Lisp. I don't
> know if more than the above three are still in use, but they are all
> called Lisp.
>
> What makes Lisp Lisp?
Now there's a fat pitch. From the Lisp 1.5 manual:
http://green.iis.nsk.su/~vp/doc/lisp1.5/node1.html
"LISP differs from most programming languages in three important ways.
The first way is in the nature of the data. In the LISP language, all
data are in the form of symbolic expressions usually referred to as
S-expressions. S-expressions are of indefinite length and have a
branching tree type of structure, so that significant subexpressions can
be readily isolated. In the LISP programming system, the bulk of
available memory is used for storing S-expressions in the form of list
structures. This type of memory organization frees the programmer from
the necessity of allocating storage for the different sections of his
program.
"The second important part of the LISP language is the source language
itself which specifies in what way the S-expressions are to be processed
This consists of recursive functions of S-expressions. ...<snip>...
"Third, LISP can interpret and execute programs written in the form of
S-expressions. Thus, like machine language, and unlike most other higher
level languages, it can be used to generate programs for further
execution. "
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
David Steuber <·············@verizon.net> writes:
> This is sort of a philisophical question like the one that was asked
> of Deep Thought to which the answer was 42 but the actual question
> was not known.
>
> Obviously Common Lisp is Lisp. Scheme is also called Lisp as is
> Emacs Lisp. In the past, there have been many dialects of Lisp. I
> don't know if more than the above three are still in use, but they
> are all called Lisp.
>
> What makes Lisp Lisp? What is the car and cdr of it? Please don't
> say cons ;-)
Maybe this one helps:
<http://www.paulgraham.com/diff.html>
Edi.
David Steuber wrote:
> What makes Lisp Lisp? What is the car and cdr of it? Please don't
> say cons ;-)
No, the pros are more important than the cons.
1 list data type based on dotted pairs
2 symbol (interned string) data type
3 source code is composed of lists, in prefix form
4 first-class closures
5 dynamic typing
6 everything is an expression, with a value
Another feature that's crucial in modern Lisp but
that wasn't there in the earliest versions:
7 a powerful macro system, making good use of the form
taken by source code
And another that I think is very important but wasn't
there in the earliest Lisps and still isn't there in
Emacs lisp (nor, I guess, in Autolisp):
8 commitment to giving the right answer rather than
the most rapidly computable answer -- so, e.g.,
no silent overflow of integer arithmetic
--
Gareth McCaughan
Gareth McCaughan <·····@g.local> writes:
> 8 commitment to giving the right answer rather than
> the most rapidly computable answer -- so, e.g.,
> no silent overflow of integer arithmetic
I _hate_ that about ELisp. CMUCL runs the do loop in my sig
wonderfully. GNU Emacs is just horrid with it.
In On Lisp, which I just started reading today, Paul Graham calls Lisp
a programmable programming language. I wonder if that is the essence
of it there.
He also has mentioned the word "arch" on almost every page so far. I
think he has had his arc language in mind for quite some time now.
--
One Editor to rule them all. One Editor to find them,
One Editor to bring them all and in the darkness bind them.
(do ((a 1 b) (b 1 (+ a b))) (nil a) (print a))
David Steuber <·············@verizon.net> wrote:
> In On Lisp, which I just started reading today, Paul Graham calls Lisp
> a programmable programming language. I wonder if that is the essence
> of it there.
It's certainly a lot of it, but it isn't all. By the
way, that particular aphorism is due not to Paul Graham
but to John Foderaro. Graham is quoting.
--
Gareth McCaughan
David Steuber wrote:
> What makes Lisp Lisp? What is the car and cdr of it? Please don't
> say cons ;-)
From http://www.paulgraham.com/icad.html
"Macros (in the Lisp sense) are still, as far as I know, unique to Lisp.
This is partly because in order to have macros you probably have to make
your language look as strange as Lisp. It may also be because if you do
add that final increment of power, you can no longer claim to have
invented a new language, but only a new dialect of Lisp.
I mention this mostly as a joke, but it is quite true. If you define a
language that has car, cdr, cons, quote, cond, atom, eq, and a notation
for functions expressed as lists, then you can build all the rest of
Lisp out of it. That is in fact the defining quality of Lisp: it was in
order to make this so that McCarthy gave Lisp the shape it has."
And if you want to know more about the details you should read:
- http://www.paulgraham.com/rootsoflisp.html
- ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-453.pdf
- and/or Chapter 4.1 of http://mitpress.mit.edu/sicp/
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
David Steuber <·············@verizon.net> writes:
> What makes Lisp Lisp? What is the car and cdr of it? Please don't
> say cons ;-)
I was not at all sure what I was going to get in the way of responses
to this question. I did have a latent suspicion that the answer would
be similar to what I would give if someone asked me what C was.
I would say that C is a high level assembler language that gets you
away from the details of the specific machine but still allows you to
twiddle the machine's bits. C has a terse syntax and keeps you close
to the hardware.
Well, that's a start anyway. That answer doesn't really say all there
is to say about C. I imagine that like C, you have to work with Lisp
for a while to really know what it is.
From a previous thread, I was indirectly pointed to this web page:
http://www.oreilly.com/news/vhll_1299.html
I'm sure that it is related to my question in some way, but I can't
seem to express how.
--
One Editor to rule them all. One Editor to find them,
One Editor to bring them all and in the darkness bind them.
(do ((a 1 b) (b 1 (+ a b))) (nil a) (print a))
David Steuber <·············@verizon.net> writes:
> From a previous thread, I was indirectly pointed to this web page:
>
> http://www.oreilly.com/news/vhll_1299.html
>
> I'm sure that it is related to my question in some way, but I can't
> seem to express how.
I have only superficially skimmed the text but I think it is funny
that they manage not to mention Lisp at all (OK, they mumble something
about Scheme having been "retroactively added to the same family") and
trace "very high level languages" back to AWK. Fits with the O'Reilly
policy of actively ignoring Lisp for reasons that escape me.
Edi.
Edi Weitz <···@agharta.de> writes:
> I have only superficially skimmed the text but I think it is funny
> that they manage not to mention Lisp at all
I didn't want to mention that part ;-). Anyway, O'Reilly may be OK
for much of what they do, but they are not really Addison-Wessly or
Prentice Hall.
I don't know why they ignore Lisp. With CMUCL, CLISP, Mit Scheme,
etc, etc, you would think they could wrap up the online documentation
in paper and through in a couple value added pages to create more
books and revenue.
--
One Editor to rule them all. One Editor to find them,
One Editor to bring them all and in the darkness bind them.
(do ((a 1 b) (b 1 (+ a b))) (nil a) (print a))
····@goldshoe.gte.com (Dorai Sitaram) writes:
> Lisp could possibly be in the tent of Perl and Python, but those
> languages are designed to be cooperative, self-effacing tools that
> melt into an existing toolset. That is not the Lisp way.
Sorry, I can't see that. Yes, it might look as if Common Lisp was
mainly designed to be deployed on Lisp Machines, and, yes, sometimes
"newbies" on c.l.l are asked not to think in Perl or C when starting
to learn Lisp but that doesn't mean that Lisp is inherently unable to
cooperate.
Ask MCL users how well their Lisp "melts into the existing toolset",
look at the Unix/Linux integration of CLISP or CMUCL, check out the
OSI stuff from Franz, try for yourself how LispWorks can create
cross-platform apps which map to the underlying GUI toolkits on
Windows, Mac OS X, and Linux. So, what was your point?
Perl, on the other hand, was originally built to be a Unix tool and
nothing else. Last time I checked the Windows version was still not on
par and not actually a "good citizen" on Windows. But that of course
doesn't prevent O'Reilly from publishing "Perl on Windows" books...
Edi.
In article <··············@bird.agharta.de>, Edi Weitz <···@agharta.de> wrote:
>····@goldshoe.gte.com (Dorai Sitaram) writes:
>
>> Lisp could possibly be in the tent of Perl and Python, but those
>> languages are designed to be cooperative, self-effacing tools that
>> melt into an existing toolset. That is not the Lisp way.
>
>Sorry, I can't see that. Yes, it might look as if Common Lisp was
>mainly designed to be deployed on Lisp Machines, and, yes, sometimes
>"newbies" on c.l.l are asked not to think in Perl or C when starting
>to learn Lisp but that doesn't mean that Lisp is inherently unable to
>cooperate.
>
>Ask MCL users how well their Lisp "melts into the existing toolset",
>look at the Unix/Linux integration of CLISP or CMUCL, check out the
>OSI stuff from Franz, try for yourself how LispWorks can create
>cross-platform apps which map to the underlying GUI toolkits on
>Windows, Mac OS X, and Linux. So, what was your point?
May I ask what is yours? That O'Reilly is going
to cave in and start publishing Lisp books if only ...
if only what?
I don't think it's going to happen in our professional
lifetime (and if I'm wrong, I hope the book that bucked
the trend isn't called "Common Lisp Annoyances").
I gave you my reading of O'Reilly history on why this
is. I don't see Lisp solving even _one_ problem that
O'Reilly sees as confronting its reader base and that
isn't also solved to some satisfaction by more overtly
Unix-y means.
>Perl, on the other hand, was originally built to be a Unix tool and
>nothing else. Last time I checked the Windows version was still not on
>par and not actually a "good citizen" on Windows. But that of course
>doesn't prevent O'Reilly from publishing "Perl on Windows" books...
You seem to be arguing that Lisp is better than Perl! :)
That is, strangely perhaps, irrelevant. If O'Reilly
pushed Lisp, they would be advertising a tool
that works well on both Unix and Windows. By pushing
"Perl on Windows", they are bringing a piece of Unix to
Windows. Which act do you think better reflects their
Unixoid vision and mission? Which act do you think
will appeal to those of the Unix faithful that were
somehow marooned on Windows and were looking to
O'Reilly for comfort and guidance?
--
dorai!!ccs!neu!edu ······@/ | s/!/./g
····@goldshoe.gte.com (Dorai Sitaram) writes:
> In article <··············@bird.agharta.de>, Edi Weitz <···@agharta.de> wrote:
>
> >Sorry, I can't see that. Yes, it might look as if Common Lisp was
> >mainly designed to be deployed on Lisp Machines, and, yes,
> >sometimes "newbies" on c.l.l are asked not to think in Perl or C
> >when starting to learn Lisp but that doesn't mean that Lisp is
> >inherently unable to cooperate.
> >
> >Ask MCL users how well their Lisp "melts into the existing
> >toolset", look at the Unix/Linux integration of CLISP or CMUCL,
> >check out the OSI stuff from Franz, try for yourself how LispWorks
> >can create cross-platform apps which map to the underlying GUI
> >toolkits on Windows, Mac OS X, and Linux. So, what was your point?
>
> May I ask what is yours?
My original point was that O'Reilly is "actively ignoring" Lisp. Yes,
they also don't sell books about Cobol or Fortran, but they don't have
a page where they say "please don't send proposals for Cobol or
Fortran books", they only do this for "LISP" (sic).
Then you came in and said that O'Reilly is a Unix shop, that Unix
tools generally do one thing very well and are cooperative and that
Lisp isn't cooperative at all.
I just wanted to note, for the record, that I disagree with these
points: O'Reilly isn't a Unix shop (anymore) and Lisp isn't "blas�
about wanting to take over" (anymore).
> That O'Reilly is going to cave in and start publishing Lisp books if
> only ... if only what?
No, I don't think that. And I also haven't said that.
> I don't think it's going to happen in our professional lifetime
I agree with this. And, frankly, I don't care. I'll be happy if we'll
soon see a couple of good, new Lisp books but I don't care whoever
publishes them as long as they do a good job.
Let me add that O'Reilly certainly has a very good reputation as a
publisher of computer books, and rightly so - what they do they do
very good. However, I've seen young programmers who wouldn't even look
at a book if it wasn't published by O'Reilly. I think this a bit
extreme and I'd like these people to realize that a programming
language isn't bad or non-existent just because there's no O'Reilly
book about it...
Edi.
Edi Weitz <···@agharta.de> writes:
> I've seen young programmers who wouldn't even look
> at a book if it wasn't published by O'Reilly.
i suppose we must wait for someone w/ a lot of time
on their hands to write the "oh really?" series of
bitterly satirical programmer anti-dross.
(if anyone is already doing this, please provide texinfo.)
thi
Edi Weitz <···@agharta.de> wrote:
> ····@goldshoe.gte.com (Dorai Sitaram) writes:
>
>> Lisp could possibly be in the tent of Perl and Python, but those
>> languages are designed to be cooperative, self-effacing tools that
>> melt into an existing toolset. That is not the Lisp way.
>
> Sorry, I can't see that. Yes, it might look as if Common Lisp was
> mainly designed to be deployed on Lisp Machines, and, yes, sometimes
> "newbies" on c.l.l are asked not to think in Perl or C when starting
> to learn Lisp but that doesn't mean that Lisp is inherently unable to
> cooperate.
>
> Ask MCL users how well their Lisp "melts into the existing toolset",
> look at the Unix/Linux integration of CLISP or CMUCL, check out the
> OSI stuff from Franz, try for yourself how LispWorks can create
> cross-platform apps which map to the underlying GUI toolkits on
> Windows, Mac OS X, and Linux. So, what was your point?
>
> Perl, on the other hand, was originally built to be a Unix tool and
> nothing else. Last time I checked the Windows version was still not on
> par and not actually a "good citizen" on Windows. But that of course
> doesn't prevent O'Reilly from publishing "Perl on Windows" books...
Ah, but you miss the _other_ point, which is that Perl has become
their franchise.
After all, they are the publishers for the notable Perl Luminaries,
Larry Wall, Randall Schwartz, and Tom Christiansen. From having those
Top Perl Authors, they can readily build a "franchise" involving
selling all sorts of books related to Perl.
Similarly, they have something of a "franchise" surrounding Java;
whatever the Java-related topic, you can can buy something pretty
authoritative from them.
For them to "break into" the Lisp market would require that they
invest time, effort, and money searching for top notch authors, and
the equivalent luminaries are already associated with other
publishers. It would be an expensive exercise for them to become a
credible Lisp publisher, and it is not evident that this is really in
their interests.
I think it's more relevant to take Phil Hughes' recommendation to
heart:
"Rather than complaining, I suggest shopping where Linux is
appreciated." -- Phil Hughes <···@ssc.com>
If O'Reilly's editors aren't interested in publishing Lisp books, why
do you really want to fight against this? Wouldn't it be simpler to
take the business to a more appreciative publisher? If there's a good
book on "CL Database Programming," I don't very much care if it's
published by ORA or by APress.
--
let name="aa454" and tld="freenet.carleton.ca" in name ^ ·@" ^ tld;;
http://www.ntlug.org/~cbbrowne/languages.html
"Ah, fall - when leaves turn to burnished colors upon darkling
branches, collars are turned up against a wind which murmurs of
winter, and homework assignments appear on Usenet. <sigh>"
-- Bob Jarvis
Christopher Browne <········@acm.org> writes:
> If O'Reilly's editors aren't interested in publishing Lisp books,
> why do you really want to fight against this?
I don't want to fight against this - see my other post. I just want to
fight against the implicit assumption (not yours or Dorai's) that ORA
alone defines the IT landscape.
> If there's a good book on "CL Database Programming," I don't very
> much care if it's published by ORA or by APress.
Me neither.
Edi.
····@goldshoe.gte.com (Dorai Sitaram) wrote in message news:<············@news.gte.com>...
> In article <··············@bird.agharta.de>, Edi Weitz <···@agharta.de> wrote:
> >David Steuber <·············@verizon.net> writes:
> >
> >> From a previous thread, I was indirectly pointed to this web page:
> >>
> >> http://www.oreilly.com/news/vhll_1299.html
> >>
> >> I'm sure that it is related to my question in some way, but I can't
> >> seem to express how.
> >
> >I have only superficially skimmed the text but I think it is funny
> >that they manage not to mention Lisp at all (OK, they mumble something
> >about Scheme having been "retroactively added to the same family") and
> >trace "very high level languages" back to AWK. Fits with the O'Reilly
> >policy of actively ignoring Lisp for reasons that escape me.
>
> Lisp doesn't even attempt to play nicely with other
> Unix programs.
This above paragraph is dangerously wrong. What Lisp?
Common Lisp? You are trolling, right?
A lot of people are investing a lot of time to make
Lisp implementations nicely usable on Unix. Several of the
free and commercial Common Lisp implementations are
running usefully integrated on Unix.
People are able to access database, run Lisp as a login
shell, run Lisp has a CGI process for Apache, provide
web services, even act as an NFS server in Lisp for Unix, ...
Even a short look on http://www.cliki.net/
whould give you an idea that there are "some
people interested in exactly that area about
which you are talking. For example
http://www.cliki.net/Unix .
> It wants to be a Unix replacement. As
> a case in point, when somebody asked not so long ago
> about how to pass information to Lisp from the OS
> command line, the proffered advice was for the user to
> stay within Lisp itself and treat it as the operating
> environment, not as one tool among many in what the
> user considered to be the "real" operating environment.
Come on. This is FUD. Lots of people are able to pass
arguments to from the command line to the Common Lisp
implementation they are using.
> I chanced upon an old (out-of-print) book, _Unix Text
> Processing_, by Tim O'Reilly himself, et al.
> There is a palpable admiration for the fact that Unix
> tools concentrate on doing one thing,
Ha ha, that was wrong long ago and it is still wrong.
> very well if not
> in the most perfect manner, but then have a
> well-defined way they can interact with other, possibly
> yet unwritten, tools. Lisp wants to have everything
> done within itself. It is quite blas� about wanting to
> take over rather than cooperate. Why then would a Unix
> publishing shop want anything to do with it?
······@corporate-world.lisp.de (Rainer Joswig) writes:
> ····@goldshoe.gte.com (Dorai Sitaram) wrote in message news:<············@news.gte.com>...
>> Lisp doesn't even attempt to play nicely with other
>> Unix programs.
>
> This above paragraph is dangerously wrong. What Lisp?
> Common Lisp? You are trolling, right?
>
> A lot of people are investing a lot of time to make
> Lisp implementations nicely usable on Unix. Several of the
> free and commercial Common Lisp implementations are
> running usefully integrated on Unix.
> People are able to access database, run Lisp as a login
> shell, run Lisp has a CGI process for Apache, provide
> web services, even act as an NFS server in Lisp for Unix, ...
I think I'm probably one of these people, so I have some reasonable
basis for saying "yes, but ...". We're working on it, but the
situation is not (yet) entirely rosy.
Yes, but in almost all of these cases the emphasis is on accessing
Unix features from Lisp, rather than having Lisp accessible as a
tool that can be called from a typical unix setup. I can call a
shared library function from SBCL. I can even (after a certain amount
of fiddling around) call back into a Lisp function _from_ a shared
library. I can't (yet, anyway) create a shared library using Lisp
and have C code "running the show". And if I could I'd still expect
to have to step carefully to avoid stamping on the GC or the
Lisp memory areas or whatever else.
ECL might be a better bet for that kind of thing, granted.
>> a case in point, when somebody asked not so long ago
>> about how to pass information to Lisp from the OS
>> command line, the proffered advice was for the user to
>> stay within Lisp itself and treat it as the operating
>> environment, not as one tool among many in what the
>> user considered to be the "real" operating environment.
>
> Come on. This is FUD. Lots of people are able to pass
> arguments to from the command line to the Common Lisp
> implementation they are using.
In fairness, this may be more about comp.lang.lisp than Lisp itself.
Though the facilities exist to do this, I think that most of the
advice on cll to someone who appears to be coming from a unix
background is "you could do it like you say you want to, but you
don't really want to". Witness all the "how do I make a standalone
executable" threads which end up in arguments about what a standalone
executable actually is anyway.
>> There is a palpable admiration for the fact that Unix
>> tools concentrate on doing one thing,
>
> Ha ha, that was wrong long ago and it is still wrong.
Granted (why does ls -C exist when "ls | column" will do the job?).
But it's still what Unixoids claim is their philosophy, and it's a way
of working that's not well-supported by heavyweight Lisp applications
with 20Mb core files and a fasl format which is as near as possible
completely unshareable.
Mind you, Java has exactly the same problem - probably even more so,
in fact - and it doesn't seem to get beaten up as often or in quite
thwe same way. What gives there, then?
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Granted (why does ls -C exist when "ls | column" will do the job?).
> But it's still what Unixoids claim is their philosophy, and it's a way
> of working that's not well-supported by heavyweight Lisp applications
> with 20Mb core files and a fasl format which is as near as possible
> completely unshareable.
>
> Mind you, Java has exactly the same problem - probably even more so,
> in fact - and it doesn't seem to get beaten up as often or in quite
> thwe same way. What gives there, then?
This may be a case where Sun did something right. Of course I am
refering to marketing, not software design. ;-)
(eq 'perception 'reality)
t
--
One Editor to rule them all. One Editor to find them,
One Editor to bring them all and in the darkness bind them.
(do ((a 1 b) (b 1 (+ a b))) (nil a) (print a))
In article <····························@posting.google.com>,
Rainer Joswig <······@corporate-world.lisp.de> wrote:
>····@goldshoe.gte.com (Dorai Sitaram) wrote in message news:<············@news.gte.com>...
>> In article <··············@bird.agharta.de>, Edi Weitz <···@agharta.de> wrote:
>> >David Steuber <·············@verizon.net> writes:
>> >
>> >> http://www.oreilly.com/news/vhll_1299.html
>> >
>> >I have only superficially skimmed the text but I think it is funny
>> >that they manage not to mention Lisp at all (OK, they mumble something
>> >about Scheme having been "retroactively added to the same family") and
>> >trace "very high level languages" back to AWK. Fits with the O'Reilly
>> >policy of actively ignoring Lisp for reasons that escape me.
>>
>> Lisp doesn't even attempt to play nicely with other
>> Unix programs.
>
>This above paragraph is dangerously wrong. What Lisp?
>Common Lisp? You are trolling, right?
You may wish to (re)browse Kent Pitman's article on
political parties. Kent is the canonical non-troll of
this newsgroup, so reformulating the Unix vs Lisp
philosophy gap using his terminology may be more
persuasive to you.
>> There is a palpable admiration for the fact that Unix
>> tools concentrate on doing one thing,
>
>Ha ha, that was wrong long ago and it is still wrong.
Does it matter? It serves to highlight the difference
between the Unix and the Lisp ways. And your
witty reaction verifies that the difference does exist
and isn't going to get erased in any great hurry.
--
dorai @ ccs . neu . edu
David Steuber wrote:
> David Steuber <·············@verizon.net> writes:
>
>> What makes Lisp Lisp? What is the car and cdr of it? Please don't
>> say cons ;-)
I use, both, Lisp and C heavily. I have written compilers and embedded code
for many of my 30-ish years of programming. Maybe my meandering comments
will help spiral in towards your question about lisp:
Executive summary:
Lisp is used by people who value the idea of being able to choose the most
efficient programming paradigm to solve a problem and who are not afraid to
learn about and to mix paradigms as appropriate within the same body of
work. All of lisp's "features" (syntax, datatypes, closures, program
representation, etc) are necessary in allowing this freedom of choice for
the programmer. That's why those features are still there after 5 decades.
This act of choosing the best paradigm for a (sub)-problem is what I call
"architecting". No other text language I know supports architecture. Most
other languages are mono-paradigmatic or have a strictly bounded set of
usable paradigms. These languages are built for tradesmen (interchangeable
coders), whereas lisp is built for architects.
>
> I was not at all sure what I was going to get in the way of responses
> to this question. I did have a latent suspicion that the answer would
> be similar to what I would give if someone asked me what C was.
>
> I would say that C is a high level assembler language that gets you
> away from the details of the specific machine but still allows you to
> twiddle the machine's bits. C has a terse syntax and keeps you close
> to the hardware.
The idea - that C is a good assembler - is an urban myth. C is possibly
the *worst* assembler I have encountered. Good assemblers use a two-pass
structure, allowing declaration after use - C doesn't (this really, really
hurts when you try to write a compiler that emits C). C has an amateurish
notion of type that only gets in the way when you want to use C as an
assembler.
C is close to only one class of hardware - DEC PDP's (e.g. PDP11). For
example, C totally misses out on the Intel x86 architecture (hence, all of
the ugly kludges like "near" and "far").
C has a grossly bloated syntax compared to the syntax of lisp. C's syntax
cannot even be expressed in a context-independent manner (e.g. LR or LALR -
see "typedef").
C has ruined the word "macro", much as bad adolescents have ruined the word
"hacker".
C has glitches in its semantics, e.g. structs as args vs. other things as
args (this "feature" appeared during the transition from V6 to V7 Unix) and
the discontinuities when dealing with the meaning of arrays (which led to
some of the kludges in gcc).
C was beautiful at one time and had world-shaking effects, as did Pascal,
back in the 70's. It demonstrated that what "assembler programmers" were
doing at the time could be done in a "higher level" language. Small-C and
K&R and UCSD Pascal and Borland Turbo Pascal demonstrated that mortal
humans could understand what an HLL could do for them. If you were alive
and programming at that time, you know what a world-altering concept this
was.
Lisp, otoh, makes a great assembler. It has a uniform syntax, no goofy
rules that require declaration before use, etc.
Lisp is also very close to one class of hardware (others: remind me what it
was, I was only 1 year old when Lisp was invented in 1956). CAR means
"contents of address register", kind of like "++" means auto-increment.
CDR means "contents of decrement register. CONS means construct a car/cdr
cell (and malloc it).
Interestingly, Lisp's orignal hardware-ishness translates better to more
architectures than C's, even though C is 15 years younger than Lisp (mostly
because C tries to define operations on pointers beyond assignment and
dereferencing).
In addition, lisp defines GC (garbage collection) as a primitive/transparent
language feature. This makes lisp highly more modular and structured and
portable than C. In Lisp, the runtime system is allowed to deal with "new"
hardware architectural features, such as virtual memory, paging registers,
etc., whereas in C the concept of memory allocation is demodularized and
deportified by letting malloc leak manipulable pointers out to the
programmer. Lisp language implementors are allowed to make memory
management more efficient and less cumbersome than C language implementors
are allowed. Rhetorical question - the last time you wrote an efficient C
program using malloc, did you remember to take into account the issues of
locality of reference and paging characteristics of your particular
hardware platform (hint: a good generational GC will move objects and
pointers around so that they fit on the most efficient combination of VM
pages - did you do that in C?).
>
> Well, that's a start anyway. That answer doesn't really say all there
> is to say about C. I imagine that like C, you have to work with Lisp
> for a while to really know what it is.
I have been frustrated for decades trying to explain to C-only programmers
how the world opens up when you know lisp. Yes, it definitely helps to use
lisp on something "real".
Lisp's set of features allow one to program in a wide, wide range of
programming paradigms (I haven't found anything that comes close to lisp's
ability to accept new paradigms), for example:
Lisp's macros are hard to understand until you get intimate with them. To
add such capability to C, you would have to (at the least) build LEX and
YACC *into* the C language, then formally standardize the base C language
and make it available to the programmer. Every C compiler would have to
re-lex and re-yacc the language as it compiled source code. Every C
programmer would have to learn LEX, YACC and the details of the non-LR
syntax of C. The reason that lisp can do this same thing so effectively is
that lisp has a simple and uniform syntax (corollary - this is why all
attempts to "upgrade" the syntax of lisp fail - changing the syntax
instantly makes macros a lot harder to write and compile) and because the
source program is represented as a simple and programmer-accessible
first-class data structure.
The importance of closures and functions as first-class entities isn't
groked by non-lispers. C programmers tend to dismiss this as just another
use of pointers. They are missing all of the "emergent" properties of
being able to conveniently use these entities and paradigms. It's like
claiming that you understand everything about life on Earth because you
have discovered that DNA has four fundamental units CGTA and then stopping
the study of all the various lifeforms that emerge from these fundamental
units.
Closures and macros let lispers write other languages into their code - you
can have prolog when it makes sense, you can have OOP when it makes sense.
The result still looks like lisp. If you try this in C, you don't get very
far before you either quit (and go back to procedural programming) or build
a brand new language and compiler, as Stroustroup did with C++ and Gosling
did with Java. Guess what? Their stunted mindsets created new, improved
languages that *still* can't be extended. I easily added a prolog compiler
to my lisp code a few months back. I simply cannot do this with my C, C++,
Java code - the base languages are too stunted.
Lisp is used by people who value the idea of being able to choose the most
efficient programming paradigm to solve a problem and who are not afraid to
learn about and to mix paradigms as appropriate within the same body of
work.
pt
Paul Tarvydas wrote:
> Closures and macros let lispers write other languages into their code - you
> can have prolog when it makes sense, you can have OOP when it makes sense.
> The result still looks like lisp. If you try this in C, you don't get very
> far before you either quit (and go back to procedural programming) or build
> a brand new language and compiler, as Stroustroup did with C++ and Gosling
> did with Java. Guess what? Their stunted mindsets created new, improved
> languages that *still* can't be extended. I easily added a prolog compiler
> to my lisp code a few months back. I simply cannot do this with my C, C++,
> Java code - the base languages are too stunted.
C "macros" aren't completely limiting. I've used them to good
effect when defining my own Lisp dialect
(http://web.onetel.com/~hibou/Emblem.html),
effectively creating a new language in them. Here's a sample
piece of code. (Yes, it really is in ANSI standard C).
----------------------------
DefineF("let")
Local1 Car
Local2 /* initialize new env */
Prog(1)
Ret
Params(2)
Until Local1 Null Do
Local1 Caar /* var */
Local1 Cadar Free12 Call("eval") /* val in old env */
Local2 /* env */
ACons
SetLocal2 Pop /* update new env */
PopLocal1
Od
Free11 Cdr Local2 Call("progn") /* use new env */
Ret
Termin
-----------------------------
A few comments: it's the code for "let" used in the interpreter.
The interpreter is used (a) before the compiler has compiled
itself, (b) top level REPL, (c) code that is supplied as an
argument to "eval".
Everything else is incrementally compiled when defun or defmacro
is called, or compiled before first use if it is defined by
defmethod. (This ties in with the other thread "JIT for Lisp
..." -- part of the confusion with Lisp and interpretation I
think stems from people noticing that there's an interpreter,
and not realizing there's a compiler too).
It's reverse Polish, operating on a stack, like Forth.
This code (considered as C) just deposits the byte codes
into the byte code array. It does not actually run "let".
Had I not used #define for this, the C would have been
horrendous to write and maintain.
> Lisp is used by people who value the idea of being able to choose the most
> efficient programming paradigm to solve a problem and who are not afraid to
> learn about and to mix paradigms as appropriate within the same body of
> work.
Agreed. With Lisp, you extend the language to suit the
problem, so that solving the problem in the extended language
becomes trivial (rather than solving the problem in a
language not specifically designed for the problem, which
is in general much more effort). This is "bottom up programming"
as described in On Lisp.
> pt
--
:ugah179 (home page: http://web.onetel.com/~hibou/)
"I'm outta here. Python people are much nicer."
-- Erik Naggum (out of context)
Paul Tarvydas <········@attcanada.ca> writes:
> This act of choosing the best paradigm for a (sub)-problem is what I call
> "architecting". No other text language I know supports architecture. Most
> other languages are mono-paradigmatic or have a strictly bounded set of
> usable paradigms. These languages are built for tradesmen (interchangeable
> coders), whereas lisp is built for architects.
Being an "interchangeable coder" really sucks. I am trying to move
away from that.
I like the idea of being an architect. That is a good metaphor.
> The idea - that C is a good assembler - is an urban myth. C is possibly
> the *worst* assembler I have encountered. Good assemblers use a two-pass
> structure, allowing declaration after use - C doesn't (this really, really
> hurts when you try to write a compiler that emits C). C has an amateurish
> notion of type that only gets in the way when you want to use C as an
> assembler.
I learned C from the K&R book (the original). I believed what the
horse said because my prior experience was in BASIC and FORTRAN 77.
It seemed quite true to me. I didn't change my mind when I started
mixing 386/387 assembler into my code. I was rather surprised at the
redundant loading of the segment register though when I looked at the
intermediate assembly (Borland C++ 2.0).
I remember liking TASM and its ideal mode syntax.
> C is close to only one class of hardware - DEC PDP's (e.g. PDP11). For
> example, C totally misses out on the Intel x86 architecture (hence, all of
> the ugly kludges like "near" and "far").
Don't forget "huge". Damn that's a big pointer!
> C has a grossly bloated syntax compared to the syntax of lisp. C's syntax
> cannot even be expressed in a context-independent manner (e.g. LR or LALR -
> see "typedef").
One thing I liked about assembler was the simple syntax. Although
Intel's lack of registers is quite infuriating.
> C has ruined the word "macro", much as bad adolescents have ruined the word
> "hacker".
I hate C macros. I really hate seeing them in C++ since C++ was
supposed to make them obsolete.
> Lisp, otoh, makes a great assembler. It has a uniform syntax, no goofy
> rules that require declaration before use, etc.
Yes, I like the symplicity of Lisp syntax. However, special forms
throw me. I hate exceptions to the rule. Or maybe I don't yet get
what is special about special forms.
Would the fact that Lisp makes a great assembler make it a low level
programming language?
> Rhetorical question - the last time you wrote an efficient C program
> using malloc, did you remember to take into account the issues of
> locality of reference and paging characteristics of your particular
> hardware platform (hint: a good generational GC will move objects
> and pointers around so that they fit on the most efficient
> combination of VM pages - did you do that in C?).
I never wrote my own malloc or new for that matter. Locality of
memory was something I simply never thought of.
> The importance of closures and functions as first-class entities isn't
> groked by non-lispers. C programmers tend to dismiss this as just another
> use of pointers. They are missing all of the "emergent" properties of
> being able to conveniently use these entities and paradigms. It's like
> claiming that you understand everything about life on Earth because you
> have discovered that DNA has four fundamental units CGTA and then stopping
> the study of all the various lifeforms that emerge from these fundamental
> units.
I am having difficulty with the concept of closures. To me they look
like C callbacks or C++ objects that are a member of some class, that
is they support the required interface. Or a Java interface object.
> Closures and macros let lispers write other languages into their code - you
> can have prolog when it makes sense, you can have OOP when it makes sense.
> The result still looks like lisp. If you try this in C, you don't get very
> far before you either quit (and go back to procedural programming) or build
> a brand new language and compiler, as Stroustroup did with C++ and Gosling
> did with Java. Guess what? Their stunted mindsets created new, improved
> languages that *still* can't be extended. I easily added a prolog compiler
> to my lisp code a few months back. I simply cannot do this with my C, C++,
> Java code - the base languages are too stunted.
>
> Lisp is used by people who value the idea of being able to choose the most
> efficient programming paradigm to solve a problem and who are not afraid to
> learn about and to mix paradigms as appropriate within the same body of
> work.
Mixing paradigms is something I've done in C++ and Perl. I've never
been into pure OO. Then again, an int is just an object of type int
and a function is a function object. I also tend to doodle in the
editor because I never know the solution to a problem before I solve
it. I highly doubt I will ever be a fan of UML.
--
One Editor to rule them all. One Editor to find them,
One Editor to bring them all and in the darkness bind them.
(do ((a 1 b) (b 1 (+ a b))) (nil a) (print a))
David Steuber <·············@verizon.net> writes:
> Being an "interchangeable coder" really sucks. I am trying to move
> away from that.
>
> I like the idea of being an architect. That is a good metaphor.
well, even architects can be interchangeable, according to management
(who are usually the most interchangeable but yet least willing to admit
to it).
i think rather than fixate on an organizational title (not to imply this
is what you're doing but only to mention it as a potential pitfall (that
i have some experience with)) as the metaphor, it's more interesting to
cast an eye over the types of communication flowing in an organization:
between those different roles, among peers, from external to internal
(and vice versa), in circles, in spirals, in "shit flows uphill to make
for promising quarterly reports" homilies, etc; as a metaphorical basis
for programming language comparison.
then, of course, do the same analysis, varying time and forcing
functions.
thi
David Steuber wrote:
> Yes, I like the symplicity of Lisp syntax. However, special forms
> throw me. I hate exceptions to the rule. Or maybe I don't yet get
> what is special about special forms.
Both functions and macros can be defined using other functions and
macros. However at some level, you need a core language that is not
further defined in terms of other functions and macros - otherwise you
would run into an infinite regress. The special forms (or better:
operators) are just this core language.
The good thing about the set of special operators in Common Lisp is that
it is fixed.
http://www.lispworks.com/reference/HyperSpec/Body/03_ababa.htm#clspecialops
lists all of them.
> I am having difficulty with the concept of closures. To me they look
> like C callbacks or C++ objects that are a member of some class, that
> is they support the required interface. Or a Java interface object.
See http://c2.com/cgi/wiki?ScopeAndClosures for some explanation.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> David Steuber wrote:
>
> > Yes, I like the symplicity of Lisp syntax. However, special forms
> > throw me. I hate exceptions to the rule. Or maybe I don't yet get
> > what is special about special forms.
>
> Both functions and macros can be defined using other functions and
> macros. However at some level, you need a core language that is not
> further defined in terms of other functions and macros - otherwise you
> would run into an infinite regress. The special forms (or better:
> operators) are just this core language.
Couldn't you avoid the infinite regress with tail-recursion? ;-)
> The good thing about the set of special operators in Common Lisp is
> that it is
> fixed. http://www.lispworks.com/reference/HyperSpec/Body/03_ababa.htm#clspecialops
> lists all of them.
Are Lisp implimentatons typicaly based on this set of primatives,
since Lisp can be written in Lisp, or are other primatives, er
operators, added for reasons of pragmatism?
> > I am having difficulty with the concept of closures. To me they look
> > like C callbacks or C++ objects that are a member of some class, that
> > is they support the required interface. Or a Java interface object.
>
> See http://c2.com/cgi/wiki?ScopeAndClosures for some explanation.
Ok, you just wanted me to find my way to your home page, didn't you?
There is a fair bit to read there. Thanks for the link. BTW, I like
that mac finder icon smashing the windows icon.
--
One Editor to rule them all. One Editor to find them,
One Editor to bring them all and in the darkness bind them.
(do ((a 1 b) (b 1 (+ a b))) (nil a) (print a))
In article <··············@verizon.net>,
David Steuber <·············@verizon.net> wrote:
> > The good thing about the set of special operators in Common Lisp is
> > that it is
> > fixed.
> > http://www.lispworks.com/reference/HyperSpec/Body/03_ababa.htm#clspecialops
> > lists all of them.
>
> Are Lisp implimentatons typicaly based on this set of primatives,
> since Lisp can be written in Lisp, or are other primatives, er
> operators, added for reasons of pragmatism?
I don't know the details of how to design a good set of special
operators for a Lisp dialect. I would be interested to learn something
about that as well. Perhaps someone else can give some hints?
> > > I am having difficulty with the concept of closures. To me they look
> > > like C callbacks or C++ objects that are a member of some class, that
> > > is they support the required interface. Or a Java interface object.
> >
> > See http://c2.com/cgi/wiki?ScopeAndClosures for some explanation.
>
> Ok, you just wanted me to find my way to your home page, didn't you?
Shit, this was too obvious. I need to be more subservise the next time.
;)
> There is a fair bit to read there. Thanks for the link. BTW, I like
> that mac finder icon smashing the windows icon.
I have stolen this from someone else's webpage, but I don't remember
anymore where I found it...
Pascal
Pascal Costanza <········@web.de> writes:
> In article <··············@verizon.net>,
> David Steuber <·············@verizon.net> wrote:
> > > The good thing about the set of special operators in Common Lisp is
> > > that it is fixed.
> > > http://www.lispworks.com/reference/HyperSpec/Body/03_ababa.htm#clspecialops
> > > lists all of them.
> >
> > Are Lisp implimentatons typicaly based on this set of primatives,
> > since Lisp can be written in Lisp, or are other primatives, er
> > operators, added for reasons of pragmatism?
>
> I don't know the details of how to design a good set of special
> operators for a Lisp dialect. I would be interested to learn something
> about that as well. Perhaps someone else can give some hints?
It's a balance between efficiency and correctness, like any toolkit
design. You pick a set that is large enough to implement all the
common cases efficiently, and small and simple enough that you can
implement it correctly.
Interpreters and compilers will end up with different choices, because
the implementation techniques are so different. For an interpreter,
it quite simple to write special operator implementations as auxiliary
functions of EVAL (see any textbook with a meta-circular Lisp
implementation), and you would want to do this for many common macros,
especially in an interpreter where the alternative is to recompute the
macroexpansion every time. For a compiler, generating correct code
for all cases is very important and non-trivial, so expanding macros
to a simple set of special operators is indicated; the ones that I've
seen end with pretty much the list of Figure 3-2 (usually with
M-V-BIND replacing M-V-CALL). Extra variables and unnecessary
branches introduced by the macros are eliminated in the optimizer
phases of compilation.
It should be noted that there are other "building blocks" of Lisp
implementations besides the operator set. For example, the important
building blocks CAR, CDR, CONS, and CONSP.
--
Pekka P. Pirinen
Adams Principle 42: The usefulness of an answer is proportional to
the meaningfulness of the problem statement. - Greg Menke
David Steuber wrote:
> Yes, I like the symplicity of Lisp syntax. However, special forms
> throw me. I hate exceptions to the rule.
Rules are ok as a rule, but we should not be slaves to them. Then we are
forced, eg, to make a Java anonymous class just to get an anonymous
function, because "everything is an object!". Or how about the screwed
up evaluation of infix arithmetic in Smalltalk because everything is
message-passing?
The bigger point in all this is that Lisp is the most pragmatic of
languages in its design, so things work the way you want them to work,
arbitrary rules be damned.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
> David Steuber wrote:
> > Yes, I like the symplicity of Lisp syntax. However, special forms
> > throw me. I hate exceptions to the rule.
>
> Rules are ok as a rule, but we should not be slaves to them.
As a rule, we should only be slaves to rule-generating meta-rules, and to this one.
:)
David Steuber wrote:
>
> Paul Tarvydas <········@attcanada.ca> writes:
>
> > This act of choosing the best paradigm for a (sub)-problem is what I call
> > "architecting". No other text language I know supports architecture. Most
> > other languages are mono-paradigmatic or have a strictly bounded set of
> > usable paradigms. These languages are built for tradesmen (interchangeable
> > coders), whereas lisp is built for architects.
It would be better to say "lisp is built for craftsmen".
> Being an "interchangeable coder" really sucks. I am trying to move
> away from that.
It does indeed. Not having a job sucks even more though.
> I like the idea of being an architect. That is a good metaphor.
It is not a good metaphor. Software construction bears
no resemblance whatsoever to building construction.
In any case, Christopher Alexander (whose books perhaps you
should read) thinks that modern architecture is bankrupt.
--
:ugah179 (home page: http://web.onetel.com/~hibou/)
"I'm outta here. Python people are much nicer."
-- Erik Naggum (out of context)
Donald Fisk wrote:
>> I like the idea of being an architect. That is a good metaphor.
>
> It is not a good metaphor. Software construction bears
> no resemblance whatsoever to building construction.
I'd be interested to know why you think there is no resemblance. Can you
expand?
thanx
pt
Paul Tarvydas wrote:
> Donald Fisk wrote:
>
>
>>>I like the idea of being an architect. That is a good metaphor.
>>
>>It is not a good metaphor. Software construction bears
>>no resemblance whatsoever to building construction.
>
>
> I'd be interested to know why you think there is no resemblance. Can you
> expand?
>
> thanx
> pt
Software is almost entirely organised- one part corresponds to one function.
Traditional buildings are almost entirely holistic- the wall defines
space, supports the roof, provides thermal insulation etc.
Modern architecture, at least at the time that Alexander was writing,
was tending towards the modular and organised functional approach. His
books, as far as I can tell (I don't own a copy and only skimmed one
some time ago, but have read much of the software patterns literature)
try to go against this towards more holistic forms.
In this Aledander was trying for a modular holism, which is better than
what software engineers were doing in the 1980s, but not as good as the
building engineers were doing in the 1780s (or any other time in history).
Pete
pete kirkham wrote:
Thank you. I think that I understand your description of architecture, but
I still seem to reach a different conclusion - architecture is necessary in
software development and some people strive (possibly unkowningly) towards
being "good" software architects. [I think that the current
state-of-the-art in software architecture is poor and can certainly be
improved].
> Software is almost entirely organised- one part corresponds to one
> function.
If this were true, then there would be no need for regression testing,
system testing, integration and schedules would never slip. "Something" is
causing system-wide effects, even when the software system is made up of
totally understandable functional units. I call this "something"
"architecture" (and, I guess, I am trying to confirm whether I am using
this word correctly).
One example of something that has system-wide effect is the choice of data
structures. If you choose badly, code everywhere is impacted. (E.g. the
use of strings inside of a compiler instead of tokens).
Am I making sense, or have I totally missed your point?
thanx
pt
Paul Tarvydas wrote:
> pete kirkham wrote:
>
> Thank you. I think that I understand your description of architecture, but
> I still seem to reach a different conclusion - architecture is necessary in
> software development and some people strive (possibly unkowningly) towards
> being "good" software architects. [I think that the current
> state-of-the-art in software architecture is poor and can certainly be
> improved].
>
>
>>Software is almost entirely organised- one part corresponds to one
>>function.
>
>
> If this were true, then there would be no need for regression testing,
> system testing, integration and schedules would never slip.
Yes, I meant 'good software that we should aspire to write'; the
metaphor is supposed to be aspirational.
Most real software somewhat less than perfect.
> "Something" is
> causing system-wide effects, even when the software system is made up of
> totally understandable functional units. I call this "something"
> "architecture" (and, I guess, I am trying to confirm whether I am using
> this word correctly).
So would I, but instead of the tight coupling between functions which
makes good buildings, good software is often chacterised by
architectures with loose coupling.
> One example of something that has system-wide effect is the choice of data
> structures. If you choose badly, code everywhere is impacted. (E.g. the
> use of strings inside of a compiler instead of tokens).
>
> Am I making sense, or have I totally missed your point?
better sense than I
Pete
pete kirkham wrote:
> So would I, but instead of the tight coupling between functions which
> makes good buildings, good software is often chacterised by
> architectures with loose coupling.
Actually, I would argue that good architecture is not characterized by
"loose" (or looser) coupling, but by *visible* coupling.
All state-of-the-art software is insanely-tightly-coupled, due to the
underlying use of CALL/RETURN. Most functions have a long chain of
invisible dependencies (i.e. bug enhancers). Corralling and restricting
such chains is one of the steps in architecture.
thanx
pt
Donald Fisk <················@enterprise.net> writes:
> So it might not be that all architects have lost The Timeless Way.
> It might be that only a few ever had it, and that only those
> buildings which have Quality Without A Name survive from earlier
> periods.
But note that Alexander considers this kind of building to be more or
less impossible within the United States given the AIA's influence
over contracts and project relationships, prohibitive building codes,
and the entire construction products and methods industry arranged
around a whole different way of thinking.
I recall him telling us in class (undergraduate architecture,
1992/1993) that making buildings like he proposes requires one to
forgo the so-called "professional" architectural endeavor and become a
criminal. So many rules would need to be broken, so many "best
practices" ignored, that one must operate above the law to get this
kind of work done. It was intimidating to hear. Few fellow students
could promise to dig in like that.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Yes, the dig at late '60s modern architects was a slight overstatement.
Over the weekend, it struck me that software isn't so much like a
cathederal but more like a ger (eg
http://www.pbm.com/~lindahl/articles/yurt/).
Each part is almost entirely single-function, it is portable, has
modular replaceable components, extensible (it you want a city you just
put a few hundred together on a plain), scalable (Genghis Khan had a
really big one), maintainable. And the smoke generated by the users
drives the bugs out.
We also might want to learn from post-modern architecture, such as the
eco-building movement and self build rather than the hierarchic
architect in charge model (not that Alexander's Origon project was like
that- his use of patterns was to restrain the end users enough to
prevent them building something terrible that they were freed to build
something good).
I also would recommend Gabriel's writings, but there's a difference from
the feeling I get from him, and that from groups like Rational and the
UML architechure-is-central approach.
Pete
pete kirkham <············@cafemosaic.co.uk> writes:
>
> I also would recommend Gabriel's writings, but there's a difference
> from the feeling I get from him, and that from groups like Rational
> and the UML architechure-is-central approach.
>
The Rational/UML people scare me. Whenever its pitched to me, I start
to get the feeling that the red-hot pincers, iron maidens and
stretching racks all disguised as Modern Software Development Tools
are in the offing- waiting only for the Word of Deployment.
Gregm
In article <··············@verizon.net>,
David Steuber <·············@verizon.net> wrote:
> Yes, I like the symplicity of Lisp syntax. However, special forms
> throw me. I hate exceptions to the rule. Or maybe I don't yet get
> what is special about special forms.
Functions in Lisp (or pretty much any other language other than Algol60)
evaluate their arguments *exactly* one time.
A special form might not evaluate some of its arguments at all, or might
evaluate some multiple times.
e.g.
* (/ 3 0)
Arithmetic error DIVISION-BY-ZERO signalled.
Operation was KERNEL::DIVISION, operands (3 0).
* (defun safe/ (a b) (and (/= b 0)) (/ a b))
SAFE/
* (safe/ 3 0)
NIL
*
"and" is a special form, because if the first argument is false then it
doesn't evaluate the second argument. You could't write "and" as a
function becasue you'd get a divide by zero error before you got into
the function.
> I am having difficulty with the concept of closures. To me they look
> like C callbacks or C++ objects that are a member of some class, that
> is they support the required interface. Or a Java interface object.
A closure is like a C callback that has an additional "userData"
argument. As examples see just about any of the callbacks in the
original Macintosh toolbox. They understood the need, even though they
were programming in Pascal or assembler.
It is also like a C++ or Java object that has some data and a method
with a well-known name, such as "doIt".
The difference is that the compiler does all the drudge work for you.
It figures out what variables from the context you need, arranges to
declare an appropriate struct for them, allocates it on the heap (if
necessary -- it isn't always), fills it in for you, automatically saves
a pointer to the struct and passes it into your function. And deletes
it when it's no longer required.
-- Bruce
>>>>> "Bruce" == Bruce Hoult <·····@hoult.org> writes:
Bruce> In article <··············@verizon.net>,
Bruce> David Steuber <·············@verizon.net> wrote:
> Yes, I like the symplicity of Lisp syntax. However, special forms
>> throw me. I hate exceptions to the rule. Or maybe I don't yet
>> get what is special about special forms.
Bruce> Functions in Lisp (or pretty much any other language other
Bruce> than Algol60) evaluate their arguments *exactly* one time.
..or pretty much any other language other than Algol60 *and modern lazy
functional languages*...
Immanuel
I've taken advantage of the "short circuiting" rule in Perl with
regard to conditional expressions.
Lazy evaluation is a good thing.
--
One Editor to rule them all. One Editor to find them,
One Editor to bring them all and in the darkness bind them.
(do ((a 1 b) (b 1 (+ a b))) (nil a) (print a))
On 8429 day of my life Bruce Hoult wrote:
> * (defun safe/ (a b) (and (/= b 0)) (/ a b))
Probably, you mean
(defun safe/ (a b) (and (/= b 0) (/ a b)))
--
Ivan Boldyrev
Onions has layers. Unix has layers too.
Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
> On 8429 day of my life Bruce Hoult wrote:
> > * (defun safe/ (a b) (and (/= b 0)) (/ a b))
>
> Probably, you mean
>
> (defun safe/ (a b) (and (/= b 0) (/ a b)))
NIL is not a number, is it? I didn't see Bruce's article and don't
know what the discussion is really about, but this function is bad
because if it is passed zero as second parameter, it will return NIL.
If that is not checked immediately, it will cause problems when you
will want to do calculations with the returned value later.
This might be better:
(defun safe/ (a b)
(assert (/= b 0) (b)
"Cannot divide ~S by 0." a)
(/ a b))
But I don't see the point, because / function will rise the
DIVISION-BY-ZERO error anyway. (The assert provides a way to continue
in the this case, thought.)
--
Janis Dzerins
If million people say a stupid thing, it's still a stupid thing.
On 8434 day of my life Janis Dzerins wrote:
> Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
>
>> On 8429 day of my life Bruce Hoult wrote:
>> > * (defun safe/ (a b) (and (/= b 0)) (/ a b))
>>
>> Probably, you mean
>>
>> (defun safe/ (a b) (and (/= b 0) (/ a b)))
>
> NIL is not a number, is it? I didn't see Bruce's article and don't
> know what the discussion is really about,
It is about special forms, and 'and is simple example of such a form.
Nothing more.
--
Ivan Boldyrev
"Assembly of Japanese bicycle require great peace of mind."
In article <···············@gulbis.latnet.lv>,
Janis Dzerins <·····@latnet.lv> wrote:
> Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
>
> > On 8429 day of my life Bruce Hoult wrote:
> > > * (defun safe/ (a b) (and (/= b 0)) (/ a b))
> >
> > Probably, you mean
> >
> > (defun safe/ (a b) (and (/= b 0) (/ a b)))
Eeek. I don't know how that happened! I really *did* run that code in
CMUCL, and it worked when I tried it with (safe/ 3 0).
> NIL is not a number, is it? I didn't see Bruce's article and don't
> know what the discussion is really about
The discussion was about "what is a special form".
-- Bruce
Dorai Sitaram <····@gte.com> wrote:
+---------------
| Lisp is not in that tent. Lisp could possibly be in the tent
| of Perl and Python, but those languages are designed to be
| cooperative, self-effacing tools that melt into an existing
| toolset. That is not the Lisp way.
+---------------
Gee, then I guess all those CGI scripts [sitting between Apache
and PostgreSQL] I've been writing in Common Lisp over the past
year (and similar ones I was writing in Scheme for several years
before I came over to the dark side) were all just a fig newton
of my imagination...?!?
As well as all the little 1-, 2-, 20-, 50-liners I've been including
in shell pipelines over the past decade...?!?
Sorry to disagree, but the Lisp way certainly *includes* the
"fitting in" style, as well as the monolithic "Lisp is the universe"
style and the "call out/in to others with an FFI" style and the
"talk to other pieces over pipes/sockets" style and a dozen other
styles. To borrow a saying from another language: "There is more
than just one ``Lisp way''".
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607