What's so great about lisp?
I had to use lisp in college for a course, and it looked like a
horribly primitive and useless contraption. We even had to use emacs to
use it, in the 21 century!. I have avoided it ever since. However I
find more and more people rhapsodizing about how cool Lisp is and what
an advanced language it supposedly is. I just don't get it: I mean do
those people claim that we have made no progress in all the years since
the early days of computing when lisp was used?
I'd like to know, what's the secret?
Regards
--
Kris.

Kris Cipa wrote:
> What's so great about lisp?

See http://wiki.alu.org:80/Success_Stories and 
http://wiki.alu.org:80/Evaluate_Lisp


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

"Kris Cipa" <kristinacipa@yahoo.co.nz> writes:

> What's so great about lisp?
> I had to use lisp in college for a course, and it looked like a
> horribly primitive and useless contraption. We even had to use emacs to
> use it, in the 21 century!. I have avoided it ever since. However I
> find more and more people rhapsodizing about how cool Lisp is and what
> an advanced language it supposedly is. I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?
> I'd like to know, what's the secret?
> Regards
> --
> Kris.
>

Well, I'm not an expert on the history of programming languages, but
as far as I can see most of the "new and cool" features of current
programming languages existed on the Lisp arena for a really long
time. So I think the answer is yes, we didn't made too much
progress. Of course this is just an idea of a Lisp newbie...

To how intresting Lisp can be, I recommend you to start by watching
Rainer Joswig's Lisp Machine videos [1]. Then, you can read Pascal
Costanza's Hİghly Opinionated Guide to Lisp [2]. I think these will
show you some of the secrets about Lisp.

[1] http://lispm.dyndns.org/
[2] http://p-cos.net/lisp/guide.html

PS: Emacs is not a requirement for Lisp programming, but it makes life
a lot easier. Take a look at SLIME
(http://common-lisp.net/project/slime/).

-- 
Love Respect GNU/Linux
########################################################################
BOFH excuse #431:
  
Borg implants are failing
########################################################################
Tonguç Yumruk

On 2005-09-23 12:40:26, Kris Cipa wrote:

> What's so great about lisp?

After all those years it still attracts programming language trolls.

At 23 Sep 2005 03:40:26 -0700,
Kris Cipa wrote:
> 
> What's so great about lisp?
> I had to use lisp in college for a course, and it looked like a
> horribly primitive and useless contraption.

That would be a good description for C or Java (C being primitive but
perhaps not useless).

> We even had to use emacs to use it, in the 21 century!.

Do you know a better alternative (a free, programmable, general
purpose text-editor that makes it easy to edit lisp programs)?

> I have avoided it ever since. However I find more and more people
> rhapsodizing about how cool Lisp is and what an advanced language it
> supposedly is.

People are rhapsodizing about many languages.  Read the newsgroups
about Ruby, Ocaml, Haskell, scheme...  In a way they are all right.
However people who are advocating these languages usually know more
languages than people who say they like Java.

> I just don't get it: I mean do those people claim that we have made
> no progress in all the years since the early days of computing when
> lisp was used? I'd like to know, what's the secret?

Lisps have progressed since that time.  The lisps that are used now
are not the same as the lisps in the early days of computing.  What
has remained is what makes lisp different from other languages, namely
the use of s-expressions for code.  This allows for a great
flexibility (e.g. macro's, code generation).  And there is of course a
lot more, for which there is enough information on the net.

Kristof Bastiaensen

Kris Cipa wrote:
> I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?

Well, the majority doesn't use FORTRAN anymore, but moved on to C 
dialects (like Java).  The minority moved on from LISP 1.5 to Common 
Lisp, Scheme, ML, Haskell and other more modern languages.

The mainstream made lots of progress, in gradually picking up Lisp 
features (dynamic memory, garbage collection, dynamic typing).  They 
emulate macros by using XML and code generating programs on it.

> I'd like to know, what's the secret?

If you are really interested, read Practical Common Lisp and On Lisp, 
otherwise just ignore the Lisp world.  Your choice...

-- 
My mouth says the words, my brain is thinking monstertrucks.
Joey (Friends)

I know one should not answer things like this, but maybe just a little
bit won't hurt :)

In <1127472026.869368.13690@z14g2000cwz.googlegroups.com> "Kris Cipa" <kristinacipa@yahoo.co.nz> writes:
>What's so great about lisp?

Many things.  Which, depends on which lisp language (or implementation)
you are talking about.

A few that come to my mind include:
 * symbols
 * lists
 * write representations (s-expressions)
 * homoiconicity
 * first-class functions
 * closures
 * recursion
 * debugging
 * REPL
 * dynamic typing
 * side-effectlessness
 * good macros
 * smart compilers
(... of course, the list could go on forever...)

>I mean do those people claim that we have made no progress in all the
>years since the early days of computing when lisp was used?

This question is too imprecise: first, "those people" certainly does not
include _all_ Lisp aficionados; second, Lisp has not ceased to be used,
so it's hard to say which time "when lisp was used" refers to; third, as
there has been much progress in Lisp since its birth, so the claim
wouldn't hold even if the other languages had not progressed at all;
fourth, since Lisp's influence on other languages is so vast (for
example, the birth of procedural programming is in part due to Lisp and
the birth of OOP is definitely affected by Lisp) it's not possible to
separate the progress of other programming languages from the progress
of Lisp.

But still, if you would ask whether _I_ claim that programming
environments and languages (not "we") have made no progress since the
days when Lisp machines were still actively developed, I would say,
"yes".  Which, of course, doesn't mean there hasn't been a lot of
progress in communication media, everyday usage of cryptography,
licensing, and availability of cheap hardware.

Panu

-- 
personal contact: atehwa@iki.fi, +35841 5323835, +3589 85619369
work contact: panu.kalliokoski@helsinki.fi, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/

"Kris Cipa" <kristinacipa@yahoo.co.nz> writes:

> What's so great about lisp?

Nothing at all,
It is just like human proliferation:
Any person can do it.
But for all its greatness to be enjoyed, one must be smart enough to learn.

Cor

-- 
To really make a mess of things one should use a computer

In <87mzm3gawf.wl%kristof@vleeuwen.org> Kristof Bastiaensen <kristof@vleeuwen.org> writes:

>> example, the birth of procedural programming is in part due to Lisp and
>> the birth of OOP is definitely affected by Lisp) it's not possible to
>While I mostly agree with this paragraph, isn't the birth of OOP more
>attributable to smalltalk?  Early smalltalk systems had some features
>of lisp (such as garbage collection), but the OOP system was quite a
>different paradigm from lisp.  Lisps only later caught on with OOP.
>IMHO support for OOP is one of the weak spots in scheme and lisp.

Well, depends on your definition of "attributable".  As Alan Kay says,
some parts of Smalltalk's designs are attributable to Lisp; and the
theoretical foundations of OOP lie in "frame networks", which were
invented to model concepts in symbolic AI programs, developed on, you
guessed it, Lisp systems.

Now, about the following I'm not sure: I think the reason why language
support for OOP in Lisp was introduced so late is that it was too easy
to implement _within_ the language.  You can write a very advanced,
delegation-based object system with multiple inheritance in a hundred
lines of Scheme; everybody just made up their _own_ object systems if
they wanted one and it took a _long_ time to standardise an object
system that would not irritate anybody.

That said, Lisp machines had OO facilities (such as flavors) at the same
time that Smalltalk machines had OO facilities, so I don't think the
statement "only later caught on" holds.

Panu

-- 
personal contact: atehwa@iki.fi, +35841 5323835, +3589 85619369
work contact: panu.kalliokoski@helsinki.fi, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/

> I mean do
> those people claim that we have made no progress
> in all the years since
> the early days of computing when lisp was used?

  It's funny I read this today.  Yesterday I picked up a system
engineering book from 1977.  You know what I found in it?  The problems
they had 30 years ago are the *EXACT* same problems we face today.
Nothing has changed.  Nothing has improved.  As smart as we like to
think we are, the software development industry is going in circles.

  I think the return to lispishness by so many languages is showing
that we know how to write software.  We've always known.  The problems
we have getting predictable, quality software on a large scale don't
originate at the keyboard.  That tells me that new languages aren't
going to help.

  I have a lot of ideas about what will help, but I'm sure this the
wrong place for THAT rant.  :)

-Ben

At 23 Sep 2005 12:55:31 GMT,
Panu Kalliokoski wrote:
> <snip>
> 
> >I mean do those people claim that we have made no progress in all the
> >years since the early days of computing when lisp was used?
> 
> This question is too imprecise: first, "those people" certainly does not
> include _all_ Lisp aficionados; second, Lisp has not ceased to be used,
> so it's hard to say which time "when lisp was used" refers to; third, as
> there has been much progress in Lisp since its birth, so the claim
> wouldn't hold even if the other languages had not progressed at all;
> fourth, since Lisp's influence on other languages is so vast (for
> example, the birth of procedural programming is in part due to Lisp and
> the birth of OOP is definitely affected by Lisp) it's not possible to
> separate the progress of other programming languages from the progress
> of Lisp.
>

While I mostly agree with this paragraph, isn't the birth of OOP more
attributable to smalltalk?  Early smalltalk systems had some features
of lisp (such as garbage collection), but the OOP system was quite a
different paradigm from lisp.  Lisps only later caught on with OOP.
IMHO support for OOP is one of the weak spots in scheme and lisp.

Kristof Bastiaensen

Kristof Bastiaensen wrote:
> At 23 Sep 2005 12:55:31 GMT,
> Panu Kalliokoski wrote:
> 
>><snip>
>>
>>>I mean do those people claim that we have made no progress in all the
>>>years since the early days of computing when lisp was used?
>>
>>This question is too imprecise: first, "those people" certainly does not
>>include _all_ Lisp aficionados; second, Lisp has not ceased to be used,
>>so it's hard to say which time "when lisp was used" refers to; third, as
>>there has been much progress in Lisp since its birth, so the claim
>>wouldn't hold even if the other languages had not progressed at all;
>>fourth, since Lisp's influence on other languages is so vast (for
>>example, the birth of procedural programming is in part due to Lisp and
>>the birth of OOP is definitely affected by Lisp) it's not possible to
>>separate the progress of other programming languages from the progress
>>of Lisp.
> 
> While I mostly agree with this paragraph, isn't the birth of OOP more
> attributable to smalltalk?  Early smalltalk systems had some features
> of lisp (such as garbage collection), but the OOP system was quite a
> different paradigm from lisp.  Lisps only later caught on with OOP.

To a certain extent, you could argue that Lisp 1.5 already had 
object-oriented features, by providing identity and property lists. 
(It's a stretch, I know. ;)

The contribution of Smalltalk was indeed to identify the paradigm, give 
it a name, and distill it to a minimal set features. This is not unlike 
Scheme that successfully distilled the notion of lexical scoping to a 
minimal set of features.

> IMHO support for OOP is one of the weak spots in scheme and lisp.

This is a non-sequitur. There is CLOS integrated into Common Lisp, and 
there is Tiny CLOS and its derivatives, plus a bunch of other object 
systems for Scheme. Indeed, it's relatively straightforward to implement 
a simple object-oriented extension in a few lines of Scheme or Lisp code.

Alan Kay has acknowledged that the CLOS Metaobject Protocol is an 
important contribution, and I think that Lisp and Scheme are still ahead 
of other languages in that regard, including Smalltalk. (However, Brian 
Foote has implemented a CLOS-style metaobject protocol for Smalltalk 
that he talked about at this year's ECOOP.)


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

"Kris Cipa" <kristinacipa@yahoo.co.nz> writes:

> What's so great about lisp?

Many people have already given you answers to this question and
to the succeeding paragraph.  However, they are given from the
point of view of people who have bought into Lisp, and who already
know the answer.  Now, I don't know about the Scheme community,
but it's probably safe to say that in the Common Lisp community
most of the adherents come to Common Lisp not as a first language.
So they have at one point in time asked precisely the same question
you are asking here.  For an interesting set of insights into what
these people were thinking when they came to learn Lisp, take a
browse through:

http://wiki.alu.org/The_Road_To_Lisp_Survey

-- 
Duane Rettig    duane@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   

My first production language was LISP on a Symbolics Lisp machine back
in 1985.  Since then I've moved to a bunch of other languages.  I've
learned C, C++, Java, VB, Perl, Ruby, and on and on over the past 20
years.  And I can tell you that the most fun I've had is when I can
squeeze in some Lisp programming over the last two decades.

I've not done exhaustive comparisons to say why its better.   But I
know that I code faster, I debug faster, I think faster in Lisp.  And I
can't really say that my experience is that deep with Lisp.  But it
sure is a heck of a lot of fun.

Drew

> I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?

As Tonto said, "what do you mean 'we'"?  Some folks are making
progress.  Yes, they could have just made the leap in, say, 1980, but
they are moving.  In their defense, technology changes have made the
"lisp overhead" less of an issue.  (It wasn't as much an issue as they
claimed even then, but ....)

In article <1127472026.869368.13690@z14g2000cwz.googlegroups.com>,
 "Kris Cipa" <kristinacipa@yahoo.co.nz> wrote:

> What's so great about lisp?

Macros.

Actually, that's not the real answer.  What's great about Lisp is that 
its surface syntax is the same for its code and one of its data 
structures.  That enables the easy implementation of myriad cool 
features that are difficult or impossible [1] in other languages.  This 
includes macros, but also things that most people using other languages 
wouldn't even begin to dream of, e.g. 
http://www.cs.utexas.edu/users/moore/acl2/

Common Lisp also has a pretty cool object model based on generic 
functions rather than message passing that no other language has.

(The list of features unique to Lisp used to be much longer, but other 
languages have slowly been catching up.)

Finally, Lisp is great because at its core it is a very simple language.  
Lisp is in fact simultaneously the simplest and the most powerful [2] 
programming language ever invented (some would say "discovered").  Once 
you come to realize this all other languages start to feel like a waste 
of time.

rg

[1] "Impossible" in the sense of being unable to create a reasonable 
user interface within the language, not in the sense of being 
uncomputable.

[2] "Most powerful" in the sense that there are features that Lisp has 
that no other language has, and at the same time there are no features 
that any other language has that Lisp does not have (or could not be 
easily implemented within the language).

Following up to comp.lang.lisp only.

"Kris Cipa" <kristinacipa@yahoo.co.nz> writes:

> What's so great about lisp?

You tell me:

  Practical Common Lisp
  http://www.gigamonkeys.com/book/


Paolo
-- 
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- CFFI: Foreign Function Interface

Kris Cipa wrote:
> What's so great about lisp?
> I had to use lisp in college for a course, and it looked like a
> horribly primitive and useless contraption. We even had to use emacs to
> use it, in the 21 century!. I have avoided it ever since. However I
> find more and more people rhapsodizing about how cool Lisp is and what
> an advanced language it supposedly is. I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?
> I'd like to know, what's the secret?
> Regards
> --
> Kris.
> 

What's so great about jazz?
I had to listen to jazz in college for a course, and it sounded like a
horribly primitive and toneless composition. We even had to use records 
to hear it, in the 21 century!. I have avoided it ever since. However I
find more and more people rhapsodizing about how cool Jazz is and what
an advanced genre it supposedly is. I just don't get it: I mean do
those people claim that we have made no progress in all the years since
the early days of recording when jazz was used?
I'd like to know, what's the secret?


"Man, If you have to ask what jazz is you'll never know"
-- Louis Armstrong


-- 
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
	-- Karl A. Krueger on comp.lang.lisp

drewc <drewc@rift.com> writes:
>What's so great about jazz?
>I had to listen to jazz in college for a course, and it sounded like a
>horribly primitive and toneless composition. We even had to use records 
>to hear it, in the 21 century!

  I do not use to listen to jazz, but yesterday I enjoyed
  listening to jazz music I heard on the streets, which was
  played by musicians live (within a pub) and with no electrical
  amplification.

  Even from the very distance one could here immediatly that
  this was not recorded music. So you should go to places where
  jazz music is played live -- not listen to records.

  When I heard that music I thought, "What a lie, to suggest
  that music can be recorded on technical media!"

>I have avoided it ever since. However I find more and more
>people rhapsodizing about how cool Jazz is and what an advanced
>genre it supposedly is. I just don't get it: I mean do those
>people claim that we have made no progress in all the years
>since the early days of recording when jazz was used?  I'd like
>to know, what's the secret?

  The type of music people are praising and prefer is usually
  not determined by intrinsic qualities of the music but by
  certain social conventions. As a member of a certain
  subculture one usually does have to adhere to a certain
  musical culture. This correlation was observed by
  sociologists.
 

drewc <drewc@rift.com> writes:

> Kris Cipa wrote:
> > What's so great about lisp?
> > I had to use lisp in college for a course, and it looked like a
> > horribly primitive and useless contraption. We even had to use emacs to
> > use it, in the 21 century!. I have avoided it ever since. However I
> > find more and more people rhapsodizing about how cool Lisp is and what
> > an advanced language it supposedly is. I just don't get it: I mean do
> > those people claim that we have made no progress in all the years since
> > the early days of computing when lisp was used?
> > I'd like to know, what's the secret?
> > Regards
> > --
> > Kris.
> >
> 
> What's so great about jazz?  I had to listen to jazz in college for
> a course, and it sounded like a horribly primitive and toneless
> composition. We even had to use records to hear it, in the 21
> century!. I have avoided it ever since. However I find more and more
> people rhapsodizing about how cool Jazz is and what an advanced
> genre it supposedly is. I just don't get it: I mean do those people
> claim that we have made no progress in all the years since the early
> days of recording when jazz was used?  I'd like to know, what's the
> secret?
>
> "Man, If you have to ask what jazz is you'll never know"
> -- Louis Armstrong

Excellent answer! :-)

  Matthias

Stefan Ram wrote:
> drewc <drewc@rift.com> writes (with-tongue-planted-firmly-in-cheek):
> 
>>What's so great about jazz?
>>I had to listen to jazz in college for a course, and it sounded like a
>>horribly primitive and toneless composition. We even had to use records 
>>to hear it, in the 21 century!
> 
> 
>   I do not use to listen to jazz, but yesterday I enjoyed
>   listening to jazz music I heard on the streets, which was
>   played by musicians live (within a pub) and with no electrical
>   amplification.
> 
>   Even from the very distance one could here immediatly that
>   this was not recorded music. So you should go to places where
>   jazz music is played live -- not listen to records.
> 
>   When I heard that music I thought, "What a lie, to suggest
>   that music can be recorded on technical media!"

Did I forget a smiley somewhere? While i agree that Jazz is best 
experienced live, i wanted to show the correlation between Jazz and the 
early recording industry, and relate that to LISP and the early 
computing industry.

Also, vinyl albums (records) and emacs are both very old technology for 
which a suitable replacement has yet to be found. Music sounds better on 
Wax, text edits better in Emacs.

>>I have avoided it ever since. However I find more and more
>>people rhapsodizing about how cool Jazz is and what an advanced
>>genre it supposedly is. I just don't get it: I mean do those
>>people claim that we have made no progress in all the years
>>since the early days of recording when jazz was used?  I'd like
>>to know, what's the secret?
> 
> 
>   The type of music people are praising and prefer is usually
>   not determined by intrinsic qualities of the music but by
>   certain social conventions. As a member of a certain
>   subculture one usually does have to adhere to a certain
>   musical culture. This correlation was observed by
>   sociologists.


    The programming language people are praising and prefer is usually
    not determined by intrinsic qualities of the language but by
    certain social conventions. As a member of a certain
    subculture one usually does have to adhere to a certain
    linguistic culture. This correlation was observed by
    sociologists.


-- 
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
	-- Karl A. Krueger on comp.lang.lisp

"Kris Cipa" <kristinacipa@yahoo.co.nz> wrote in message 
news:1127472026.869368.13690@z14g2000cwz.googlegroups.com...
> What's so great about lisp?
> I had to use lisp in college for a course, and it looked like a
> horribly primitive and useless contraption. We even had to use emacs to
> use it, in the 21 century!. I have avoided it ever since. However I
> find more and more people rhapsodizing about how cool Lisp is and what
> an advanced language it supposedly is. I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?
> I'd like to know, what's the secret?

For me, freedom.

Most languages force you to tackle a problem on the language's terms.
Java implies objects, for example. The more you use the language, the
more you tackle problems from it's perspective, but every once and a
while don't you catch yourself thinking, "If I was programming in
language X, I'd just write like this and be done, instead of having to
come up with a way to crowbar it into language Y."

Lisp's big strength is it's ability to adapt to the solution. If you've
come up with an elegant algorithm, you don't have to hammer it to fit
the language. Lisp handles most paradigms already, but if it still doesn't
fit, then you hammer the language to fit the solution.

--
Geoff

"Kris Cipa" <kristinacipa@yahoo.co.nz> writes:

> What's so great about lisp?

It's a meta-programming language.

> I had to use lisp in college for a course, and it looked like a
> horribly primitive and useless contraption. We even had to use emacs to
> use it, in the 21 century!. I have avoided it ever since. However I
> find more and more people rhapsodizing about how cool Lisp is and what
> an advanced language it supposedly is. I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?

Yes, indeed, we've made no progress.

> I'd like to know, what's the secret?

The secret as Paul Grahams puts it, is that lisp is not a programming
language, it's a mathematical theorem.  Pythagore's  theorem is still
valid 2600 years later and still will be valid for ever.

http://paulgraham.com/icad.html

-- 
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"

"Ben" <benbelly@gmail.com> writes:
>   I have a lot of ideas about what will help, but I'm sure this the
> wrong place for THAT rant.  :)

There are a couple of newsgroups that could be right on topic for this
rant, but AFAIK they're less read than c.l.l, so I'd be glad if you shared.  

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

The world will now reboot.  don't bother saving your artefacts.

In <rNOSPAMon-20618F.09074023092005@news.gha.chartermi.net> Ron Garret <rNOSPAMon@flownet.com> writes:
>[2] "Most powerful" in the sense that there are features that Lisp has 
>that no other language has, and at the same time there are no features 
>that any other language has that Lisp does not have (or could not be 
>easily implemented within the language).

Well, depends on what you mean by "easily implemented", but things that
could be easier to implement IMO include lazy evaluation, backtracking
execution (although Scheme's call/cc makes it pretty easy), and
reversible execution (would require support in primitives).

Lazy evaluation and backtracking can be universally achieved by
implementing one's own version of |eval| or code-walking macros, but I
don't consider things like that very easy.  Of course, a greatly
simplified version is probably OK, but taking into account the
evaluation of all user-defined data types and control structures can be
messy...

And reversible execution, such as "'(a b c) == (append ?x '(c)), deduce
?x" requires support on primitive level.  So if you're going to
implement that, you'll need to redefine all primitives.

I do agree that these are even harder to implement in many other
languages.

Panu

-- 
personal contact: atehwa@iki.fi, +35841 5323835, +3589 85619369
work contact: panu.kalliokoski@helsinki.fi, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/

drewc <drewc@rift.com> writes:
>Did I forget a smiley somewhere? While i agree that Jazz is best 
>experienced live, i wanted to show the correlation between Jazz and the 
>early recording industry, and relate that to LISP and the early 
>computing industry.

  I have not read what you had quoted, but just what you wrote.
  So I was not aware of the paraphrase. A smiley would not have
  helped me to observe that. I only became aware of it, when 
  I read the reply of Matthias.

>The programming language people are praising and prefer is
>usually not determined by intrinsic qualities of the language
>but by certain social conventions.

      "Moving to new programming languages such as Java and C#
      and pushing aside older languages is not just a technical
      issue. One theory on the success of a programming
      language is that the acceptance of a new language is also
      a social and evolutionary process (Gabriel 1996). Many
      students who attend universities to learn the newest
      programming language are experienced programmers already
      working in the field. Universities face a new challenge
      of teaching Java or C# to programmers whose popular image
      of what a language should be is quite different from the
      language they already have a close bond with. Yet their
      employer, or the lack of current job skills, forces them
      to break ties and learn the latest fad."

http://isedj.org/isecon/2001/16c/ISECON.2001.Emigh.txt

      "The success or failure of a programming language is often
      not related to its technical merits."

  (I forgot who said that, it was used once in the Usenet in
  1998, but I already have heard, that it was said before that
  between 1960 and 1980. I have the name of the author in my
  notes on paper, but it is difficult to access that notebook
  now.)

drewc <drewc@rift.com> writes:

> Kris Cipa wrote:
> > What's so great about lisp?
> > I had to use lisp in college for a course, and it looked like a
> > horribly primitive and useless contraption. We even had to use emacs to
> > use it, in the 21 century!. I have avoided it ever since. However I
> > find more and more people rhapsodizing about how cool Lisp is and what
> > an advanced language it supposedly is. I just don't get it: I mean do
> > those people claim that we have made no progress in all the years since
> > the early days of computing when lisp was used?
> > I'd like to know, what's the secret?
> > Regards
> > --
> > Kris.
> 
> What's so great about jazz?
> I had to listen to jazz in college for a course, and it sounded like a
> horribly primitive and toneless composition. We even had to use records 
> to hear it, in the 21 century!. I have avoided it ever since. However I
> find more and more people rhapsodizing about how cool Jazz is and what
> an advanced genre it supposedly is. I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of recording when jazz was used?
> I'd like to know, what's the secret?

Damn, Drew wins!

> "Man, If you have to ask what jazz is you'll never know"
> -- Louis Armstrong

And I never thought I'd see this quote used in relation to a
programming language.  Much less used well.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | Free Mumia Abu-Jamal! |
     ,--'    _,'   | Abolish the racist    |
    /       /      | death penalty!        |
   (   -.  |       `-----------------------'
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>"The success or failure of a programming language is often not
>related to its technical merits."
>(I forgot who said that, it was used once in the Usenet in
>1998, but I already have heard, that it was said before that
>between 1960 and 1980. I have the name of the author in my
>notes on paper, but it is difficult to access that notebook
>now.)

  Now, I have found it!

  In 1992, using a pencil and paper while in a library, I copied
  this quote from a journal:

      "Unfortunately, the success or failure of a computer
      language is often dependent on factors unrelated to its
      technical merits (...)"
   
    S. H. Valentin in "The Computer Journal", Vol. 17, No. 4, p. 331

  I just found this BibTeX entry of the article:

@article{DBLP:journals/cj/Valentine74,
  author    = {Samuel H. Valentine},
  title     = {Comparative Notes on ALGOL 68 and PL/I.},
  journal   = {Comput. J.},
  volume    = {17},
  number    = {4},
  year      = {1974},
  pages     = {325-331},
  bibsource = {DBLP, http://dblp.uni-trier.de}
}

http://dblp.uni-trier.de/rec/bibtex/journals/cj/Valentine74

"Kris Cipa" <kristinacipa@yahoo.co.nz> writes:

> What's so great about lisp?
> I had to use lisp in college for a course, and it looked like a
> horribly primitive and useless contraption. We even had to use emacs to
> use it, in the 21 century!. I have avoided it ever since. However I
> find more and more people rhapsodizing about how cool Lisp is and what
> an advanced language it supposedly is. I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?
> I'd like to know, what's the secret?
> Regards
> --
> Kris

You will never get what is so great about lisp until you have
programmed in and wrestled with other languages for awhile.  Go off
and use VB/C/C++ and what not. If you are fed up with programming in
10 years then come and look at Common Lisp again.

We can spew off a list of features all day but in my experience the
response to that is generally along the lines of 'why would I need to
do that?' or 'I can do something similar by doing [some pain in the ass
pseudo substitute]'.  eg I don't a macro when I can just cut and 
paste code.  

Kris Cipa wrote:
> What's so great about lisp?
> I had to use lisp in college for a course, and it looked like a
> horribly primitive and useless contraption. We even had to use emacs to
> use it, in the 21 century!. I have avoided it ever since. However I
> find more and more people rhapsodizing about how cool Lisp is and what
> an advanced language it supposedly is. I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?
> I'd like to know, what's the secret?

As far as I can tell, people used to teach Lisp badly. You know, boring
lists and functions. Not much focus on macros, LOOP and arrays o' doom.

Or maybe it was more word-of-mouth or something, and it was best to
actually work with Lispers.

But now we have things like http://www.gigamonkeys.com/book/ and wikis.

Tayssir

Ron Garret wrote:

> In article <1127472026.869368.13690@z14g2000cwz.googlegroups.com>,
>  "Kris Cipa" <kristinacipa@yahoo.co.nz> wrote:
> 
>> What's so great about lisp?
> 
> Macros.

ack. Currently I'm writing a Plugin on MacOS and sometimes I'm feeling like
a macro preprocessor. See for example this nice definition:

http://lxr.mozilla.org/seamonkey/source/modules/plugin/base/public/npupp.h

There are 24 lines of code to define one function for the Plugin interface.
Ok, this is the header, only, and I don't have to write it myself, but to
use it, I have to write the functions and in another place I have to fill a
struct with these function pointers with some helper function, one line for
each function. In Lisp you would just define a special define-netscape-func
as a macro and the rest, including the 24 lines per function, will be
generated automaticly.

So why I don't use Lisp for implementing it, if it is so great? If you give
me a FFI, which works with all the tricks for UPP functions, dynamic Plugin
loading on different architectures and the like, I'll do it, but I fear
that I have to write much of the low-level stuff by myself, so I'm faster
being a preprocessor.

-- 
Frank Bu�, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

I'd like to throw my two cents into this. The best way to learn the
'secret' of Lisp is to program something non-trivial in it. You won't
be able to appreciate it until you do.

Frank Buss <fb@frank-buss.de> writes:
>Ok, this is the header, only, and I don't have to write it myself, but to
>use it, I have to write the functions and in another place I have to fill a
>struct with these function pointers with some helper function, one line for
>each function.

  You could possibly use Lisp to generate that code for you.

In comp.lang.lisp Ron Garret <rNOSPAMon@flownet.com> wrote:

>[2] "Most powerful" in the sense that there are features that Lisp has 
>that no other language has, and at the same time there are no features 
>that any other language has that Lisp does not have (or could not be 
>easily implemented within the language).

How do you ("easily") implement a polymorphic type system for Common
Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
well-known Lisp, such as Scheme) so that you can make any Common
Lisp (or Scheme, ...) program be statically type checked?

There are indeed many things that can be (more or less straightforward)
implemented in, or emulated with (Common) Lisp but your claim that
there are _no_ features of any other language that cannot be "easily"
(I'd say, "naturally") expressed in Lisp is a bit strong.

mkb.

Pascal Bourguignon wrote:
> "Ben" <benbelly@gmail.com> writes:
> 
>>  I have a lot of ideas about what will help, but I'm sure this the
>>wrong place for THAT rant.  :)
> 
> 
> There are a couple of newsgroups that could be right on topic for this
> rant, but AFAIK they're less read than c.l.l, so I'd be glad if you shared.  
> 

Agreed, but if you do go ahead with it, please use a different subject
line;  I don't want to have something potentially cool mixed into yet
another "why use lisp" iteration.

				Bear

I don't know if I'm typical but my first experience of lisp was in an
introductory AI programming course, where lisp was the topic for a
couple of weeks. In that short time all we learned was about lambda
expressions and their relation to lisp. After that we did some things
with lists and that was it. The rest of undergraduate level AI was done
in Prolog.

>From that kind of introduction by someone who doesn't really know lisp,
you're not going to develop much enthusiasm, and I didn't.

Luckily as has been said, the internet and recent books now provide a
pleasant and rapid entry into the world of lisp for those willing to
invest the time.

Part of the problem seems to be the introduction of lisp as a language
purely for AI research, when in fact I learned that it is very much a
general purpose language. Secondly any introduction that focuses on
lisp as a list processor that doesn't seem to have other data
structures like arrays, strings etc, when in fact it does have all
those things, leaves the student with a poor impression.

drewc wrote:
> Stefan Ram wrote:
> 

>>   Even from the very distance one could here immediatly that
>>   this was not recorded music. So you should go to places where
>>   jazz music is played live -- not listen to records.
>>
>>   When I heard that music I thought, "What a lie, to suggest
>>   that music can be recorded on technical media!"

Ah yes; "is it live or is it <elided>?" was a cruel joke.
You might not be able to tell with an amplified performance,
but on live performance with unamplified voice or acoustical
instruments there was never really any comparison.

Honestly, I think it's more about storage and reproduction issues
than a recording issue.  CD's use something like ten megabytes a
minute to store a raw sound format; that's really only about a
twentieth of what you need, I think.

Unfortunately, it's "enough" to drive conventional mikes and
speakers to the limits of their respective performance envelopes.
To really take advantage of higher resolution recordings, you
have to go to technologically advanced substitutes such as
helium-ion speakers.

But that's not the way music seems to be going.  Instead, we're
getting MP3's, which have smaller bandwidth but utterly mangle
any subtle sounds.

				Bear

Matthias Buelow <mkb@incubus.de> writes:

> In comp.lang.lisp Ron Garret <rNOSPAMon@flownet.com> wrote:
> 
> >[2] "Most powerful" in the sense that there are features that Lisp has 
> >that no other language has, and at the same time there are no features 
> >that any other language has that Lisp does not have (or could not be 
> >easily implemented within the language).
> 
> How do you ("easily") implement a polymorphic type system for Common
> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
> well-known Lisp, such as Scheme) so that you can make any Common
> Lisp (or Scheme, ...) program be statically type checked?

You can't make it so, for "any" program -- your are proposing a
tautology, because you can't statically type check all classes of
computer programs.  But it would be easy to implement, in Lisp, 
a suitable language for embedding with Common Lisp.

In article <3pjj9bFankq2U1@news.dfncis.de>,
 Matthias Buelow <mkb@incubus.de> wrote:

> In comp.lang.lisp Ron Garret <rNOSPAMon@flownet.com> wrote:
> 
> >[2] "Most powerful" in the sense that there are features that Lisp has 
> >that no other language has, and at the same time there are no features 
> >that any other language has that Lisp does not have (or could not be 
> >easily implemented within the language).
> 
> How do you ("easily") implement a polymorphic type system for Common
> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
> well-known Lisp, such as Scheme) so that you can make any Common
> Lisp (or Scheme, ...) program be statically type checked?

By shadowing defun.

> There are indeed many things that can be (more or less straightforward)
> implemented in, or emulated with (Common) Lisp but your claim that
> there are _no_ features of any other language that cannot be "easily"
> (I'd say, "naturally") expressed in Lisp is a bit strong.

Well, it all hinges, of course, on the meaning of the word "easily".  
But ACL2 provides static type checking (and much, much more) embedded 
within CL, so we need not speculate in this case.  The incremental cost 
of adding such a system to CL is now zero.

rg

On Fri, 23 Sep 2005 03:40:26 -0700, Kris Cipa wrote:

> What's so great about lisp?
> I had to use lisp in college for a course, and it looked like a
> horribly primitive and useless contraption. We even had to use emacs to
> use it, in the 21 century!. I have avoided it ever since. However I
> find more and more people rhapsodizing about how cool Lisp is and what
> an advanced language it supposedly is. I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?
> I'd like to know, what's the secret?
> Regards

I really dunno. Do you?

-- 
mvh,
Lars Rune Nøstdal
http://lars.nostdal.org/

Pascal Bourguignon wrote:
> "Ben" <benbelly@gmail.com> writes:
> > wrong place for THAT rant.  :)
>
> There are a couple of newsgroups that could be right on
> topic for this
> rant, but AFAIK they're less read than c.l.l, so I'd be
> glad if you shared.

  Well, I never pass up an invitation to grump and holler.  Regardless
of language, platform or goal, when projects hit three or four million
lines of code, cancellation rates skyrocket.  When we read "Mythical
Man Month", "Peopleware", "Agile Software Development", or just about
any book about software processes and management, we find a common
theme:  Software development is hard.  It requires adaptive processes,
_skilled_engineers_, and a LOT of communication to make sure that
knowledge and experience are passed between workers.

  There is no surprise in that.  If you ever read the Wall Street
Journal, you'll find that one of their favorite topics is the need to
pay top dollar for skilled, experienced executives to direct a company.
 Software engineering is no different - experience and skill counts and
can mean the difference between success and failure.  It is important
to hire developers who understand how to get work done, and get work
done correctly.

  The corporations with the dollars to invest in large software
programs have categorically rejected this idea.  I don't think that
anyone doubts the truth, but companies are not interested in that
answer.  They would rather fail than do what is necessary for success -
pay for talented developers.  Every company I have worked for, or have
seen friends work for, has adopted a "new college hire only" policy for
years at a time.  They clamp down on raises, people quit, and all the
active projects are crippled.  Schedules slip for YEARS.  After a
while, the restriction is reduced, and a few experienced people come
in.  Some of the college hires have figured stuff out by then, and
progress resumes.  A project or two is successful, then the whole thing
starts again.

  The difference between successful large projects and failures is the
people.  Experts in the field have been saying that for 25-30 years.
Instead of listening, the industry has banged its head on the wall of
failure.  Sure, a dent has been made.  I think the success rate has
risen from 5% to about 15%.  Yay!  50 more years, and we'll be half-way
there!

  You may now return to Lisp.  :)

Ron Garret <rNOSPAMon@flownet.com> writes:

> In article <3pjj9bFankq2U1@news.dfncis.de>,
>  Matthias Buelow <mkb@incubus.de> wrote:
>
>> In comp.lang.lisp Ron Garret <rNOSPAMon@flownet.com> wrote:
>> 
>> >[2] "Most powerful" in the sense that there are features that Lisp has 
>> >that no other language has, and at the same time there are no features 
>> >that any other language has that Lisp does not have (or could not be 
>> >easily implemented within the language).
>> 
>> How do you ("easily") implement a polymorphic type system for Common
>> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
>> well-known Lisp, such as Scheme) so that you can make any Common
>> Lisp (or Scheme, ...) program be statically type checked?
>
> By shadowing defun.

It is not that easy.  Hindley-Milner (as well as many other things)
depend on certain properties of the language -- in particular that
there are some things that one canNOT do.

There is no language where "everything is expressible" because
sometimes one would like to express that some other thing is not
expressible.  (That's similar to the old question whether God -- who
"can do anything" -- could create a stone so heavy that He cannot lift
it...)

(another) Matthias

Ron Garret wrote:
> In article <3pjj9bFankq2U1@news.dfncis.de>,
>  Matthias Buelow <mkb@incubus.de> wrote:
>>
>>How do you ("easily") implement a polymorphic type system for Common
>>Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
>>well-known Lisp, such as Scheme) so that you can make any Common
>>Lisp (or Scheme, ...) program be statically type checked?
> 
> 
> By shadowing defun.

Not quite.  The class of programs that can be statically
type checked (via Hindley-Milner or any other technique)
is a strict subset of the class of programs that can be
expressed in Lisp and Scheme.

By shadowing Defun, you can statically typecheck programs
which are statically type-checkable and/or expressible in
languages with static type systems; but there is no way
at all to statically typecheck "any" Common Lisp or Scheme
program, because CL and Scheme can be used to express
programs that do not have static type semantics.

			Bear

Christopher C. Stacy wrote:
> You can't make it so, for "any" program -- your are proposing a
> tautology, because you can't statically type check all classes of
> computer programs.  But it would be easy to implement, in Lisp, 
> a suitable language for embedding with Common Lisp.

It depends on what you consider static checking.  In Lisp all functions 
have type Lisp -> Lisp, which is a very wide type ;)

If you want to go Hindley-Milner, for instance, you can't type all Lisp 
programs in that, maybe.

-- 
My mouth says the words, my brain is thinking monstertrucks.
Joey (Friends)

In article <BL2Ze.46$Aw.676@typhoon.sonic.net>,
 Ray Dillinger <bear@sonic.net> wrote:

> Ron Garret wrote:
> > In article <3pjj9bFankq2U1@news.dfncis.de>,
> >  Matthias Buelow <mkb@incubus.de> wrote:
> >>
> >>How do you ("easily") implement a polymorphic type system for Common
> >>Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
> >>well-known Lisp, such as Scheme) so that you can make any Common
> >>Lisp (or Scheme, ...) program be statically type checked?
> > 
> > 
> > By shadowing defun.
> 
> Not quite.  The class of programs that can be statically
> type checked (via Hindley-Milner or any other technique)
> is a strict subset of the class of programs that can be
> expressed in Lisp and Scheme.
>
> By shadowing Defun, you can statically typecheck programs
> which are statically type-checkable and/or expressible in
> languages with static type systems; but there is no way
> at all to statically typecheck "any" Common Lisp or Scheme
> program, because CL and Scheme can be used to express
> programs that do not have static type semantics.

None of those claims are true.  All Lisp and Scheme programs can be 
statically type checked.  Furthermore, all Lisp and Scheme programs have 
static type semantics.

It is true that the result of performing a static type check on certain 
Lisp programs may be that the program is incorrect with respect to 
certain static criteria.  It is also true that the static type semantics 
of certain Lisp and Scheme programs might not be particularly 
interesting or useful.  But all that is beside the point.  It goes 
without saying that even Lisp is subject to the fundamental constraints 
of computation.  That does not change the fact that it is much easier to 
add Hindley-Milner type checking to Lisp than to any other language that 
does not natively possess it.

rg

In article <m2psqzcjt7.fsf@hanabi.local>,
 Matthias Blume <find@my.address.elsewhere> wrote:

> Ron Garret <rNOSPAMon@flownet.com> writes:
> 
> > In article <3pjj9bFankq2U1@news.dfncis.de>,
> >  Matthias Buelow <mkb@incubus.de> wrote:
> >
> >> In comp.lang.lisp Ron Garret <rNOSPAMon@flownet.com> wrote:
> >> 
> >> >[2] "Most powerful" in the sense that there are features that Lisp has 
> >> >that no other language has, and at the same time there are no features 
> >> >that any other language has that Lisp does not have (or could not be 
> >> >easily implemented within the language).
> >> 
> >> How do you ("easily") implement a polymorphic type system for Common
> >> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
> >> well-known Lisp, such as Scheme) so that you can make any Common
> >> Lisp (or Scheme, ...) program be statically type checked?
> >
> > By shadowing defun.
> 
> It is not that easy.  Hindley-Milner (as well as many other things)
> depend on certain properties of the language -- in particular that
> there are some things that one canNOT do.

So?  (See my response to Bear.)

> There is no language where "everything is expressible"

Who ever said that there was?

rg

In <1127526780.902734.198080@g14g2000cwa.googlegroups.com> "Ben" <benbelly@gmail.com> writes:
>  Well, I never pass up an invitation to grump and holler.  Regardless
>of language, platform or goal, when projects hit three or four million
>lines of code, cancellation rates skyrocket.  When we read "Mythical

But you can do a whole lot more in 3M lines of Lisp/Haskell than you can
do in 3M lines of Java/C.

Anyway, I have never been happy with this concept of "project" size.
What constitutes a project?  See my rant on the subject at
http://c2.com/cgi/wiki?FactoringLargePrograms (the name was not picked
by me).  (But please answer in the NG, because Ward's wiki is nowadays
mostly a closed medium.)

Panu

-- 
personal contact: atehwa@iki.fi, +35841 5323835, +3589 85619369
work contact: panu.kalliokoski@helsinki.fi, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/

Stefan Ram wrote:

>   You could possibly use Lisp to generate that code for you.

this is possible and I've already used Lisp for a Java project to generate
the database schema for Postgresql and MySQL from the same Lisp source. But
generating C is not worth the trouble for such a small project, because you
have to write many lines of Lisp code to generate C syntax from an abstract
definition. Then it is better to invest the time in the FFI interface to
allow to write Mac and Linux Plugins and Windows ActiveX Plugins (they are
all a bit different) all from the same Lisp code base, but currently I
don't have the time to do it.

-- 
Frank Bu�, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Panu Kalliokoski wrote:
>
> But you can do a whole lot more in 3M lines of Lisp/Haskell than you can
> do in 3M lines of Java/C.
>
> Anyway, I have never been happy with this concept of
> "project" size.
> What constitutes a project?  See my rant on the subject at
> http://c2.com/cgi/wiki?FactoringLargePrograms
> (the name was not picked
> by me).  (But please answer in the NG, because Ward's
> wiki is nowadays
> mostly a closed medium.)
>

Well, I'm up at 4:00am with the baby, so I'll type a response while I
let the swing try to soothe her back to sleep.  I hope this is somewhat
sensible.  :)

To start with, I have to disagree with the statement that you can do
more w/ 3 million lines of Lisp/Haskell/(Pick you language) than with
Java/C.  In my experience, much of the LoC savings of interpretted
languages comes from the extensive library support, and a briefer
syntax for many things.  Once you have a couple hundred thousand lines
of library / toolkit code integrated, the libraries and the syntax get
closer to the interpretted language.  There is less of an advantage
then.  Compare using standard C++ to using C++ with boost.

As for project size, the large projects I have been involved with are
families of embedded systems with multiple boards, multiple processors
on each board, multiple GUI/s running on their own SPARCs or PCs for
different purposes.  They were constructed modularly - all the
components support several product families.  When a new product is
created, a new set of requirements come in, and all the components have
to be updated and integrated.  So there are a few thousand lines of
code to control thing A, and a couple hundred thousand to control thing
B, and a half-million on the main control board where everything comes
together, and few hundred thousand lines to abstract away system calls.
 (So OS's and electronic hardware can change from product to product
and platform to platform withouth changing application code)  Different
languages are used in different places, and data is moved through XML
or proprietary binary formats when speed or size is an issue.  All this
means that you need 50 - 70 software developers with another 20 people
managing requirements, a whole team managing the nightly builds and
servers and tracking which version of what software components are
working together with which version of what hardware components.  (With
all the HW/OS abstraction layers it is possible to detect HW at
powerup, and configure dyamically, but usually a throughput or powerup
timing requirement forces a couple things to be hardcoded)
Communication is vital, and if you end up working a feature with
someone who doesn't understand how to plug a few systems together
you're both doomed to schedule hell.

  There are certainly improvements that could be made, and for the most
part the individual components don't get into millions of lines.  But
the code is all there in what the customer has shipped to them, and
when the user clicks "go", six million lines of code will execute
several times before the output is achieved.  It all needs to have
people who understand the software and how to integrate it with other
software to add features and fix problems.

  I guess maybe the world of shrinkwrap software doesn't have many
things like this - I've been doing embedded work for a long time (C++
mostly and sometimes Java).  Maybe the skilled people aren't needed so
much for desktop or server apps - someone else would have to speak to
that.  I guess if you don't need the best, could you please hire the
worst so they stop ending up on my teams! :)  When someone makes a
change in the system and it starts taking 90 milliseconds to do
something with a 65 millisecond deadline, you learn appreciate talented
peers who understand a system top to bottom who can help track that
down.

justinhj wrote:
> I don't know if I'm typical but my first experience of lisp was in an
> introductory AI programming course, where lisp was the topic for a
> couple of weeks. In that short time all we learned was about lambda
> expressions and their relation to lisp. After that we did some things
> with lists and that was it. The rest of undergraduate level AI was done
> in Prolog.
>
> >From that kind of introduction by someone who doesn't really know lisp,
> you're not going to develop much enthusiasm, and I didn't.

It is not so much that the course was taught badly - I think it was
fine as far as it goes. It is just that the programming language itself
feels so klunky and basic.
Actually it reminded me of my days coding in BASIC on a Spectrum as a
kid: in both cases you have to go through hoops to make the compiler
happy rather than the compiler making things easy for you. I mean
there's something called parsers, they've been around for years, so why
does the user have to use raw AST to write programs in Lisp? Just like
in old BASICs where you had to number your lines so interpreter can
execute them in the correct order.

Apparently it's so you can obfuscate the code with macros, but come on,
even if you really wanted those (I don't) there must be a better way
than coding in raw syntactic representation!
And of course there's tons of other issue, you can imagine what: the
braindead naming conventions: either cryptic like lambda, car, cdr,
cdaadr, princ and company, or long winded verbosities like
call-with-current-continuation or multiple-value-bind; the almost total
lack of useful libraries or IDEs, the list just goes on.

>From reading the advocay pages I was pointed to etc it seems like
people are into lisp for totally non-technical reasons: they all saw
the light and never went back, they   have secret knowledge that others
lack etc.  It seems more of a cult than a programming language
community.
So I still don't get what the real technical advantages are.
--
Kris

Kris Cipa wrote:

> It is not so much that the course was taught badly - I think it was
> fine as far as it goes. It is just that the programming language itself
> feels so klunky and basic.
 >
> Actually it reminded me of my days coding in BASIC on a Spectrum as a
> kid: in both cases you have to go through hoops to make the compiler
> happy rather than the compiler making things easy for you. I mean
> there's something called parsers, they've been around for years, so why
> does the user have to use raw AST to write programs in Lisp?

That you have to be asking this question demonstrates that you
really, really don't understand why Lisp is that way.

Look, having a more conventional syntax for Lisp has been tried,
repeatedly, for more than four decades.  Each time it's been tried
it's failed to gain any traction.  The reason is that the syntax
becomes natural with just a little experience -- it's just a syntax;
it's not there to 'make the compiler happy' -- and the payback
from macros is tremendous.

	Paul

Matthias Buelow wrote:

> In comp.lang.lisp Ron Garret <rNOSPAMon@flownet.com> wrote:
> 
>>[2] "Most powerful" in the sense that there are features that Lisp has 
>>that no other language has, and at the same time there are no features 
>>that any other language has that Lisp does not have (or could not be 
>>easily implemented within the language).
> 
> How do you ("easily") implement a polymorphic type system for Common
> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
> well-known Lisp, such as Scheme) so that you can make any Common
> Lisp (or Scheme, ...) program be statically type checked?

That wasn't Ron's claim. He said "implemented within the language" not 
"implemented for the language".

It is clear that there are programming language constructs that are 
incompatible with each other, in the sense that you cannot have them in 
the same language. However, it's comparatively simple to embed 
incompatible languages in Common Lisp that you can use each within their 
own "world" but, for example, let programs in those different 
sublanguages still interact with each other.

ACL2 is a good example because it is a subset of Common Lisp restricted 
to purely applicative constructs. Within ACL2, you can only program in 
that subset and are not allowed to use constructs with side effects from 
the host language. Seems to work very well.

> There are indeed many things that can be (more or less straightforward)
> implemented in, or emulated with (Common) Lisp but your claim that
> there are _no_ features of any other language that cannot be "easily"
> (I'd say, "naturally") expressed in Lisp is a bit strong.

The "easily" part probably refers to the fact that it's particularly 
easy to regard programs or program fragments as data. This is an 
important feature to make embeddings of different languages in the same 
environment work. For example, a type checker is "just" a program that 
traverses an s-expression and yields 'acceptable or 'not-acceptable...


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

Kris Cipa wrote:
> It is not so much that the course was taught badly - I think it was
> fine as far as it goes. It is just that the programming language
> itself feels so klunky and basic.

The core language is definitely minimalist. It does have a few
advantages, however. Once you get accustomed to prefix notation, it's
much easier to read and write complex expressions, largely because
everything is regular. You can often write conditions and loops much
more tersely than you could in a procedural language, without obscuring
the meaning. It's the same thing that attracts some people to C and
Perl, only moreso.

The regular syntax also makes it easy to write Lisp parsers. Coming from
other languages, that may not seem like a big deal, but it's a major
advantage for some users. Easy parsing means that you can create domain-
specific languages easily: With a bit of forethought, you can write
programs in a Lisp-like language tailored to your specific needs. In
most languages, that's difficult enough that it's not worth doing.

> Actually it reminded me of my days coding in BASIC on a Spectrum as a
> kid: in both cases you have to go through hoops to make the compiler
> happy rather than the compiler making things easy for you.

That shouldn't happen with Lisp, so long as you're using a decent IDE,
and Lisp has some really excellent IDEs -- including the one built into
Emacs. However, an IDE doesn't help unless you know what it can do for
you and how to use it, and as a novice you probably didn't know how to
use Emacs effectively.

> I mean there's something called parsers, they've been around for
> years, so why does the user have to use raw AST to write programs in
> Lisp?

The original Lisp design called for a more traditional parser, but
nobody ever got around to making it, because the users didn't want it.
Traditional parsers make it easier for novices to write programs, but
s-expressions make it easier for experts to write meta-programs --
something that traditional syntax hinders. I've you have any interest in
C++ meta-programs, you'll know what I mean: It's very, very cool stuff,
but tough to write and nearly impossible to understand. Lisp makes that
stuff (relatively) easy.

> Apparently it's so you can obfuscate the code with macros, but come
> on, even if you really wanted those (I don't) ....

If you've only ever used C-style macros, that's understandable. Lisp
macros are more like C++ template meta-programs, without all the angle
brackets and headaches. The difference between Lisp macros and C++
meta-programs is like writing "Hello world" in Perl instead of Java, for
a crude comparison.

> ... there must be a better way than coding in raw syntactic
> representation!

I don't know of a better way of writing meta-programs.

> And of course there's tons of other issue, you can imagine what: the
> braindead naming conventions: either cryptic like lambda, car, cdr,
> cdaadr, princ and company, or long winded verbosities like
> call-with-current-continuation or multiple-value-bind ....

Eh, Lisp is no better or worse than other languages in this respect.
Compare it to "strxfrm" in C, "bidirectional_iterator" in C++, "$_" in
Perl, or just about anything in COBOL. You just aren't used to it.

> the almost total lack of useful libraries or IDEs ....

Common Lisp has many sophisticated libraries and IDEs, as do some
flavors of Scheme (e.g., PLT Scheme). As I mentioned, Emacs has one of
the best Lisp IDEs; you probably didn't have sufficient training or
experience with it, that's all.

> the list just goes on.

Much of your list is off the mark; while Lisp is different from what
you're used to, the stuff exists.

> From reading the advocay pages I was pointed to etc it seems like
> people are into lisp for totally non-technical reasons: they all saw
> the light and never went back, they have secret knowledge that
> others lack etc.

There's no secret, but some of Lisp's advantages are difficult to
explain to novices, even if they have considerable experience with other
languages. The meta-programming stuff is a good example; except for C++
programmers, not many people know it exists, let alone understand why it
might be useful. Closures are another good example. They package up a
function and a bit of data, which may not seem very important unless you
realize that it's the same basic idea as object-oriented programming
(with a lot less typing). With closures, you don't really need OO
features, because it's almost trivially easy to roll your own objects.

> It seems more of a cult than a programming language community. So I
> still don't get what the real technical advantages are.

People are trying to explain them to you. Try to see past the ugly bits
that scare off novices. I didn't like Lisp either, when I learned it in
college. The parentheses were annoying, the deep expression nesting was
confusing, and overall it seemed like a big hassle compared to C. While
Lisp is still not my /favorite/ language, it's tied for second place.
(Perl is my favorite, and C is my other second-favorite language. I used
to be a C++ nut, but I haven't programmed in it for years, and going
back is a bit daunting.)
-- 
Bradd W. Szonye
http://www.szonye.com/bradd

Ron Garret <rNOSPAMon@flownet.com> writes:

>> There is no language where "everything is expressible"
>
> Who ever said that there was?

You.  You said that there are no features that any other langugage has
that Lisp does not have and which could not easily be implemented
within the language.  That claim is just false.

Proof:  Pick any feature A.  Now consider feature A* defined as:

     A* = "A cannot arise"

Yes, you could (assuming Lisp has feature A) implement /another/
language with feature A* using Lisp, but not /in/ Lisp in the sense
that you "add" the feature to Lisp without at the same time removing
other features (namely A).

Matthias

Pascal Costanza <pc@p-cos.net> writes:

> Matthias Buelow wrote:
>
>> In comp.lang.lisp Ron Garret <rNOSPAMon@flownet.com> wrote:
>> 
>>> [2] "Most powerful" in the sense that there are features that Lisp
>>> has that no other language has, and at the same time there are no
>>> features that any other language has that Lisp does not have (or
>>> could not be easily implemented within the language).
>> How do you ("easily") implement a polymorphic type system for Common
>> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
>> well-known Lisp, such as Scheme) so that you can make any Common
>> Lisp (or Scheme, ...) program be statically type checked?
>
> That wasn't Ron's claim. He said "implemented within the language" not
> "implemented for the language".

You mean I can use Lisp to implement some /other/ language that has
H-M typing?  Well, duh!  I can do that using pretty much /any/ language.

> It is clear that there are programming language constructs that are
> incompatible with each other, in the sense that you cannot have them
> in the same language. However, it's comparatively simple to embed
> incompatible languages in Common Lisp that you can use each within
> their own "world" but, for example, let programs in those different
> sublanguages still interact with each other.

I can agree with this paragraph.  But Ron's claim was worded much more
strongly -- so strongly in fact that it became false.

Matthias

Following up to comp.lang.lisp only.

"Kris Cipa" <kristinacipa@yahoo.co.nz> writes:

> It is not so much that the course was taught badly - I think it was
> fine as far as it goes. It is just that the programming language itself
> feels so klunky and basic.

The COMMON-LISP package of Common Lisp has 978 symbols.  Does it
qualify as "basic"?  What do you mean by "klunky"?  Any examples?


> Apparently it's so you can obfuscate the code with macros, but come on,
> even if you really wanted those (I don't) there must be a better way
> than coding in raw syntactic representation!

Like?


> call-with-current-continuation or multiple-value-bind; the almost total
> lack of useful libraries or IDEs, the list just goes on.

What problems or limitations have you found in existing Lisp IDEs?
Which one(s) have you tried?  Also, which libraries do you
particularly miss?


> From reading the advocay pages I was pointed to etc it seems like
> people are into lisp for totally non-technical reasons: they all saw
> the light and never went back, they   have secret knowledge that others
> lack etc.  It seems more of a cult than a programming language
> community.
> So I still don't get what the real technical advantages are.

If you think that Lisp is a cult rather than a programming language,
technical advantages are irrelevant.  Why do you bother?


Paolo
-- 
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- CFFI: Foreign Function Interface

On 23 Sep 2005 03:40:26 -0700, "Kris Cipa"
<kristinacipa@yahoo.co.nz> wrote:

>What's so great about lisp?
>I had to use lisp in college for a course, and it looked like a
>horribly primitive and useless contraption. We even had to use emacs to
>use it, in the 21 century!. I have avoided it ever since. However I
>find more and more people rhapsodizing about how cool Lisp is and what
>an advanced language it supposedly is. I just don't get it: I mean do
>those people claim that we have made no progress in all the years since
>the early days of computing when lisp was used?
>I'd like to know, what's the secret?
>Regards

You don't know because you don't LOVE Lisp. Lisp is greater than
your girlfriend, your mom, your dad, your country and your dog. This
is The Best Thing Ever Invented, and The Best Language That Makes
Everything 20 Times Faster And Easier Than in Any Other Language.
Lisp doesn't need libraries because real Lisper writes everything
himself

How do I know?.. Well... I read comp.lang.lisp

Kapturek62

"Paul F. Dietz" <dietz@dls.net> writes:
>>here's something called parsers, they've been around for years, so why
>>oes the user have to use raw AST to write programs in Lisp?
>Look, having a more conventional syntax for Lisp has been tried,
>repeatedly, for more than four decades.  Each time it's been tried
>it's failed to gain any traction.  The reason is that the syntax
>becomes natural with just a little experience -- it's just a syntax;
>it's not there to 'make the compiler happy' -- and the payback
>from macros is tremendous.

  I was looking at syntax when contemplating how to teach and
  eventually found that there is a close similarity with natural
  languages.

  A noun phrase, like "the language Lisp" in linguistics is
  considered to have a nucleus, which gives its grammatical
  role. This nucleus here is "language". The nucleus might have
  "satellites" specifying the details, like "Lisp" here.

  Semantically, the nucleus gives the kind ("a language") and
  the satellites select the specific individual ("Lisp").

  This is the same structure as in the function notation, such
  as: "sin(0)", where "sin" gives the kind (a sin-value, i.e.,
  a real number in the range [-1,1]) and "0" specifies the
  individual.

  Now I want to call that "the application of a nucleus to 
  satellites". I can establish that this takes places both in
  natural languages and in formal languages. (Even for whole
  sentences in natural languages the verb can be regarded as
  the nucleus.)

  Then, most languages have developed different notations for
  applications

  "the language Lisp" is an application in English, with the
  nucleus "language" and the satellite "Lisp".

  "the Sine of 0" in an application in English with the nucleus
  "Sine" and the satellite "0". I am not a native speaker, but I
  believe possibly one might also use "of" as in "the language
  of Lisp", showing the analogy.

  "sin(0)" is an application in mathematics with the nucleus
  "sin" and the satellite "0". It is not obvious how this
  specific notation is called. It might be called "prefix-syntax
  with parenthesis" for an application. (I might call it
  "Euler-notation", but I am not sure if Euler really invented
  it.)

  "sin 0" also is an application in mathematics. It might be
  called "prefix-syntax without parenthesis" or "Polish
  notation" of an application.

  "(sin 0)" is the Cambridge-notation.

  "0 sin" is the postfix-notation or reverse Polish notation
  of an application. (One might possibly call "(0 sin)" the
  "reverse Cambridge-notation.)

  "0 + 1" is the infix-notation of an application with the
  nucleus "+" and the satellites "0" and "1".

  A whole english sentence can be translated to prefix-notation,
  for example, "Peter knows the language Lisp." gives
  "assertion( knows( Peter, language( Lisp )))". 

  Programming languages can be separated into languages with a
  single notation for applications and languages with multiple
  notations for applications.

  Lisp is a language with a single notation for applications,
  i.e., the Cambridge notation (ignoring extensions for
  infix-notation within lists, which, of course, are possible).
  But there also are other languages with a single, albeit not
  Cambridge, notation. For example, the RPN-pocket-calculators
  or possibly Forth use a postfix-notation.
  
  Languages with multiple notations for an application often can
  be seens as languages, which also consists of applications
  only, but hide this structure, because the application appears
  "hidden" in several different notations.
  
  A classical non-RPN pocket calculator uses RPN for some
  functions, like [0] [sin], but infix for other functions, like
  [2] [+] [3]. Mathematical notation uses prefix for some
  functions and infix for some other.

  A while-statement in C

while( x < 0 )f( x );

  can be regarded as an application of the nucleaus "while"
  to the satellites "x < 0" and "f( x );". (The semantics are
  that of a function, mapping an expression and a statement
  to another statement.)

  So eventually, every structure in every language is the
  application of a nucleaus to satellites (sometimes, however,
  the details are open to interpretation, for example, which
  constituent in a given text has the role of the nucleus.).

  Using only a single notation for an application has some
  advantages and some disadvantages: An advantage of one
  notation is that it is easier to process text of such a
  language with an algorithm, because only a single case has to
  be considered. An advantage of multiple notations is that it
  sometimes might be easier to read or write for humans, as one
  can see from natural languages and mathematics, where "f(x+1)"
  mixes prefix and infix notation. 

  "2+3+4" also expresses naturally the law of associativity,
  while "+(2,+(3,4))" or "+(+(2,3),4)" would be needed if the
  number of satellites for "+" would be fixed to two. Both of
  these introduce an additional determination, than might be
  irrelevant here. Infix notation here helps to write "2+3+4"
  without that needles determination. This might be a case
  illustrating an advantage of multiple notations for special
  applications. However, the notation "+(2,3,4)" can be used
  as soon as one does not fix the number of satellites of "+"
  to two.

  Remarkably, the origin of the function notation "f(x)" is
  not known to me. The page

http://members.aol.com/jeff570/functions.html

  attributes "f(x)" to Euler, but reports that "log a"

http://members.aol.com/jeff570/loga.gif

  might already have been used before Euler. So actually, I do
  not want to know, who used "f(x)" literally the first time,
  but who used the notation of a function name (not neccessarily
  "f") followed by a function argument (not neccessarily "x")
  for the first time. This is still a mystery to me. I would be
  grateful for any hints.

  I use "nucleus" and not "function" above, because "necleus" to
  me means the grammatical role in the deep structure while
  "function" means the semantics (a function is part of another
  model).

  There are actually three levels:

    - The surface structure (I call "notation"), which might be
      "sin(0)", "sin 0", "(sin 0)", or "0 sin".

    - The deep structure, which is an application of the nucleus
      "sin" to the satellite "0" in all cases.

    - The semantics, which is the function value of the function
      "sin" at the point "0".

"Bradd W. Szonye" <bradd+news@szonye.com> writes:
>There's no secret, but some of Lisp's advantages are difficult
>to explain to novices, even if they have considerable
>experience with other languages. The meta-programming stuff is
>a good example; except for C++ programmers, not many people
>know it exists, let alone understand why it might be useful.

  After all, it might not be /so/ difficult to explain that to
  users of /any/ other language, because sooner or later they
  all will spot redundant structures in their source code, which
  they can not easily abstract using the features of their
  language (without macro-like features). For example, in Java:

if( object instanceof de.dclj.ram.Example )
{ de.dclj.ram.Example example =( de.dclj.ram.Example )object; 
  /* ... */ }

  Sooner or later every Java-programmer should asked himself,
  why he has to type such a scheme (only with other variable and
  class names) over and over again and how it could be
  abstracted.

On 24 Sep 2005 05:59:55 GMT, Panu Kalliokoski <atehwa@sange.fi>
wrote:

>In <1127526780.902734.198080@g14g2000cwa.googlegroups.com> "Ben" <benbelly@gmail.com> writes:
>>  Well, I never pass up an invitation to grump and holler.  Regardless
>>of language, platform or goal, when projects hit three or four million
>>lines of code, cancellation rates skyrocket.  When we read "Mythical
>
>But you can do a whole lot more in 3M lines of Lisp/Haskell than you can
>do in 3M lines of Java/C.
>

Have you ever seen 3M lines of Haskell?... 3M lines means about 50
people team, and majority must know programming language very well.
Have you seen 25 Haskell programmers in one place?...

Kapturek62

On Sat, 24 Sep 2005 15:33:50 +0200, Paolo Amoroso
<amoroso@mclink.it> wrote:
 
>
>What problems or limitations have you found in existing Lisp IDEs?
>Which one(s) have you tried?  Also, which libraries do you
>particularly miss?

BLAS. Cephes. PVM. MPS. 

A.L.

Kris Cipa wrote:
> From reading the advocay pages I was pointed to etc it seems like
> people are into lisp for totally non-technical reasons: they all saw
> the light and never went back, they   have secret knowledge that others
> lack etc.  It seems more of a cult than a programming language
> community.

Any cult-like resemblances will likely now diminish, as people at
places like Microsoft publicly adopt Lisp.

People used to be rather spooked at the reality distortion fields which
excluded Lisp. Leading to this cult-like behavior, which nearly any
radical non-mainstream group exhibits. Now it's starting to be part of
the distortion field.


Tayssir

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>"(sin 0)" is the Cambridge-notation.

  When thinking about how to call the whole thing "(sin 0)",
  I thought "It has a nucleus and satellites - so it should
  be called an 'atom'." -- but then, in Lisp, this is exactly
  the opposite of an atom!

Matthias Blume wrote:

> You mean I can use Lisp to implement some /other/ language that has
> H-M typing?  Well, duh!  I can do that using pretty much /any/ language.

Yes, but not as easily. That's the whole point.

>>It is clear that there are programming language constructs that are
>>incompatible with each other, in the sense that you cannot have them
>>in the same language. However, it's comparatively simple to embed
>>incompatible languages in Common Lisp that you can use each within
>>their own "world" but, for example, let programs in those different
>>sublanguages still interact with each other.
> 
> I can agree with this paragraph.  But Ron's claim was worded much more
> strongly -- so strongly in fact that it became false.

I don't think so. Maybe it was a little bit vague, but then your 
interpretation of what he said is not the only possible one.

Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

A.L. <alewando@kapturek62.com> writes:

> On Sat, 24 Sep 2005 15:33:50 +0200, Paolo Amoroso
> <amoroso@mclink.it> wrote:
>  
> >
> >What problems or limitations have you found in existing Lisp IDEs?
> >Which one(s) have you tried?  Also, which libraries do you
> >particularly miss?
> 
> BLAS. Cephes. PVM. MPS. 

For BLAS you have Matlisp: http://matlisp.sourceforge.net/

A.L. wrote:
> Have you ever seen 3M lines of Haskell?... 3M lines means about 50
> people team, and majority must know programming language very well.
> Have you seen 25 Haskell programmers in one place?...

Hm, I don't know the size of GHC, but I'd guess it's quite big.  It uses 
GCC as the backend, AFAIK, but still does *a lot*.  GCC by comparison 
was lots of megabytes when I last looked, just the source.  Zipped.  And 
it doesn't do much AT ALL.  Oh yes, written in C.

Or look at a Lisp compiling itself.  Vastly faster, and with vastly less 
source than GCC takes.

-- 
My mouth says the words, my brain is thinking monstertrucks.
Joey (Friends)

On 24 Sep 2005 02:19:33 -0700, "Ben" <benbelly@gmail.com> wrote:

> To start with, I have to disagree with the statement that you can do
> more w/ 3 million lines of Lisp/Haskell/(Pick you language) than
> with Java/C.  In my experience, much of the LoC savings of
> interpretted languages comes from the extensive library support, and
> a briefer syntax for many things.

Which of "Lisp/Haskell/(Pick you language)" is an interpreted
language?  And do you really think that there's "extensive library
support" for Lisp and Haskell but not for Java or C?  What are you
talking about?

Cheers,
Edi.

-- 

Lisp is not dead, it just smells funny.

Real email: (replace (subseq "spamtrap@agharta.de" 5) "edi")

A.L. <alewando@kapturek62.com> writes:

> On Sat, 24 Sep 2005 15:33:50 +0200, Paolo Amoroso
[...]
>>Which one(s) have you tried?  Also, which libraries do you
>>particularly miss?
>
> BLAS. Cephes. PVM. MPS. 

Some starting points:

  http://www.stat.umn.edu/users/stat-lisp-devel/msg00133.html (Cephes)
  http://lush.sourceforge.net/ (BLAS)
  http://www.uni-koeln.de/~a0047/disco93/node6.html (PVM)

I don't know MPS.  You may also try Verrazano + CFFI.


Paolo
-- 
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- CFFI: Foreign Function Interface

I know I shouldn't feed him, but my guts tell me to go with it.

Kris Cipa wrote:
> It is not so much that the course was taught badly - I think it was
> fine as far as it goes. It is just that the programming language itself
> feels so klunky and basic.

Hm, sounds like that Scheme class I had in my first semester.  There are 
other Lisps out there you know.  Just like C and Java doesn't only mean 
the base language.  There are things called libraries.  In Lisp there 
are also things called macros.

> I mean
> there's something called parsers, they've been around for years, so why
> does the user have to use raw AST to write programs in Lisp? Just like
> in old BASICs where you had to number your lines so interpreter can
> execute them in the correct order.

Hm, why do most oh-so-modern platforms (say, J2EE) require me to create 
tons of files in raw AST, called XML?  Hmmmm...

And do you really think that
foo(bar(a, b, (x+y)*24), c) is that much more readable than
(foo (bar a b (* (+ x y)
		 24))
      c)
even if you remove the indentation.  I don't see THE POINT of using that 
"cool" syntax, just so you can have a custom parser for that.  Seems 
like it wasn't enough, either, since C uses another parser (CPP) to 
preprocess stuff.  Oh, and yacc, lex and other tools also have their own 
parsers and create C code.  For Java things are similar.

And I don't even want to see how a readable Lisp LOOP expression would 
look like in Java...

> Apparently it's so you can obfuscate the code with macros, but come on,
> even if you really wanted those (I don't) there must be a better way
> than coding in raw syntactic representation!

And that is?  Using Java and lots of XML, oops, raw syntax again, only 
with more arbitrary complexity added.

And why use macros when you can use lots of different preprocessors and 
code generators instead, only that they don't recognize each others' 
syntax, so you can't combine them, as you can with macros.

> And of course there's tons of other issue, you can imagine what: the
> braindead naming conventions: either cryptic like lambda, car, cdr,
> cdaadr, princ and company, or long winded verbosities like

Oh my god, it's sooo much easier to just do a
Pair foo = bla();
foo.second.first.first.second

than just doing a (cdaadr (bla)), right?

Not to mention calling
someobj.somefunction(new BlaFunction(){
			public void fun() { do stuff(); } } );

instead of (somefunction someobj (lambda () do stuff)), because syntax 
is cool.  Right.

And everybody knows that System.out.println is Good because God says so, 
but PRINC is from hell, as are PRINT and FORMAT.  Unless you code in C, 
then printf is suddenly cool again.

> call-with-current-continuation or multiple-value-bind; the almost total
> lack of useful libraries or IDEs, the list just goes on.

Right.  I love having to write "return new Tuple3(a, b, c);" in Java, 
and having to extract the values from the tuple, because there are no 
multiple values.  Greatest.  Innovation.  Ever.  And that's ten years 
after Standard ML we're talking here.  They should have known.

Oh, and of course continuations are useless, as everybody knows:
http://jakarta.apache.org/commons/sandbox/javaflow/
http://rifers.org/
http://www.theserverside.com/news/thread.tss?thread_id=36594

It's much more fun to have at least three different implementations of 
it, that probably aren't too compatible.

>>From reading the advocay pages I was pointed to etc it seems like
> people are into lisp for totally non-technical reasons: they all saw
> the light and never went back, they   have secret knowledge that others
> lack etc.  It seems more of a cult than a programming language
> community.

I don't know anybody who likes Java, or C#, that also really knows 
Smalltalk, or Lisp, but almost everybody in the Lisp camp is really 
fluent in C, Java, and probably several other languages.  You figure.

> So I still don't get what the real technical advantages are.

I'm afraid I can't help you then.  If you don't see advantages, just go 
home to the java newsgroup of your choice (or whatever language you 
think is much cooler than Lisp).

-- 
My mouth says the words, my brain is thinking monstertrucks.
Joey (Friends)

["Followup-To:" header set to comp.lang.lisp.]
On 2005-09-24, Kris Cipa <kristinacipa@yahoo.co.nz> wrote:
> Apparently it's so you can obfuscate the code with macros, but come on,
> even if you really wanted those (I don't) there must be a better way
> than coding in raw syntactic representation!

This reminds me of another thing of those good old 8bit basic and asm
days.  Why obfuscate the code with named functions or symbols instead of
direct addresses for memory mapped registers?  It only makes it harder
to see what's going on.  Even assembler macros were bad; the only
sensible thing is to program in a machine language monitor.

-- 
Julian Squires

Kris wrote:
"It is not so much that the course was taught badly - I think it was
fine as far as it goes. It is just that the programming language itself
feels so klunky and basic.
Actually it reminded me of my days coding in BASIC on a Spectrum as a
kid: in both cases you have to go through hoops to make the compiler
happy rather than the compiler making things easy for you. I mean
there's something called parsers, they've been around for years, so why
does the user have to use raw AST to write programs in Lisp? Just like
in old BASICs where you had to number your lines so interpreter can
execute them in the correct order."

If you were taught well I don't think you'd be making the kind of
statements you are. Lisp is far from just an AST. I'd describe it as a
pure uncluttered language rather than a basic one.

"Apparently it's so you can obfuscate the code with macros, but come
on,
even if you really wanted those (I don't) there must be a better way
than coding in raw syntactic representation!
And of course there's tons of other issue, you can imagine what: the
braindead naming conventions: either cryptic like lambda, car, cdr,
cdaadr, princ and company, or long winded verbosities like
call-with-current-continuation or multiple-value-bind; the almost total
lack of useful libraries or IDEs, the list just goes on. "

But macro's are not for obfuscating.. they are for better expressing
what you want your program to do. If you want obfsucation take a look
at any reasonably complex peice of C++ and STL.

cdr and car actually have quite useful properties in that they are
short and they can be combined into caddr, caaddr etc which you cannot
do with the more expressive names 'first' or 'rest'.

The best way to prove yourself right or wrong in this matter is to
write a program that does something interesting in your language of
choice and then in lisp and compare your experiences.

["Followup-To:" header set to comp.lang.lisp.]
On 2005-09-24, Matthias Blume <find@my.address.elsewhere> wrote:
> Yes, you could (assuming Lisp has feature A) implement /another/
> language with feature A* using Lisp, but not /in/ Lisp in the sense
> that you "add" the feature to Lisp without at the same time removing
> other features (namely A).

This reminds me of the old "irresistable force versus immovable object"
thing.  And, of course, you're right.  Except that I think Ron's intent
included sublanguages like ACL2.  I don't think it's fair to say that
implementing something like that in Lisp is just the same as
implementing it in C.  There is an obvious practical difference, and
that is the important point.

Cheers.

-- 
Julian Squires

Paolo Amoroso wrote:
> A.L. <alewando@kapturek62.com> writes:
> 
> 
>>On Sat, 24 Sep 2005 15:33:50 +0200, Paolo Amoroso
> 
> [...]
> 
>>>Which one(s) have you tried?  Also, which libraries do you
>>>particularly miss?
>>
>>BLAS. Cephes. PVM. MPS. 
> 
> 
> Some starting points:
> 
>   http://www.stat.umn.edu/users/stat-lisp-devel/msg00133.html (Cephes)
>   http://lush.sourceforge.net/ (BLAS)
>   http://www.uni-koeln.de/~a0047/disco93/node6.html (PVM)
> 
> I don't know MPS.  You may also try Verrazano + CFFI.

Oh, goody, I need a C++ test for my evaluation of vzn (Verrazano). I 
will try Cephes. Any Cephes users out there? As far as I can make out, 
the main header is qfloat.h? And I see test1, test2, test3... are those 
good regression tests or just detritus?


-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state 
I finally won out over it."
     Elwood P. Dowd, "Harvey", 1950

In comp.lang.lisp Christopher C. Stacy <cstacy@news.dtpq.com> wrote:

>> How do you ("easily") implement a polymorphic type system for Common
>> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
>> well-known Lisp, such as Scheme) so that you can make any Common
>> Lisp (or Scheme, ...) program be statically type checked?
>
>You can't make it so, for "any" program -- your are proposing a
>tautology, because you can't statically type check all classes of
>computer programs.  But it would be easy to implement, in Lisp, 

The poster I responded to made the claim that any language feature
can be "easily" backfitted into Lisp. Upon which I gave the
counter-example of static polymorphic typechecking, which, as I see
it, is not possible (without replacing the compiler, or, for that
matter, "eval"). I'm not saying that one can type-check all possible
computer programs, I'd be satisfied with the subset that typically
can be type-checked in languages that have this feature.

>a suitable language for embedding with Common Lisp.

Please explain. Of course one can write a ML/Haskell/whatever
interpreter in Lisp or Scheme. But that's probably not what you
mean.

mkb.

In article <m2ll1md2yg.fsf@hanabi.local>,
 Matthias Blume <find@my.address.elsewhere> wrote:

> Ron Garret <rNOSPAMon@flownet.com> writes:
> 
> >> There is no language where "everything is expressible"
> >
> > Who ever said that there was?
> 
> You.  You said that there are no features that any other langugage has
> that Lisp does not have and which could not easily be implemented
> within the language.  That claim is just false.
> 
> Proof:  Pick any feature A.  Now consider feature A* defined as:
> 
>      A* = "A cannot arise"
> 
> Yes, you could (assuming Lisp has feature A) implement /another/
> language with feature A* using Lisp, but not /in/ Lisp in the sense
> that you "add" the feature to Lisp without at the same time removing
> other features (namely A).

Well, if you choose to define "in Lisp" so as to prohibit the removal of 
existing features then of course (tautologically in fact) you cannot 
implement A* "in Lisp".

But that's a stupid definition because it *is* possible to remove (or at 
least effectively hide) features in Lisp.  Lisp is specifically designed 
to make it easy to implement "other languages" (as you put it) whose 
semantics are incompatible with (parts of) Lisp.  And indeed there are 
many existence proofs of Lisp being used in precisely this way.  (In 
fact, my original suggestion of implementing HM type checking by 
"shadowing defun" is an example of "removing" a feature to replace it 
with an incompatible feature.)

(I think I'm beginning to understand the motivation behind some of Erik 
Naggum's opinions of the Scheme community.)

rg

In comp.lang.lisp Ray Dillinger <bear@sonic.net> wrote:

>But that's not the way music seems to be going.  Instead, we're
>getting MP3's, which have smaller bandwidth but utterly mangle
>any subtle sounds.

I think with consumer bandwidth offerings getting expanded every
year, and disk space being cheap now anyways, mp3 will be succeeded
by flac (preferrably), or a number of proprietary lossless encodings
in some time. At least when consumers are not completely stupid
(ok, not a good chance here.) I at least won't pay for mp3 or similar
losing encodings; when they want to sell me music over the Internet,
then they better offer it in lossless formats (from which I usually
generate mp3s for my own convenience, like stuffing them into the
iPod or so, but that doesn't matter.)

mkb.

Ray Dillinger wrote:
> drewc wrote:
> 
>> Stefan Ram wrote:
>>
> 
>>>   Even from the very distance one could here immediatly that
>>>   this was not recorded music. So you should go to places where
>>>   jazz music is played live -- not listen to records.
>>>
>>>   When I heard that music I thought, "What a lie, to suggest
>>>   that music can be recorded on technical media!"
> 

> Honestly, I think it's more about storage and reproduction issues
> than a recording issue.  CD's use something like ten megabytes a
> minute to store a raw sound format; that's really only about a

....snip...

Actually, I think the primary failing of recording/playback systems 
today isn't really fidelity.  I doubt that most people could honestly 
(aka in a double blind test) tell the difference between a live point 
audio source and a recorded one.

However, todays recordings often ignore the second aspect that make 
"live" lifelike: the complexity of reflected sound.  The home theatre 
industry is focused in a very marketroid way on selling ever increasing 
numbers of surround speakers, but all on a two dimensional plane. 
Ambisonics solves the playback part elegantly, but that isn't being 
built for end users, and certainly music isn't being recorded that way.

</end ot>

	Scott

Kris Cipa wrote:

> So I still don't get what the real technical advantages are.

It's okay; you don't have to.  :-)

			Bear

In <f9maj11911c4sf43f1gvdn0js5d3530hnj@4ax.com> A.L. <alewando@kapturek62.com> writes:
>>But you can do a whole lot more in 3M lines of Lisp/Haskell than you can
>>do in 3M lines of Java/C.
>Have you ever seen 3M lines of Haskell?... 3M lines means about 50
>people team, and majority must know programming language very well.
>Have you seen 25 Haskell programmers in one place?...

How does one "see" 3M lines of anything?-)  No, I haven't tried; the
claim was an extrapolation of experiences with shorter programs.

Matthias Buelow wrote:

> Of course one can write a ML/Haskell/whatever
> interpreter in Lisp or Scheme.

Or an interpreter of such a language, but with s-expression syntax, to 
avoid parsing. Or a compiler of such a language with s-expression syntax 
to Lisp or Scheme. Or a set of macros that effectively perform the 
translation from that s-expression-based language to Lisp or Scheme.

Use a full-fledged macro system to perform checks during the translation 
process. Use a code walker to determine non-trivial properties of the 
code to be checked. Use packages or a module system to define the subset 
of Lisp or Scheme that the language is compatible with.


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

Panu Kalliokoski <atehwa@sange.fi> writes:
>How does one "see" 3M lines of anything? (...) No, I haven't tried; the
>claim was an extrapolation of experiences with shorter programs.

  One should never see 3M lines of anything.

  When size and complexity are handled in the right way, they
  disappear.

  On every level of abstraction there are only small units
  combining features of other units to a meaningful new feature.

  Eventually, a "huge project", like a Common Lisp interpreter,
  is also just such a small unit with only few lines or even
  just a single line, such as:

(while(print(eval(read)))

  Each word used stands itself for another small unit and so on.

First, I'd like to say that your points are very valid and the theory of
S-expressions was probably motivated by syntax trees of natural
languages.  Lisp is designed to be its own metalanguage: by exposing its
AST in an easy-to-manipulate form, it effectively encourages (a)
building new languages on that same format and (b) reasoning about
programs written in itself.  Prolog is similar in this respect
(homoiconic).

A parenthesised expression in Lisp corresponds to the idea of
"expression" (or "phrase") in linguistics.  A symbol in Lisp corresponds
to the idea of "word" (or "idiom") in linguistics.  The idea of "clause"
does not have a clear counterpart in Lisp, but in Logo it is modelled as
a list.  (An anonymous function serves some of the same purpose as a
subordinate clause.)

Some other points:

In <nuclei-20050924143843@ram.dialup.fu-berlin.de> ram@zedat.fu-berlin.de (Stefan Ram) writes:

>while( x < 0 )f( x );
>  can be regarded as an application of the nucleaus "while"
>  to the satellites "x < 0" and "f( x );". (The semantics are
>  that of a function, mapping an expression and a statement
>  to another statement.)

This is why some Logos have:

while [:x < 0] [f :x]

>  So eventually, every structure in every language is the
>  application of a nucleaus to satellites (sometimes, however,
>  the details are open to interpretation, for example, which
>  constituent in a given text has the role of the nucleus.).

Definitely.  For example, in "red hat" we would be tempted to describe
"hat" as the nucleus; but it's clear that "hat" needs no parameters, for
example, in the clause "eat the hat".  So, in type-based grammars, we
usually make "red" a (unary) function and "hat" a constant (= nullary
function).

When natural languages have multiple ways of using a word, we tag
expressions with explicit "type declarations":

"John sees a red hat"
-> (S (NP (N john)) (VP (V sees) (NP (A red) (NP (N hat)))))
"I like red"
-> (S (NP (PRON I)) (VP (V like) (NP (N red))))

See how the tags differ for "red" in the trees?  In programming
languages, we require every word to behave syntactically similarly in
all contexts.

(Actually, my example parse trees _still_ use NP in a polymorphic way;
it's used for both N expressions and A,NP expressions.  Prolog accounts
for this by internally treating NP/1 and NP/2 as different tags.)

Panu

-- 
personal contact: atehwa@iki.fi, +35841 5323835, +3589 85619369
work contact: panu.kalliokoski@helsinki.fi, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/

In <3M-20050924185232@ram.dialup.fu-berlin.de> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>  One should never see 3M lines of anything.

My point exactly, and explained on the page FactoringLargePrograms...
another older writing of mine on the subject is
http://c2.com/cgi/wiki?WhatIsaProject

>(while(print(eval(read)))

I find it somehow funny that the expression is missing a parenthese. :)

P

-- 
personal contact: atehwa@iki.fi, +35841 5323835, +3589 85619369
work contact: panu.kalliokoski@helsinki.fi, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/

On 24 Sep 2005 16:49:49 GMT, Panu Kalliokoski <atehwa@sange.fi>
wrote:

>In <f9maj11911c4sf43f1gvdn0js5d3530hnj@4ax.com> A.L. <alewando@kapturek62.com> writes:
>>>But you can do a whole lot more in 3M lines of Lisp/Haskell than you can
>>>do in 3M lines of Java/C.
>>Have you ever seen 3M lines of Haskell?... 3M lines means about 50
>>people team, and majority must know programming language very well.
>>Have you seen 25 Haskell programmers in one place?...
>
>How does one "see" 3M lines of anything?-)  No, I haven't tried; the
>claim was an extrapolation of experiences with shorter programs.

Extrapolate linearly?... Sorry, life is more complicated...

A.L.

Stefan Ram wrote:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>"(sin 0)" is the Cambridge-notation.
> 
>   When thinking about how to call the whole thing "(sin 0)",
>   I thought "It has a nucleus and satellites - so it should
>   be called an 'atom'." -- but then, in Lisp, this is exactly
>   the opposite of an atom!

Well, the problem stems from "atom" (meaning indivisible
thing: a-tom) being applied by physicists to something 
that later turned out to be divisible.  D'oh.  

In comp.lang.lisp Stefan Ram <ram@zedat.fu-berlin.de> wrote:

>  When size and complexity are handled in the right way, they
>  disappear.

Unfortunately, they usually aren't handled the right way...

mkb.

In comp.lang.lisp Pascal Costanza <pc@p-cos.net> wrote:

>Or an interpreter of such a language, but with s-expression syntax, to 
>avoid parsing. Or a compiler of such a language with s-expression syntax 
>to Lisp or Scheme. Or a set of macros that effectively perform the 
>translation from that s-expression-based language to Lisp or Scheme.

Yes, well.. but that's beside the point since we were talking about
adding features to Lisp in the sense of those features then being
available for any Lisp program, and not just for embedded sub-languages.
It's like pregnancy; either a woman is pregnant, or she isn't.
There's no "somewhat" (partially) pregnant.

Apart from that, after a number of years of experimenting, I
personally have come to the conclusion that I prefer a portfolio
of distinct languages with (potentially very different) specialized
syntax+semantics, for different application domains, to a
stuff-it-all-into-one language (such as Common Lisp attempts to be,
at least theoretically). It's a different philosophy and one that
is, imho, more successful.

mkb.

In article <m2hdcad2s7.fsf@hanabi.local>,
 Matthias Blume <find@my.address.elsewhere> wrote:

> Pascal Costanza <pc@p-cos.net> writes:
> 
> > Matthias Buelow wrote:
> >
> >> In comp.lang.lisp Ron Garret <rNOSPAMon@flownet.com> wrote:
> >> 
> >>> [2] "Most powerful" in the sense that there are features that Lisp
> >>> has that no other language has, and at the same time there are no
> >>> features that any other language has that Lisp does not have (or
> >>> could not be easily implemented within the language).
> >> How do you ("easily") implement a polymorphic type system for Common
> >> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
> >> well-known Lisp, such as Scheme) so that you can make any Common
> >> Lisp (or Scheme, ...) program be statically type checked?
> >
> > That wasn't Ron's claim. He said "implemented within the language" not
> > "implemented for the language".
> 
> You mean I can use Lisp to implement some /other/ language that has
> H-M typing?  Well, duh!  I can do that using pretty much /any/ language.

Of course you can.  But in any other language it's hard.  In Lisp it's 
(comparatively) easy.  For example, the language for which you implement 
HM typing could be a subset or minor variant of Lisp.  Lisp includes 
features that make it easy to implement such subsets and minor variants, 
and in this regard Lisp is unique.

> > It is clear that there are programming language constructs that are
> > incompatible with each other, in the sense that you cannot have them
> > in the same language. However, it's comparatively simple to embed
> > incompatible languages in Common Lisp that you can use each within
> > their own "world" but, for example, let programs in those different
> > sublanguages still interact with each other.
> 
> I can agree with this paragraph.  But Ron's claim was worded much more
> strongly -- so strongly in fact that it became false.

The truth or falseness of my claim hinges entirely on one's 
interpretation of the word "easily".  Reasonable people may differ on 
this, but since the claim has a subjective element you can't write it 
off as objectively false.

rg

Matthias Buelow wrote:

> In comp.lang.lisp Pascal Costanza <pc@p-cos.net> wrote:
> 
>>Or an interpreter of such a language, but with s-expression syntax, to 
>>avoid parsing. Or a compiler of such a language with s-expression syntax 
>>to Lisp or Scheme. Or a set of macros that effectively perform the 
>>translation from that s-expression-based language to Lisp or Scheme.
> 
> Yes, well.. but that's beside the point since we were talking about
> adding features to Lisp in the sense of those features then being
> available for any Lisp program, and not just for embedded sub-languages.

Some people were talking about that, others were not.

> It's like pregnancy; either a woman is pregnant, or she isn't.
> There's no "somewhat" (partially) pregnant.

Yes, there is. That's why some think that abortion is acceptable. (Not 
that I know how this would be related to the topic at hand... ;)

> Apart from that, after a number of years of experimenting, I
> personally have come to the conclusion that I prefer a portfolio
> of distinct languages with (potentially very different) specialized
> syntax+semantics, for different application domains, to a
> stuff-it-all-into-one language (such as Common Lisp attempts to be,
> at least theoretically). It's a different philosophy and one that
> is, imho, more successful.

a) If that works well for you, go ahead.

b) Even if that works well for you, that doesn't negate the claim about 
the embeddability of language features in Lisp.

c) Just out of interest: Do you never need to interoperate between 
applications developed in different languages? I am asking because I 
think a host language that eases embedding of specialized languages also 
  eases interoperability. (This is not a rhetorical question.)



Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

In article <3plbm1Fb20nbU1@news.dfncis.de>,
 Matthias Buelow <mkb@incubus.de> wrote:

> In comp.lang.lisp Christopher C. Stacy <cstacy@news.dtpq.com> wrote:
> 
> >> How do you ("easily") implement a polymorphic type system for Common
> >> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
> >> well-known Lisp, such as Scheme) so that you can make any Common
> >> Lisp (or Scheme, ...) program be statically type checked?
> >
> >You can't make it so, for "any" program -- your are proposing a
> >tautology, because you can't statically type check all classes of
> >computer programs.  But it would be easy to implement, in Lisp, 
> 
> The poster I responded to made the claim that any language feature
> can be "easily" backfitted into Lisp. Upon which I gave the
> counter-example of static polymorphic typechecking, which, as I see
> it, is not possible (without replacing the compiler, or, for that
> matter, "eval").

You say "without replacing the compiler" as if replacing the compiler 
was difficult.  And in most languages it is, but in Lisp it's not.  In 
fact, it is easy to replace the compiler.  It is even easy to replace 
parts of the compiler while retaining other parts.  That's exactly what 
macros do.

> I'm not saying that one can type-check all possible
> computer programs, I'd be satisfied with the subset that typically
> can be type-checked in languages that have this feature.
> 
> >a suitable language for embedding with Common Lisp.
> 
> Please explain. Of course one can write a ML/Haskell/whatever
> interpreter in Lisp or Scheme. But that's probably not what you
> mean.

It doesn't matter.  There are many options available:

1.  Transparent type checking that operates on Lisp programs to the 
extent possible and throws up its hands on cases that it can't handle.

2.  Type checking on a subset or slightly modified dialect of Lisp that 
is more amenable to being type checked.

3.  A complete embedding of an entirely different language specifically 
designed for type checking (with or without a new surface syntax).

There are probably others.  My claim is: whatever strategy you choose, 
it will be vastly easier to implement that strategy in Lisp than it will 
be to implement that strategy in any other language (except, of course, 
in the trivial case where the language you choose already has the 
feature built in, in which case the effort is obviously zero).

rg

In comp.lang.lisp Pascal Costanza <pc@p-cos.net> wrote:

>c) Just out of interest: Do you never need to interoperate between 
>applications developed in different languages? I am asking because I 
>think a host language that eases embedding of specialized languages also 
>  eases interoperability. (This is not a rhetorical question.)

Hmm, the rage today seem to be CORBA or XML-RPC style stuff. Not
that I want to advocate that in general but I'd think the problem
is language-independent and would be the same no matter if you use
Lisp, or Java, or ML, or whatever (although using CORBA with ML is
a bit stretching my imagination atm. but could probably be done
by deriving structures+their signatures from the IDL or whatever.)

mkb.

Matthias Buelow wrote:
> In comp.lang.lisp Pascal Costanza <pc@p-cos.net> wrote:
> >Or an interpreter of such a language, but with s-expression syntax, to
> >avoid parsing. Or a compiler of such a language with s-expression syntax
> >to Lisp or Scheme. Or a set of macros that effectively perform the
> >translation from that s-expression-based language to Lisp or Scheme.
>
> Yes, well.. but that's beside the point since we were talking about
> adding features to Lisp in the sense of those features then being
> available for any Lisp program, and not just for embedded sub-languages.
> It's like pregnancy; either a woman is pregnant, or she isn't.
> There's no "somewhat" (partially) pregnant.

A person can have blonde hair, a "feature" they remove by religiously
dyeing it blue.

And still, that person may be "partially" blonde. ;)


> Apart from that, after a number of years of experimenting, I
> personally have come to the conclusion that I prefer a portfolio
> of distinct languages with (potentially very different) specialized
> syntax+semantics, for different application domains, to a
> stuff-it-all-into-one language (such as Common Lisp attempts to be,
> at least theoretically). It's a different philosophy and one that
> is, imho, more successful.

Lisp is a tool. Not a philosophy. The only philosophizing Lisp does is
in some AI lab.

Many Lisp users are fluent in multiple programming languages, and are
more than eager to honestly opine which tool is best for your job, and
any Lisp gotchas to watch out for.
http://lisp.tech.coop/Lisp%20Gotchas

I understand skepticism is required in computer "science," as it
features so many reality distortion fields and false advertising. But
that does not mean we should make grand claims about its Philosophy, or
make assumption-laden "proofs" claiming Lisp is too powerful to ever
make a tender chicken. Because that only adds to the reality distortion
field.


Tayssir

Matthias Buelow wrote:
> In comp.lang.lisp Pascal Costanza <pc@p-cos.net> wrote:
> 
>>c) Just out of interest: Do you never need to interoperate between 
>>applications developed in different languages? I am asking because I 
>>think a host language that eases embedding of specialized languages also 
>> eases interoperability. (This is not a rhetorical question.)
> 
> Hmm, the rage today seem to be CORBA or XML-RPC style stuff. Not
> that I want to advocate that in general but I'd think the problem
> is language-independent and would be the same no matter if you use
> Lisp, or Java, or ML, or whatever (although using CORBA with ML is
> a bit stretching my imagination atm. but could probably be done
> by deriving structures+their signatures from the IDL or whatever.)

In an integrated environment, you can easily pass values unchanged from 
one sublanguage to another one. With RPC-style approaches, you will get 
overhead and/or semantical issues with serialization/deserialization. So 
I think there's an important difference here.


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

Matthias Blume wrote:
> Ron Garret <rNOSPAMon@flownet.com> writes:
>> Who ever said that there was?
> 
> You.  You said that there are no features that any other langugage has
> that Lisp does not have and which could not easily be implemented
> within the language.  That claim is just false.

Indeed, and that incorrect statement is the most commonly cited
justification for using Lisp. Beyond that there is also the implication
that Jo-coder can actually implement any language feature himself.

IMHO, Lisp has a huge number of advantages over assembler and C. So if
they're your alternatives then go for Lisp. If you have the freedom to
choose any language then look at something a little more modern...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

On Sat, 24 Sep 2005 20:51:31 +0100, Jon Harrop <usenet@jdh30.plus.com> wrote:

[Content garbage-collected.]

Hmm, first the bloke who started this thread, then Matthias Buelow
resurfaces, and now Dr. "Flying Frog" Harrop is back again as well.

Is this Troll Day, or what?  Do you guys all have one big boot camp
with free Internet access?  Well, I hope you have fun over there.

What I don't understand, though, is the following: If it's so obvious
that Lisp is crap why are you still hanging around here?  Trying to
save young, innocent souls?  Or are the c.l.l inhabitants simply too
troll-friendly?

Sigh,
Edi.

-- 

Lisp is not dead, it just smells funny.

Real email: (replace (subseq "spamtrap@agharta.de" 5) "edi")

Kris Cipa wrote:
> 
> It is not so much that the course was taught badly - I think it was
> fine as far as it goes. It is just that the programming language itself
> feels so klunky and basic.
> Actually it reminded me of my days coding in BASIC on a Spectrum as a
> kid: in both cases you have to go through hoops to make the compiler
> happy rather than the compiler making things easy for you. I mean
> there's something called parsers, they've been around for years, so why
> does the user have to use raw AST to write programs in Lisp? Just like
> in old BASICs where you had to number your lines so interpreter can
> execute them in the correct order.
> 
> Apparently it's so you can obfuscate the code with macros, but come on,
> even if you really wanted those (I don't) there must be a better way
> than coding in raw syntactic representation!

On the contrary, Lisp is the only language where you rarely write raw 
syntax trees, because it you can easily add abstractions to it.

In fact, Lisp is the only language where all the following statements 
are true:

1. The rules for parsing text into a syntax tree are extremely simple.
    (It can be spec'd informally in under a page)
2. The rules for evaluating the raw syntax tree are extremely simple.
    (It can be spec'd informally in under a page)
3. You are not limited to evaluating only raw syntax tree.
4. You are not limited to parsing using only the built in rules.

And it is entirely because of macros that this is the case.  In 
addition, Lisp has many other nice properties:

5. The language is interactive.  You can test code as you write it.
6. The language is (usually) natively compiled.  Code is output that is
    fast and small.
7. The whole language is always available.  In particular, 3 and 4 are
    done using existing code.

All these sound like good properties to have, right?  And Lisp has all 
of them (and has had them since the mid-80s). But somehow, no other 
language supports even five of these seven properties.  Other so-called 
"modern, high-level languages" support from one of these properties 
(Java and C# get 6, but only with JIT compilers) to two of them (C++ 
gets 3 and 6) to three or four of them (Python gets 1, 2, and 5; 6 is 
debatable).

As an example, when you write the following in C#, you're using the 
built in "foreach" keyword:

foreach( string s in strings ) {
   Console.WriteLine( s );
}

But when you write the comparable code in Lisp, you're using the library 
level "dolist":

(dolist (s strings)
   (write-line s))

The raw syntax tree this represents is a lot bigger:

(block nil
   (let ((#:n-list4423 strings))
     (tagbody
      #:start4424
       (if (not (endp #:n-list4423))
           (progn
             nil
             (let ((s (car #:n-list4423)))
               (setq #:n-list4423 (cdr #:n-list4423))
               (tagbody (write-line s)))
             (go #:start4424))
           nil)))
   nil)

Concepts that are built in to other languages can be added to Lisp by 
any programmer.  Imagine if you could add the changes from C# 2.0 and 
3.0 to C# 1.0 without requiring a new compiler or a new runtime.

> And of course there's tons of other issue, you can imagine what: the
> braindead naming conventions: either cryptic like lambda, car, cdr,
> cdaadr, princ and company, or long winded verbosities like
> call-with-current-continuation or multiple-value-bind;

These are true, but extremely easy to fix.  Fixes range from 
instantaneous Here's a fix for lambda, call-with-current-continuation, 
and multiple-value-bind:

(defmacro fn (&rest args) `(lambda ,@args))
(defmacro call/cc (&rest args) `(call-with-current-continuation,@args))
(defmacro mv-bind (&rest args) `(multiple-value-bind ,@args))

 > or IDEs, the list just goes on.

I'd say that 90% of what an IDE is used for can be done better with 
macros and an interactive environment.  Out of the remaining 10%, 5% can 
be done just fine with Emacs and Slime.

> the almost total lack of useful libraries

This is true.  The only problem I have currently with Lisp is the lack 
of libraries.  But with CFFI and Veranzzno (or however it's spelled) all 
C and C++ libraries should now be Lisp libraries as well.

   -- MJF

Pascal Costanza <pc@p-cos.net> writes:

> Matthias Blume wrote:
>
>> You mean I can use Lisp to implement some /other/ language that has
>> H-M typing?  Well, duh!  I can do that using pretty much /any/
>> language.
>
> Yes, but not as easily. That's the whole point.

I think Pascal is being too brief here, perhaps because he has made
the real point elsewhere in the thread. But I'll reiterate it: The
difference between Lisp and most other languages is that while you can
use any language to implement an interpreter or compiler for another
language that has H-M typing (or whatever other language feature you
want), in Lisp you can easily implement an interpreter or compiler for
such a langugae in a way that allows programs written in that language
to be embedded in Lisp programs, passing data back and forth between
the embedded program and the containing Lisp world.

-Peter

-- 
Peter Seibel           * peter@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp  * http://www.gigamonkeys.com/book/

Edi Weitz <spamtrap@agharta.de> writes:

> On Sat, 24 Sep 2005 20:51:31 +0100, Jon Harrop <usenet@jdh30.plus.com> wrote:
> 
> [Content garbage-collected.]
> 
> Hmm, first the bloke who started this thread, then Matthias Buelow
> resurfaces, and now Dr. "Flying Frog" Harrop is back again as well.
> 
> Is this Troll Day, or what?  Do you guys all have one big boot camp
> with free Internet access?  Well, I hope you have fun over there.
> 
> What I don't understand, though, is the following: If it's so obvious
> that Lisp is crap why are you still hanging around here?  Trying to
> save young, innocent souls?  Or are the c.l.l inhabitants simply too
> troll-friendly?

Ron Garret is starting to understand Erik Naggum ... if there was ever
an objective proof that c.l.l is too troll-friendly :-)

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | Free Mumia Abu-Jamal! |
     ,--'    _,'   | Abolish the racist    |
    /       /      | death penalty!        |
   (   -.  |       `-----------------------'
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               

Panu Kalliokoski <atehwa@sange.fi> writes:

> In <3M-20050924185232@ram.dialup.fu-berlin.de> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>  One should never see 3M lines of anything.
>
> My point exactly, and explained on the page FactoringLargePrograms...
> another older writing of mine on the subject is
> http://c2.com/cgi/wiki?WhatIsaProject
>
>>(while(print(eval(read)))
>
> I find it somehow funny that the expression is missing a parenthese. :)

The Bug/LoC increases when the LoC decreases.
It also increases when the LoC increases, you neet to have a medium LoC/function.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w--- 
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++ 
G e+++ h+ r-- z? 
------END GEEK CODE BLOCK------

Ron Garret <rNOSPAMon@flownet.com> writes:

> It is true that the result of performing a static type check on certain 
> Lisp programs may be that the program is incorrect with respect to 
> certain static criteria.

And in such a case, it would be great (IMO) to have a compiler that
would tell you that, *and* still compile the program, because...

> It is also true that the static type semantics 
> of certain Lisp and Scheme programs might not be particularly 
> interesting or useful.

However, in the last 10 years there has been a lot of promising work
in type theory.  There are funky static type systems that let you
reason about some interesting aspects of programs, but aren't all
terribly well suited to having a general purpose programming language
based on them -- because they have some weird restrictions or
properties.  Type theory is only going to advance, we're not going to
learn less about it as time goes on -- so eventually we'll have some
(static) type systems that are really practically useful.  I think the
Lispy (or at least CMU-Lispy) approach of noninterfereing static type
checking will really shine then.

> But all that is beside the point.  It goes 
> without saying that even Lisp is subject to the fundamental constraints 
> of computation.  That does not change the fact that it is much easier to 
> add Hindley-Milner type checking to Lisp than to any other language that 
> does not natively possess it.

No doubt.  Well, maybe Smalltalk.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | Free Mumia Abu-Jamal! |
     ,--'    _,'   | Abolish the racist    |
    /       /      | death penalty!        |
   (   -.  |       `-----------------------'
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               

Edi Weitz <spamtrap@agharta.de> wrote:

>Hmm, first the bloke who started this thread, then Matthias Buelow
>resurfaces, and now Dr. "Flying Frog" Harrop is back again as well.
>Is this Troll Day, or what?  Do you guys all have one big boot camp
>with free Internet access?  Well, I hope you have fun over there.

Maybe you should come to understand that you haven't rented Usenet
and if you don't like the discussions, then simply stop reading.

mkb.

Ron Garret <rNOSPAMon@flownet.com> writes:

> In article <m2hdcad2s7.fsf@hanabi.local>,
>  Matthias Blume <find@my.address.elsewhere> wrote:
>
> > You mean I can use Lisp to implement some /other/ language that has
> > H-M typing?  Well, duh!  I can do that using pretty much /any/ language.
> 
> Of course you can.  But in any other language it's hard.  In Lisp it's 
> (comparatively) easy.  For example, the language for which you implement 
> HM typing could be a subset or minor variant of Lisp.  Lisp includes 
> features that make it easy to implement such subsets and minor variants, 
> and in this regard Lisp is unique.

And the "other language" can probably call back and forth with the
host Lisp, sharing objects and doing things to them, which is all
there is to Lisp.  So in effect, it can be perfectly integrated and
quite seamless.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | Free Mumia Abu-Jamal! |
     ,--'    _,'   | Abolish the racist    |
    /       /      | death penalty!        |
   (   -.  |       `-----------------------'
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               

Kris Cipa wrote:
> What's so great about lisp?

Or alternatively,

What's so great about Kris Cipa?

Wade

In comp.lang.lisp Thomas F. Burdick <tfb@conquest.ocf.berkeley.edu> wrote:

>And in such a case, it would be great (IMO) to have a compiler that
>would tell you that, *and* still compile the program, because...
>
>> It is also true that the static type semantics 
>> of certain Lisp and Scheme programs might not be particularly 
>> interesting or useful.

I don't know why it seems to be difficult to understand that for some
application domains you'd need the compiler to do as much work as
possible to avoid any kind of runtime error (and that implies static
type checking), while for other domains it might be more beneficial to
use a more dynamic approach.

Everything where human life or expensive property is at risk would fall
into the earlier domain (say, control software for a nuclear reactor,
the fly-by-wire software of aircraft, car electronics).  The same for
applications where the risk is not that high for the user, but for the
manufacturer, that is for example, if you produce a million high-tech
washing machines[1] per year, you'd want the software to be as bug free
as possible, because having to send a service technician into a million
households to upgrade the firmware because it throws a runtime type
error and stops washing laundry (or floods the room) would be ruinous to
your reputation aswell as operation.

OTOH, most end-user consumer software, in-house support software, or web
services, which can be patched or maintained with relative ease, and
which aren't typically used in situations where human life is at risk,
are a lot less critical.  There the benefit of more relaxed and
comfortable programming with runtime typing most likely offsets any
disadvantages.

mkb.

[1] I don't know how washing machines are programmed; probably it's some
8-bit microcontroller and C (or even assembler).  But these appliances
get more complicated over time aswell.

Pascal Costanza <pc@p-cos.net> writes:

> Matthias Buelow wrote:
> 
> > In comp.lang.lisp Pascal Costanza <pc@p-cos.net> wrote:
> 
> > It's like pregnancy; either a woman is pregnant, or she isn't.
> > There's no "somewhat" (partially) pregnant.
> 
> Yes, there is. That's why some think that abortion is acceptable. (Not
> that I know how this would be related to the topic at hand... ;)
> 

not to mention the pseudo-pregnancies where the female's body hormonally
acts just like she's pregnant even when she isn't.

Gregm

Matthias Buelow wrote:

> Edi Weitz <spamtrap@agharta.de> wrote:
> 
> 
>>Hmm, first the bloke who started this thread, then Matthias Buelow
>>resurfaces, and now Dr. "Flying Frog" Harrop is back again as well.
>>Is this Troll Day, or what?  Do you guys all have one big boot camp
>>with free Internet access?  Well, I hope you have fun over there.
> 
> 
> Maybe you should come to understand that you haven't rented Usenet
> and if you don't like the discussions, then simply stop reading.
> 
> mkb.

Maybe you should come to understand that you haven't rented Usenet and 
if you do not like regulars raining on troll parades, then there is 
nothing you can do about it. Nyeah-nyeah.


-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state 
I finally won out over it."
     Elwood P. Dowd, "Harvey", 1950

Wade Humeniuk wrote:

> Kris Cipa wrote:
> 
>> What's so great about lisp?
> 
> 
> Or alternatively,
> 
> What's so great about Kris Cipa?

Kris Cipa is a prick.

:)

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state 
I finally won out over it."
     Elwood P. Dowd, "Harvey", 1950

Matthias Buelow wrote:
> In comp.lang.lisp Thomas F. Burdick <tfb@conquest.ocf.berkeley.edu> wrote:
> >And in such a case, it would be great (IMO) to have a compiler that
> >would tell you that, *and* still compile the program, because...
> >
> >> It is also true that the static type semantics
> >> of certain Lisp and Scheme programs might not be particularly
> >> interesting or useful.
>
> I don't know why it seems to be difficult to understand that for some
> application domains you'd need the compiler to do as much work as
> possible to avoid any kind of runtime error (and that implies static
> type checking), while for other domains it might be more beneficial to
> use a more dynamic approach.

Lisp users do understand it. This is why people write powerful type
systems embedded in Common Lisp, and no doubt Scheme. One example
(which I haven't tried out but read about) is:
http://www.lambdassociates.org/aboutqi.htm
http://www.lambdassociates.org/studies/study03.htm


Tayssir

Kenny Tilton <ktilton@nyc.rr.com> wrote:

>Maybe you should come to understand that you haven't rented Usenet and 
>if you do not like regulars raining on troll parades, then there is 
>nothing you can do about it. Nyeah-nyeah.

I don't care about certain people "raining on troll parades" but when
someone includes me in such a "raining", where I certainly don't troll,
that person surely will get an answer from me.

mkb.

Matthias Buelow wrote:
> I don't know why it seems to be difficult to understand that for some
> application domains you'd need the compiler to do as much work as
> possible to avoid any kind of runtime error (and that implies static
> type checking), while for other domains it might be more beneficial to
> use a more dynamic approach.
> 
> Everything where human life or expensive property is at risk would fall
> into the earlier domain (say, control software for a nuclear reactor,
> the fly-by-wire software of aircraft, car electronics).  The same for
> applications where the risk is not that high for the user, but for the
> manufacturer, that is for example, if you produce a million high-tech
> washing machines[1] per year, you'd want the software to be as bug free
> as possible, because having to send a service technician into a million
> households to upgrade the firmware because it throws a runtime type
> error and stops washing laundry (or floods the room) would be ruinous to
> your reputation aswell as operation.
> 
> OTOH, most end-user consumer software, in-house support software, or web
> services, which can be patched or maintained with relative ease, and
> which aren't typically used in situations where human life is at risk,
> are a lot less critical.  There the benefit of more relaxed and
> comfortable programming with runtime typing most likely offsets any
> disadvantages.
> 

I am very glad for any help that a compiler can provide to me as a 
programmer, and the insights about my code that Python (the compiler) 
sometimes shares with me can be very valuable. However, the fact that
a program passes a static typechecking compiler means only that certain
errors won't happen during program run - many errors do not manifest
themselves as a checkable type error. Furhermore, beyond nuclear 
reactors, the constraining factor in respect to program quality is the
amount of development time available. So the question there is, which
technique leads to the best programs within the development timeframe 
for a project. And there the strong dynamic typed languages shine.

Peter

-- 
pet project: http://dawn.netcologne.de
homepage:    http://www.peter-herth.de
lisp stuff:  http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/

Ron Garret <rNOSPAMon@flownet.com> writes:

> In article <1127472026.869368.13690@z14g2000cwz.googlegroups.com>,
>  "Kris Cipa" <kristinacipa@yahoo.co.nz> wrote:
> 
> > What's so great about lisp?
> 
> Macros.
> 
> Actually, that's not the real answer.  What's great about Lisp is that 
> its surface syntax is the same for its code and one of its data 
> structures.

A agree with this and even wrote a short essay on this one point:

  http://www.david-steuber.com/snippets/What_Makes_Lisp_Great/

Of course all the various features in Common Lisp (and also Scheme)
add up to make Lisp great.

-- 
You should maybe check the chemical content of your breakfast
cereal. --- Bill Watterson

Edi Weitz <spamtrap@agharta.de> writes:

> What I don't understand, though, is the following: If it's so obvious
> that Lisp is crap why are you still hanging around here?  Trying to
> save young, innocent souls?

It's the modern form of self-flagellation.

-- 
You should maybe check the chemical content of your breakfast
cereal. --- Bill Watterson

On Sat, 24 Sep 2005 23:15:18 +0000, Matthias Buelow wrote:

> I don't care about certain people "raining on troll parades" but when
> someone includes me in such a "raining", where I certainly don't troll,
> that person surely will get an answer from me.
> 

No, you are not a troll, but you might be an ass

	You're reasonably dismissive of other people's ideas.
	Your posts frequently start flame wars.
	You're easy to bait.

....Well I suppose Kenny Tilton might count as an ass under the above
criteria as well, but he's a lot more fun to read.

Matt 
(making a probably ill advised troll)

-- 
"You do not really understand something unless you can
 explain it to your grandmother." — Albert Einstein.

On Sat, 24 Sep 2005 21:18:15 +0000, Wade Humeniuk wrote:

> Kris Cipa wrote:
>> What's so great about lisp?
> 
> Or alternatively,
> 
> What's so great about Kris Cipa?
> 
> Wade

He wrote a post that got an interesting thread started. :>

On 9242 day of my life A. L. wrote:
>>What problems or limitations have you found in existing Lisp IDEs?
>>Which one(s) have you tried?  Also, which libraries do you
>>particularly miss?
>
> BLAS. Cephes. PVM. MPS. 

I have UFFI bindings for PVM with some optimizations for CMU CL.  I do
not remember exact URL of archive, so search for PVM at
http://www.cliki.net/

You can find the URL from main PVM page too.

-- 
Ivan Boldyrev

              "Assembly of Japanese bicycle require great peace of mind."

On 9242 day of my life Matthias Buelow wrote:
>>a suitable language for embedding with Common Lisp.
>
> Please explain. Of course one can write a ML/Haskell/whatever
> interpreter in Lisp or Scheme.

One can write macro that typechecks its input and ouputs program in
Lisp.  For example: <http://www.cliki.net/TypeL>.


;;;  Everything that starts with ';;;' is a comment.
;;;  This example demonstrates LETREC and curring
;;;  FACT: INTEGER -> INTEGER
(deftypel
    (fact ((letrec (((fact-acc acc n)
                     (if (0? n)
                         acc
                         (fact-acc (* acc n) (- n 1)))))
                   (fact-acc 1)))))

;;; Floating point math
;;; EXPONENTA: FLOAT -> INTEGER -> FLOAT
(deftypel
    ((exponenta x n)
     (letrec (((exp-acc e p fact i) ; LETREC is like a LABLES.
               (if (= i n)
                   e
                   (let ((new-fact (* fact i)))
                     (exp-acc (+. e (/. (*. p x) (int-to-float new-fact)))
                              (*. p  x)
                              new-fact
                              (+ i 1))))))
             (exp-acc 1.0 1.0 1 1))))


DEFTYPEL macro will infer types and may print it *at compile time*.

DEFTYPEL creates embedded language that you can use *inside* Lisp
without any other tool.

-- 
Ivan Boldyrev

              "Assembly of Japanese bicycle require great peace of mind."

In <fo3bj159sh9bhjhsai1t4ahq511f0uojhi@4ax.com> A.L. <alewando@kapturek62.com> writes:
>>>>But you can do a whole lot more in 3M lines of Lisp/Haskell than you can
>>>>do in 3M lines of Java/C.
>>>Have you ever seen 3M lines of Haskell?... 3M lines means about 50
>>>people team, and majority must know programming language very well.
>>>Have you seen 25 Haskell programmers in one place?...
>>How does one "see" 3M lines of anything?-)  No, I haven't tried; the
>>claim was an extrapolation of experiences with shorter programs.
>Extrapolate linearly?... Sorry, life is more complicated...

I admire your effort to misunderstand the claim, but no, the (not
necessarily linear) extrapolation goes like this: "people can do a whole
lot more in 100KLOC of Lisp/Haskell than in the same amount of Java/C,
so they can do a whole lot more in 3MLOC of Lisp/Haskell than in the
same amount of Java/C."

The claim is vague and there's no kind of "reasoning" here, only
intuition.  I find it very improbable that Lisp would require a lot
_less_ lines to achieve some goal with line counts up to 100K, but would
begin to require _more_ (or not significantly less) lines to achieve
some goal after some point in LOC.  And even linear extrapolation is not
out of question, because I didn't require the 3M lines of code to be
interrelated.  If it is divided into chunks with one-way dependencies,
linear extrapolation is also a sensible assumption.

The thread started with talk about "projects", which is a bad unit for
assessing code size, as I argue in http://c2.com/cgi/wiki?WhatIsaProject.
Additionally, IMO you should never make (and there should never be need
for) "biggest inseparable components" (that is, chunks of code whose no
part has independent meaning and API) bigger than, say, 30KLOC, as I
argue in http://c2.com/cgi/wiki?FactoringLargePrograms.  I urge you to
find _any_ blob or code, in _any_ language, that has 3M lines or more,
and is not actually composed of many sub-programs most of which have
mutually independent semantics.

Panu
-- 
personal contact: atehwa@iki.fi, +35841 5323835, +3589 85619369
work contact: panu.kalliokoski@helsinki.fi, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/

Matthias <no@spam.please> writes:

> A.L. <alewando@kapturek62.com> writes:
>
>> On Sat, 24 Sep 2005 15:33:50 +0200, Paolo Amoroso
>> <amoroso@mclink.it> wrote:
>> >
>> BLAS. Cephes. PVM. MPS. 
>
> For BLAS you have Matlisp: http://matlisp.sourceforge.net/

So, cool. Thanks.

-- 

Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html

"All animals are equal, but some animals are more equal than others."
    - Orwell, Animal Farm, 1945

Matthias Buelow <mkb@incubus.de> writes:

> In comp.lang.lisp Thomas F. Burdick <tfb@conquest.ocf.berkeley.edu> wrote:
> 
> >And in such a case, it would be great (IMO) to have a compiler that
> >would tell you that, *and* still compile the program, because...
> >
> >> It is also true that the static type semantics 
> >> of certain Lisp and Scheme programs might not be particularly 
> >> interesting or useful.
> 
> I don't know why it seems to be difficult to understand that for some
> application domains you'd need the compiler to do as much work as
> possible to avoid any kind of runtime error (and that implies static
> type checking), while for other domains it might be more beneficial to
> use a more dynamic approach.

I don't know why it seems to be difficult to understand that a
compiler that is able to determine static properties of a program, but
still compile failing programs, can be used in both use models.  CL
even encourages you in this by giving you three return values for
compile-file.

Now, how do you propose taking a language that has bought into the
static approach, that refuses to compile anything that's not
statically type-checkable, and support the dynamic approach?  It's
going to be orders of magnitude more difficult.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | Free Mumia Abu-Jamal! |
     ,--'    _,'   | Abolish the racist    |
    /       /      | death penalty!        |
   (   -.  |       `-----------------------'
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               

David Steuber wrote:
> A agree with this and even wrote a short essay on this one point:
> 
>   http://www.david-steuber.com/snippets/What_Makes_Lisp_Great

Hm, http connections to you time out...

-- 
My mouth says the words, my brain is thinking monstertrucks.
Joey (Friends)

Ulrich Hobelmann wrote:
> David Steuber wrote:
>> A agree with this and even wrote a short essay on this one point:
>>
>>   http://www.david-steuber.com/snippets/What_Makes_Lisp_Great
> 
> Hm, http connections to you time out...

Pings too. but nevermind.  From my university I can reach your site.

Seems like I'm not only client of one of the largest German ISPs, but 
also one of the worst ones (the last week it happened more than once 
that I simply couldn't connect to some websites...).

-- 
My mouth says the words, my brain is thinking monstertrucks.
Joey (Friends)

Kristof Bastiaensen <kristof@vleeuwen.org> writes:

> Do you know a better alternative (a free, programmable, general
> purpose text-editor that makes it easy to edit lisp programs)?

How about notepad? :-)

> People are rhapsodizing about many languages.  Read the newsgroups
> about Ruby, Ocaml, Haskell, scheme...  In a way they are all right.
> However people who are advocating these languages usually know more
> languages than people who say they like Java.

How so very true!

'Andreas
-- 
Wherever I lay my .emacs, there's my $HOME.

Ulrich Hobelmann <u.hobelmann@web.de> writes:
>> Hm, http connections to you time out...
>
> Pings too. but nevermind.  From my university I can reach your site.

FWIW, I can't access David's site from my ISP either.

-- 
Luis Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

Edi Weitz wrote:
> What I don't understand, though, is the following: If it's so obvious
> that Lisp is crap why are you still hanging around here?

Like I said, Lisp has many clear advantages over "conventional"
languages. I don't mind people stating that.

> Trying to save young, innocent souls?

I'm surprised that this group is so tolerant of misinformation.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Thomas F. Burdick wrote:
> Now, how do you propose taking a language that has bought into the
> static approach, that refuses to compile anything that's not
> statically type-checkable, and support the dynamic approach?  It's
> going to be orders of magnitude more difficult.

No, it's trivial. You box values inside variant constructors, e.g. `Int 3,
`Float 4. An obvious example of this (albeit "hidden") is the use of a list
to represent a 3-tuple:

  [1; 2; 3]
  (1, 2, 3)

In the latter case, the compiler will guarantee that the "list" only ever
contains exactly three elements.

In practice, you rarely need to circumvent static typing and, when you do
have to, it is very easy.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Peter Seibel wrote:
> I think Pascal is being too brief here, perhaps because he has made
> the real point elsewhere in the thread. But I'll reiterate it: The
> difference between Lisp and most other languages is that while you can
> use any language to implement an interpreter or compiler for another
> language that has H-M typing (or whatever other language feature you
> want), in Lisp you can easily implement an interpreter or compiler for
> such a langugae in a way that allows programs written in that language
> to be embedded in Lisp programs, passing data back and forth between
> the embedded program and the containing Lisp world.

That seems like a much more reasonable justification to me. I don't believe
it is "much easier" in Lisp but I do believe that the result will be more
interoperable with Lisp. However, that benefit works both ways - an
interpreter/compiler written in ML will be interoperable with ML.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

>>>>> "JH" == Jon Harrop <usenet@jdh30.plus.com> writes:
[...]
    JH> Like I said, Lisp has many clear advantages over
    JH> "conventional" languages. I don't mind people stating that.

Thank you very much for not minding us.  Like you said:

"IMHO, Lisp has a huge number of advantages over assembler and C. So if
they're your alternatives then go for Lisp. If you have the freedom to
choose any language then look at something a little more modern..."

(  <4335af1c$0$16303$ed2619ec@ptn-nntp-reader01.plus.net> )

    Edi> Trying to save young, innocent souls?

    JH> I'm surprised that this group is so tolerant of
    JH> misinformation.

We are not.  You managed to provoke me to respond, for example. 

cheers,

BM

Paul F. Dietz wrote:
> Look, having a more conventional syntax for Lisp has been tried,
> repeatedly, for more than four decades.  Each time it's been tried
> it's failed to gain any traction.  The reason is that the syntax
> becomes natural with just a little experience -- it's just a syntax;
> it's not there to 'make the compiler happy' -- and the payback
> from macros is tremendous.

This raises an interesting question. Of the enormous number of Lisp
extensions that have been invented over the past few decades, how many of
them have been widely adopted?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Ron Garret wrote:
> Finally, Lisp is great because at its core it is a very simple language.
> Lisp is in fact simultaneously the simplest and the most powerful [2]
> programming language ever invented (some would say "discovered").  Once
> you come to realize this all other languages start to feel like a waste
> of time.

Ultimately, how many widely-used modern languages are written on top of
Lisp?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Ron Garret wrote:
> There are probably others.  My claim is: whatever strategy you choose,
> it will be vastly easier to implement that strategy in Lisp than it will
> be to implement that strategy in any other language (except, of course,
> in the trivial case where the language you choose already has the
> feature built in, in which case the effort is obviously zero).

Your claim is so general that it covers languages we've never encountered. I
wouldn't mind that if it were based upon a proof but it is based upon an
entirely subjective belief (the notion of "vastly easier").

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jon Harrop wrote:

> I'm surprised that this group is so tolerant of misinformation.

The only example of a language construct given in this discussion that 
is purportedly not easy to integrate into Lisp is that of a static type 
system. It is not only comparatively easy to integrate static type 
checking, but at least three examples have been given (ACL2, Qi, TypeL).

It has also been discussed what the tradeoffs are. Again, the "easy" 
part is the fact that you don't have to worry about syntax, that you can 
reuse a lot of already existing functionality, and that you can easily 
interoperate between incompatible language extensions. The first two 
points reduce the development time while the last point eases, for 
example, bootstrapping because you can reuse existing tools like 
debuggers, pretty printers, and so on.

If you have other examples that are still harder to implement in Lisp in 
spite of these advantages, please don't hide them from us.


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

Jon Harrop wrote:
> Paul F. Dietz wrote:
> 
>>Look, having a more conventional syntax for Lisp has been tried,
>>repeatedly, for more than four decades.  Each time it's been tried
>>it's failed to gain any traction.  The reason is that the syntax
>>becomes natural with just a little experience -- it's just a syntax;
>>it's not there to 'make the compiler happy' -- and the payback
>>from macros is tremendous.
> 
> This raises an interesting question. Of the enormous number of Lisp
> extensions that have been invented over the past few decades, how many of
> them have been widely adopted?

I don't have a complete overview, but ACL2, Haskell and AspectJ come to 
mind. (The first versions of AspectJ were written in Common Lisp, IIRC 
the first version of Haskell as well. ACL2 is still implemented in 
Common Lisp.)

There are probably other examples.

Here is an overview of what ACL2 is used for 
http://www.cs.utexas.edu/users/moore/publications/acl2-papers.html

You will probably find other examples at 
http://wiki.alu.org:80/Success_Stories


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

Jon Harrop wrote:
> Ron Garret wrote:
> 
>>Finally, Lisp is great because at its core it is a very simple language.
>>Lisp is in fact simultaneously the simplest and the most powerful [2]
>>programming language ever invented (some would say "discovered").  Once
>>you come to realize this all other languages start to feel like a waste
>>of time.
> 
> Ultimately, how many widely-used modern languages are written on top of
> Lisp?

How many people listen to Britney Spears? What does it prove?


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

Bulent Murtezaoglu wrote:
>>>>>> "JH" == Jon Harrop <usenet@jdh30.plus.com> writes:
> [...]
>     JH> Like I said, Lisp has many clear advantages over
>     JH> "conventional" languages. I don't mind people stating that.
> 
> Thank you very much for not minding us.  Like you said:
> 
> "IMHO, Lisp has a huge number of advantages over assembler and C. So if
> they're your alternatives then go for Lisp. If you have the freedom to
> choose any language then look at something a little more modern..."

If the OP is still listening, we should probably go into more detail about
the aspects of Lisp really are better than C/C++/Java/C#. I'll start with
HOFs, macros, safety and data structures.

> (  <4335af1c$0$16303$ed2619ec@ptn-nntp-reader01.plus.net> )
> 
>     Edi> Trying to save young, innocent souls?
> 
>     JH> I'm surprised that this group is so tolerant of
>     JH> misinformation.
> 
> We are not.  You managed to provoke me to respond, for example.

Thanks. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Matthias Buelow writes:

> In comp.lang.lisp Ron Garret <rNOSPAMon@flownet.com> wrote:
>> [2] "Most powerful" in the sense that there are features that Lisp
>> has that no other language has, and at the same time there are no
>> features that any other language has that Lisp does not have (or
>> could not be easily implemented within the language).

> How do you ("easily") implement a polymorphic type system for Common
> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
> well-known Lisp, such as Scheme) so that you can make any Common
> Lisp (or Scheme, ...) program be statically type checked?

I think this link would be interesting to some here:

   http://www.lambdassociates.org/studies/study02.htm

It's a simple type checker on top of Lisp.

-- 
Em�lio C. Lopes
Munich, Germany

Jon Harrop wrote:
> Ron Garret wrote:
> 
>>There are probably others.  My claim is: whatever strategy you choose,
>>it will be vastly easier to implement that strategy in Lisp than it will
>>be to implement that strategy in any other language (except, of course,
>>in the trivial case where the language you choose already has the
>>feature built in, in which case the effort is obviously zero).
> 
> Your claim is so general that it covers languages we've never encountered. I
> wouldn't mind that if it were based upon a proof but it is based upon an
> entirely subjective belief (the notion of "vastly easier").

No, it's based upon a fundamental principle that you don't seem to 
understand.

Read "The Roots of Lisp" by Paul Graham and "The Art of the Interpreter" 
by Guy Steele and Gerald Sussman.


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

Pascal Costanza wrote:
> It is not only comparatively easy to integrate static type 
> checking, but at least three examples have been given (ACL2, Qi, TypeL).

At least this has now been reduced to the subjective notion of
"comparatively easy". We can just agree to disagree now...

> It has also been discussed what the tradeoffs are. Again, the "easy"
> part is the fact that you don't have to worry about syntax, that you can
> reuse a lot of already existing functionality, and that you can easily
> interoperate between incompatible language extensions.

Can you elaborate on those reasons? I can't see how Lisp is any better than
the next language.

> If you have other examples that are still harder to implement in Lisp in
> spite of these advantages, please don't hide them from us.

I'd extend the static typing example to writing a whole ML interpreter, or
an OCaml interpreter. Do you really think that would be easier in Lisp than
in OCaml?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Pascal Costanza wrote:
> Jon Harrop wrote:
>> Your claim is so general that it covers languages we've never
>> encountered. I wouldn't mind that if it were based upon a proof but it is
>> based upon an entirely subjective belief (the notion of "vastly easier").
> 
> No, it's based upon a fundamental principle that you don't seem to
> understand.
> 
> Read "The Roots of Lisp" by Paul Graham and "The Art of the Interpreter"
> by Guy Steele and Gerald Sussman.

So they've quantified "vastly easier" then, have they?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

On 2005-09-25, Jon Harrop <usenet@jdh30.plus.com> wrote:
> In practice, you rarely need to circumvent static typing and, when you do
> have to, it is very easy.

So, where is the ocaml system where I can hotpatch the code while
clients are interacting with it on the network?  It's certainly doable
in static languages with enough work, but right now Lisp and Erlang have
the advantage of practicality.

Your other claims in this thread seem to continue the "misinformation"
that carries over from earlier silly threads, thus reinforcing the idea
that you may be trolling.  As someone who uses a variety of "modern"
languages regularly, I have to say that CL is much more powerful than
OCaml, even if the OCaml compiler and runtime are faster.

-- 
Julian Squires

On 2005-09-25, Jon Harrop <usenet@jdh30.plus.com> wrote:
> Ultimately, how many widely-used modern languages are written on top of
> Lisp?

Javascript is pretty widely-used, you'll have to agree.

-- 
Julian Squires

Jon Harrop wrote:

> Pascal Costanza wrote:
> 
>>It is not only comparatively easy to integrate static type 
>>checking, but at least three examples have been given (ACL2, Qi, TypeL).
> 
> At least this has now been reduced to the subjective notion of
> "comparatively easy". We can just agree to disagree now...
> 
>>It has also been discussed what the tradeoffs are. Again, the "easy"
>>part is the fact that you don't have to worry about syntax, that you can
>>reuse a lot of already existing functionality, and that you can easily
>>interoperate between incompatible language extensions.
> 
> Can you elaborate on those reasons? I can't see how Lisp is any better than
> the next language.

Because you don't watch. (Would you mind following the links that people 
are giving you?)

>>If you have other examples that are still harder to implement in Lisp in
>>spite of these advantages, please don't hide them from us.
> 
> I'd extend the static typing example to writing a whole ML interpreter, or
> an OCaml interpreter. Do you really think that would be easier in Lisp than
> in OCaml?

Yes.


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

So we have anagrams now on c.l.l?

Kris Cipa -> is a prick

jhj

Pascal Costanza wrote:
> Jon Harrop wrote:
>> This raises an interesting question. Of the enormous number of Lisp
>> extensions that have been invented over the past few decades, how many of
>> them have been widely adopted?
> 
> I don't have a complete overview, but ACL2, Haskell and AspectJ come to
> mind. (The first versions of AspectJ were written in Common Lisp, IIRC
> the first version of Haskell as well. ACL2 is still implemented in
> Common Lisp.)

ML was as well. However, at least ML and Haskell have since moved on to
having nothing to do with Lisp. This may be just because there is bartering
value in bootstrapping a new language, i.e. to showcase its abilities.

Any idea how many people use ACL2?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Pascal Costanza wrote:
> Jon Harrop wrote:
>> Ultimately, how many widely-used modern languages are written on top of
>> Lisp?
> 
> How many people listen to Britney Spears? What does it prove?

If it really is "vastly easier" to write interpreters and compilers in Lisp
then people will create new languages on top of Lisp, and other people will
use those languages. So the existence of any widely-used languages written
on top of Lisp will support that claim.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

In comp.lang.lisp Thomas F. Burdick <tfb@conquest.ocf.berkeley.edu> wrote:

>Now, how do you propose taking a language that has bought into the
>static approach, that refuses to compile anything that's not
>statically type-checkable, and support the dynamic approach?  It's
>going to be orders of magnitude more difficult.

I don't. That's the whole point. I use a different language for
where more dynamicity is desirable.

mkb.

Julian Squires wrote:
> On 2005-09-25, Jon Harrop <usenet@jdh30.plus.com> wrote:
>> Ultimately, how many widely-used modern languages are written on top of
>> Lisp?
> 
> Javascript is pretty widely-used, you'll have to agree.

Yes, absolutely. What Javascript implementations are written in Lisp?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Julian Squires wrote:
> On 2005-09-25, Jon Harrop <usenet@jdh30.plus.com> wrote:
>> In practice, you rarely need to circumvent static typing and, when you do
>> have to, it is very easy.
> 
> So, where is the ocaml system where I can hotpatch the code while
> clients are interacting with it on the network?  It's certainly doable
> in static languages with enough work, but right now Lisp and Erlang have
> the advantage of practicality.

Yes. Concurrency is probably another similar point. OCaml vs CL is OT.

> Your other claims in this thread seem to continue the "misinformation"
> that carries over from earlier silly threads, thus reinforcing the idea
> that you may be trolling.

Can you be more specific?

> As someone who uses a variety of "modern" 
> languages regularly, I have to say that CL is much more powerful than
> OCaml, even if the OCaml compiler and runtime are faster.

Sure.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Pascal Costanza wrote:
>>>If you have other examples that are still harder to implement in Lisp in
>>>spite of these advantages, please don't hide them from us.
>> 
>> I'd extend the static typing example to writing a whole ML interpreter,
>> or an OCaml interpreter. Do you really think that would be easier in Lisp
>> than in OCaml?
> 
> Yes.

I think we need to bring some code in here. In Lisp you have:

  * (eval '(+ 1 2))
  3

In OCaml (for example) there is an initial overhead because you have to
write an interpreter:

  # let rec eval = function
      | `Int n -> n
      | `Add (e1, e2) -> eval e1 + eval e2;;
  val eval : ([< `Add of 'a * 'a | `Int of int ] as 'a) -> int = <fun>
  # eval (`Add (`Int 1, `Int 2));;
  - : int = 3

That is several times as much code. However, the "eval" function is roughly
constant overhead when you come to add all of the other features of an ML
interpreter (~30kLOC). So it quickly becomes insignificant when compared to
the rest of the implementation.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jon Harrop wrote:
> Pascal Costanza wrote:
> 
>>Jon Harrop wrote:
>>
>>>Ultimately, how many widely-used modern languages are written on top of
>>>Lisp?
>>
>>How many people listen to Britney Spears? What does it prove?
> 
> If it really is "vastly easier" to write interpreters and compilers in Lisp
> then people will create new languages on top of Lisp, and other people will
> use those languages. So the existence of any widely-used languages written
> on top of Lisp will support that claim.

Examples have been mentioned in this thread.


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

Jon Harrop wrote:
> Pascal Costanza wrote:
> 
>>Jon Harrop wrote:
>>
>>>This raises an interesting question. Of the enormous number of Lisp
>>>extensions that have been invented over the past few decades, how many of
>>>them have been widely adopted?
>>
>>I don't have a complete overview, but ACL2, Haskell and AspectJ come to
>>mind. (The first versions of AspectJ were written in Common Lisp, IIRC
>>the first version of Haskell as well. ACL2 is still implemented in
>>Common Lisp.)
> 
> ML was as well. However, at least ML and Haskell have since moved on to
> having nothing to do with Lisp. This may be just because there is bartering
> value in bootstrapping a new language, i.e. to showcase its abilities.

Right, it's traditionally done like that to have a first sufficiently 
big test case. I think that Common Lisp has been used in those cases for 
prototyping which Common Lisp is particularly good at.

I don't think it's necessary that Lisp is used in the final "products" 
in order to have a convincing argument that Lisp is a good tool to get 
there.

> Any idea how many people use ACL2?

Apparently by everyone. ;)

See http://www.cs.utexas.edu/users/moore/publications/acl2-papers.html

(BTW, it doesn't have to be many people in order to be a convincing. 
There is not a strong tendency in the mainstream to use the best tools 
for developing applications. As an ML user, you probably know that 
people reject ML for equally spurious reasons.)


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

On 2005-09-25, Jon Harrop <usenet@jdh30.plus.com> wrote:
> Julian Squires wrote:
>> On 2005-09-25, Jon Harrop <usenet@jdh30.plus.com> wrote:
>>> Ultimately, how many widely-used modern languages are written on top of
>>> Lisp?
>> 
>> Javascript is pretty widely-used, you'll have to agree.
>
> Yes, absolutely. What Javascript implementations are written in Lisp?

The first javascript implementation was written in CL, apparently.  I'm
not sure if the source is available in the mozilla repositories.

-- 
Julian Squires

On 2005-09-25, Julian Squires <julian@cipht.net> wrote:
> The first javascript implementation was written in CL, apparently.  I'm
> not sure if the source is available in the mozilla repositories.

This wouldn't be the first implementation, but here's some JS related CL
in the source, anyway:

http://lxr.mozilla.org/mozilla/source/js2/semantics/

-- 
Julian Squires

Jon Harrop <usenet@jdh30.plus.com> writes:

> Peter Seibel wrote:
>> I think Pascal is being too brief here, perhaps because he has made
>> the real point elsewhere in the thread. But I'll reiterate it: The
>> difference between Lisp and most other languages is that while you can
>> use any language to implement an interpreter or compiler for another
>> language that has H-M typing (or whatever other language feature you
>> want), in Lisp you can easily implement an interpreter or compiler for
>> such a langugae in a way that allows programs written in that language
>> to be embedded in Lisp programs, passing data back and forth between
>> the embedded program and the containing Lisp world.
>
> That seems like a much more reasonable justification to me. I don't believe
> it is "much easier" in Lisp but I do believe that the result will be more
> interoperable with Lisp. However, that benefit works both ways - an
> interpreter/compiler written in ML will be interoperable with ML.

I don't know enought about ML to say whether that's true or
not. However here's what I mean by embed. In Lisp, assuming I went to
the bother to write a C->Lisp compiler in Lisp, I could then put the
following two definitions in a file and load it into a running lisp
with the standard LOAD function (possibly compiling it with Common
Lisp's standard COMPILE-FILE function first) and it would just
work. (By which I mean the string in the DEFINE-C-FUNCTION would be
parsed as C code and compiled, creating a function FOO which I can
call from Lisp as I do in the BAR function.)

  (define-c-function "int foo(int x) { return 2 * x; }")

  (defun bar () (foo 20))

The only part that is hard about this is writing the C->Lisp
compiler. (And even that bit is likely to be as easy or easier in Lisp
as in any other language because it's such an excellent languge for
doing symbolic computation and compilers are fundamenatally about
symbolic computation.) Obviously if the language we want to embed is
less complex than C that part gets easier. But the rest is no work
because of the way Lisp gives us hooks into its own compiler. Does ML
give similar hooks?

-Peter

-- 
Peter Seibel           * peter@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp  * http://www.gigamonkeys.com/book/

justinhj wrote:
> So we have anagrams now on c.l.l?
> 
> Kris Cipa -> is a prick

Nonsense. Kristina Cipa -> parasitic ink -> troll.

:)

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state 
I finally won out over it."
     Elwood P. Dowd, "Harvey", 1950

In article <433697fb$0$49804$ed2e19e4@ptn-nntp-reader04.plus.net>,
 Jon Harrop <usenet@jdh30.plus.com> wrote:

> Ron Garret wrote:
> > There are probably others.  My claim is: whatever strategy you choose,
> > it will be vastly easier to implement that strategy in Lisp than it will
> > be to implement that strategy in any other language (except, of course,
> > in the trivial case where the language you choose already has the
> > feature built in, in which case the effort is obviously zero).
> 
> Your claim is so general that it covers languages we've never encountered.

That's right.  That's because the ease of implementation arises from a 
particular collection of language features that Lisp possesses that 
other languages do not have and cannot have without becoming Lisp.

> I wouldn't mind that if it were based upon a proof but it is based upon an
> entirely subjective belief (the notion of "vastly easier").

It is neither subjective nor is it a belief.  The effort required to 
implement something is an objective metric.  It's not particularly easy 
to measure with precision, but it can be done.  There are even a few 
actual data points out there, and lots and lots of anecdotal evidence.  
Granted, it's not quantum electrodynamics (and cannot be because 
psychology, economics and politics are involved), but it's not just a 
"subjective belief" either.

rg

In article <43369668$0$49804$ed2e19e4@ptn-nntp-reader04.plus.net>,
 Jon Harrop <usenet@jdh30.plus.com> wrote:

> Ron Garret wrote:
> > Finally, Lisp is great because at its core it is a very simple language.
> > Lisp is in fact simultaneously the simplest and the most powerful [2]
> > programming language ever invented (some would say "discovered").  Once
> > you come to realize this all other languages start to feel like a waste
> > of time.
> 
> Ultimately, how many widely-used modern languages are written on top of
> Lisp?

None.  But I presume that the question is rhetorical, and that the point 
you intended to make was that if it really were easier to implement 
languages in Lisp then market forces would tend to drive the industry 
towards implementing more languages in Lisp.  Since this hasn't happened 
the claim must be false.

The problem with this reasoning is that markets are not efficient, and 
markets for infrastructure (which is what languages are) are 
particularly inefficient because there are very strong positive feedback 
forces that tend to drive infrastructure markets towards standardization 
and the status quo.

Examples of this effect can be found everywhere.  My favorite example is 
urban transit in Los Angeles, which has clearly converged on a 
sub-optimal solution, but the solution is a local maximum and so it is 
all but impossible to change the situation despite the fact that, in 
contrast to the situation in computer languages, everyone recognizes 
that there is a problem.

rg

Ron Garret wrote:

> It is true that the result of performing a static type check on certain 
> Lisp programs may be that the program is incorrect with respect to 
> certain static criteria.  It is also true that the static type semantics 
> of certain Lisp and Scheme programs might not be particularly 
> interesting or useful.  But all that is beside the point.  It goes 
> without saying that even Lisp is subject to the fundamental constraints 
> of computation.  That does not change the fact that it is much easier to 
> add Hindley-Milner type checking to Lisp than to any other language that 
> does not natively possess it.

Okay; if you're not talking about an interpretation of "type checking"
that restricts what you can write, then I'll agree; yes, any code that
can be written and executed can be typechecked.  The point I was making
is that no type checker can reliably detect all programs that will run
without type errors.

Sometimes the type checker is able to construct a proof that a program
will run without type errors, and sometimes not; but when it is not
able to construct such a proof, it does not imply that the program
will cause a type error.

People who ask for static typing usually want restrictions on what
they can write.  Static-typing proponents typically want to be
prevented from writing even correct code unless their preferred
system can prove that it will not cause a type error.

Lisps permit such (correct but not provably correct by a given type 
checker) code to be written (and executed) anyway.  I regard this as
a valuable property of lisps, and a way in which they provide an
"extension" over most typechecked languages.

And turning the situation on its head, how easy do you think it is
to take a type-checked language and add an "extension" to it that
allows code not provably typesafe to be written and run in it?

				Bear

On Sun, 25 Sep 2005 16:53:01 GMT, Kenny Tilton <ktilton@nyc.rr.com>
wrote:

>
>
>justinhj wrote:
>> So we have anagrams now on c.l.l?
>> 
>> Kris Cipa -> is a prick
>
>Nonsense. Kristina Cipa -> parasitic ink -> troll.
>
>:)


Great! Below we have standard esposition of average so called "Lisp
Lover" mentality. 

A.L.

Kris Cipa wrote:
> What's so great about lisp?
> I had to use lisp in college for a course, and it looked like a
> horribly primitive and useless contraption. We even had to use emacs to
> use it, in the 21 century!. I have avoided it ever since. However I
> find more and more people rhapsodizing about how cool Lisp is and what
> an advanced language it supposedly is. I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?
> I'd like to know, what's the secret?

Perhaps your problem isn't so much LISP itself as much as the way your 
prof is trying, or perhaps not trying, to teach it.  I am currently a 
student, and this semester I am taking a course in programming languages 
in which we learn Scheme both as an example of functional programming 
and because the professor claims (and I've little reason to doubt him on 
it so far) that it will be an ideal language for writing an interpreter 
for a simple language which we will be inventing ourselves.

Anyway, interest in functional programming to be catching on at my 
university, and I can report that many students were already to some 
extent language nuts.  The class is the largest non-core course in the 
major this semester.  Most in the class report loving Scheme so far.

Count me in that group -- I came in with a slight head start, having 
explored functional programming a little over the summer.  I also 
dabbled a bit with _Practical_Common_Lisp_.  I found it a bit much, a 
dauntingly large language, and macros weirded me out at first -- I could 
see why they would be useful, but could barely imagine myself 
successfully writing one!

The course has made sense of it, however: Rather than try to present a 
sort of "Scheme for procedural programmers," the professor started by 
getting us accustomed to the mindset of functional programming itself, 
so that we understood what made Scheme different from the languages we 
were used to from other courses (Java, Ada, C, and for a few of us 
Mumps).  Once you start thinking about your programs in the way that 
Lisp/Scheme works, it just flows, or at least it does for me.  I 
actually find it to be more in tune with the way I think in general, but 
of course that is going to vary with the individual and I don't think 
it's impossible for anyone to get the hang of it.  Scheme often feels to 
me like a laser where most procedural languages are stone axes.

Lisp was ahead of its time from the start, at least that's what you're 
going to hear, and there seems to be plenty of grounds for saying so -- 
notice the way newer languages like Python are recently beginning to 
pick up on features that only Lisps had for decades.  I think it may 
have been Lisp's ensconcement in the relatively esoteric sector of AI 
that has delayed its getting the mainstream respect it deserves.

And by the way, there's not a thing wrong with using Emacs.  Emacs is a 
highly advanced environment that goes well beyond being a mere text 
editor, and lots of people swear by it to this day.  The SLIME mode 
amounts to a rich IDE for Lisp that snaps right into Emacs.  If the key 
combinations for many basic functions escape you, there are nice GUI 
versions such as XEmacs out there that give you those nice pull-down menus.

Anyway, I find that I do best starting with a small version of a 
language before learning the big version -- Luckily many of the big 
powerful languages are extensions in some sense from smaller ones.  I've 
had a much better time of learning C than when I tried to start from 
scratch with C++, and am now having a similar experience with Scheme. 
I'll feel much more confident tackling Common Lisp now.  In that spirit, 
I'd recommend installing DrScheme and working with it for a while, 
working from any of the many excellent books that are included in its 
"Help Desk" feature, or maybe first looking into _The_Little_Schemer_, a 
really unique book that will introduce you to what I called above the 
"mindset" of Scheme starting from the very basics.

cheers,
--chuck--

Ray Dillinger wrote:

> People who ask for static typing usually want restrictions on what
> they can write.  Static-typing proponents typically want to be
> prevented from writing even correct code unless their preferred
> system can prove that it will not cause a type error.

People cannot be prevented from writing "incorrect" code, they can only 
be prevented from _running_ "incorrect" code. In a system that allows 
them to run "incorrect" code, they could just refrain from running such 
code. It escapes me why this needs to be enforced.

I think the problem with proponents of statically typed language is more 
a psychological one. They would like _others_ not to be able to run 
"incorrect" code, for various reasons.

The story is of course a little bit different for static type systems 
that change the semantics of a program...

Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

'Cipa' means 'pussy' in Polish... Maybe Kris & A.L. are the same
persons ?

Pascal Costanza wrote:
> Ray Dillinger wrote:
> 
>> People who ask for static typing usually want restrictions on what
>> they can write.  Static-typing proponents typically want to be
>> prevented from writing even correct code unless their preferred
>> system can prove that it will not cause a type error.
> 
> 
> People cannot be prevented from writing "incorrect" code, they can only 
> be prevented from _running_ "incorrect" code. In a system that allows 
> them to run "incorrect" code, they could just refrain from running such 
> code. It escapes me why this needs to be enforced.

This is mere pedantry.  Stop it; it does not contribute to
the conversation. It was clear to anyone who is not mentally
defective what I meant by generalizing the verb "writing."
In the context of a programming system that means writing
*programs* which are, by definition, well-formed according
to the rules of the language.

> I think the problem with proponents of statically typed language is more 
> a psychological one. They would like _others_ not to be able to run 
> "incorrect" code, for various reasons.

There are occasional legitimate reasons for doing that, I
suppose; they don't interest me much.  Anyway, if you want
to, you can use a type checker for Lisp code, and then
tell your developers that running and bug-free is not
enough; it must also be provably free of type errors by
your type checker.

> The story is of course a little bit different for static type systems 
> that change the semantics of a program...

True... but not the subject under discussion, I think.

				Bear

tichy wrote:

> 'Cipa' means 'pussy' in Polish... Maybe Kris & A.L. are the same
> persons ?
> 

what does kristina mean? googling kristina-cipa picks up some polish 
porn sites.

too bad, me and AL really liked parasitic ink.

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state 
I finally won out over it."
     Elwood P. Dowd, "Harvey", 1950

Peter Seibel wrote:
> Does ML give similar hooks?

Yes and no. :-)

ML itself doesn't (it's a family of languages) but OCaml allows you to
generate and dynamically load bytecode, or you can spit out OCaml source,
compile it with ocamlopt on-the-fly and marshalling to communicate. I've
used the latter approach to implement a JIT compiler.

Then there's MetaOCaml, that gives you statically typed code-as-data that
you can compile and execute.

So yes, you can easily get the same functionality. And no, it doesn't work
in the same way.

I get the impression that code-as-data butts heads with static type
checking. I'll have to study more before I can say anything definitive
though...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jon Harrop wrote:
> Pascal Costanza wrote:
> 
>>Jon Harrop wrote:
>>
>>>Your claim is so general that it covers languages we've never
>>>encountered. I wouldn't mind that if it were based upon a proof but it is
>>>based upon an entirely subjective belief (the notion of "vastly easier").
>>
>>No, it's based upon a fundamental principle that you don't seem to
>>understand.
>>
>>Read "The Roots of Lisp" by Paul Graham and "The Art of the Interpreter"
>>by Guy Steele and Gerald Sussman.
> 
> So they've quantified "vastly easier" then, have they?

No.


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

Pascal Costanza wrote:
> Jon Harrop wrote:
>> ML was as well. However, at least ML and Haskell have since moved on to
>> having nothing to do with Lisp. This may be just because there is
>> bartering value in bootstrapping a new language, i.e. to showcase its
>> abilities.
> 
> Right, it's traditionally done like that to have a first sufficiently
> big test case. I think that Common Lisp has been used in those cases for
> prototyping which Common Lisp is particularly good at.
> 
> I don't think it's necessary that Lisp is used in the final "products"
> in order to have a convincing argument that Lisp is a good tool to get
> there.

Yes, but if there were some widely-used languages that were still based on
Lisp then that would be evidence that Lisp was better for more than just
prototyping. As you say, absence of evidence is not evidence of absence.

>> Any idea how many people use ACL2?
> 
> Apparently by everyone. ;)

:-)

> See http://www.cs.utexas.edu/users/moore/publications/acl2-papers.html
> 
> (BTW, it doesn't have to be many people in order to be a convincing.
> There is not a strong tendency in the mainstream to use the best tools
> for developing applications. As an ML user, you probably know that
> people reject ML for equally spurious reasons.)

Very true.

I believe Lisp is more widely used than all MLs put together ATM. Outside
North America, MLs are probably taught at university more than Lisp though,
so maybe that'll change.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Ron Garret wrote:
> In article <43369668$0$49804$ed2e19e4@ptn-nntp-reader04.plus.net>,
>  Jon Harrop <usenet@jdh30.plus.com> wrote:
> > Ultimately, how many widely-used modern languages are written on top of
> > Lisp?
>
> None.  But I presume that the question is rhetorical, and that the point
> you intended to make was that if it really were easier to implement
> languages in Lisp then market forces would tend to drive the industry
> towards implementing more languages in Lisp.  Since this hasn't happened
> the claim must be false.

"This melding of code and data is central to all dialects of Lisp, and
is fundamental to the way Microsoft is integrating multiple expression
languages (most notably SQL) in future versions of the Microsoft=AE .NET
Framework."
  -- Don Box
http://msdn.microsoft.com/msdnmag/issues/05/10/EndBracket/default.aspx

There's something oddly chilling about this quote though. (Perhaps he's
referring to XML? ;P )

Ron Garret wrote:
> In article <43369668$0$49804$ed2e19e4@ptn-nntp-reader04.plus.net>,
>  Jon Harrop <usenet@jdh30.plus.com> wrote:
>> Ultimately, how many widely-used modern languages are written on top of
>> Lisp?
> 
> None.  But I presume that the question is rhetorical, and that the point
> you intended to make was that if it really were easier to implement
> languages in Lisp then market forces would tend to drive the industry
> towards implementing more languages in Lisp...

No, I had no idea if any were. Had there been then it would have been a
simple killer example to settle the debate.

My personal impression is that writing a simple (i.e. slow) interpreter is
trivial in any modern FPL and writing a good (i.e. fast to compile and
producing fast executables) native-code compiler is very hard in any
language. Lisp may well be easier for a middle ground, where it is hard to
achieve reasonable performance by other techniques but there isn't any
solid evidence either way. Actually, that's just given me an interesting
idea...

Anyway, the original point was that Lisp is much better than C/C++/
C#/Java/Fortran. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Ron Garret wrote:
> That's right.  That's because the ease of implementation arises from a
> particular collection of language features that Lisp possesses that
> other languages do not have and cannot have without becoming Lisp.

You make it sound like a religion. :-)

>> I wouldn't mind that if it were based upon a proof but it is based upon
>> an entirely subjective belief (the notion of "vastly easier").
> 
> It is neither subjective nor is it a belief.  The effort required to
> implement something is an objective metric.

What units do you measure effort in?

> It's not particularly easy 
> to measure with precision, but it can be done.  There are even a few
> actual data points out there, and lots and lots of anecdotal evidence.
> Granted, it's not quantum electrodynamics (and cannot be because
> psychology, economics and politics are involved), but it's not just a
> "subjective belief" either.

To a physicist, psychology and politics are subjective belief.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Luis Oliveira <luis.oliveira@deadspam.com> writes:

> Ulrich Hobelmann <u.hobelmann@web.de> writes:
> >> Hm, http connections to you time out...
> >
> > Pings too. but nevermind.  From my university I can reach your site.
> 
> FWIW, I can't access David's site from my ISP either.

First Portugal and now Germany seem to be blacklisting my IP.  I
really don't know what's going on.  I would love to get this problem
sorted out, but I simply do not know what the problem is.

I'm guessing that the gremlin with the mohawk has been playing with
the wiring again.

I can reach the http server from my location and I read news from my
server.  This falls into the weird category for sure.  Another user
from Germany was able to ping the mail server but not my server.  I
couldn't ping back.  However with Luis I can ping back.  We went over
this on #lisp.

I think a router may have a configuration issue, but I don't know
what.  I don't know if the mail server is connected to the same router
as my web server or not.  I thought that it was.  That just makes
things even more weird.  Or weirder as the case may be.

I wonder how much of the internet has me in a black hole?

Anyway, I'll see what can be done about it.  I don't want a portion of
the world deprived of my wisdom ;-)

-- 
http://www.david-steuber.com/
The UnBlog | Lisp on OS X topics for the most part
Click all the links you want.  I'll make more!

tfb@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> Now, how do you propose taking a language that has bought into the
> static approach, that refuses to compile anything that's not
> statically type-checkable, and support the dynamic approach?  It's
> going to be orders of magnitude more difficult.

Nevermind the little detail about incorrect programs compiling just
fine under heavy static checking.

-- 
http://www.david-steuber.com/
The UnBlog | Lisp on OS X topics for the most part
Click all the links you want.  I'll make more!

Jon Harrop wrote:


> 
> If it really is "vastly easier" to write interpreters and compilers in Lisp
> then people will create new languages on top of Lisp, and other people will
> use those languages. So the existence of any widely-used languages written
> on top of Lisp will support that claim.

Widely used is a criterion that you have inserted, Jon. And I'm not sure
I believe that statement anyway, since it might suggest that assembler
has great merit for writing interpreters or compilers.  Nevertheless,


If there were merely 1,000  or 10,000  or 100,000 users of languages written
on top of Lisp, would that count?  If so consider

(a) Tony Hearn's REDUCE.
(b) IBM (then NAG)'s  Scratchpad (commercialized as AXIOM)
(c) MIT's (then Symbolics') Macsyma (now mostly used as the sourceforge Maxima system)

In each case a different language (some infix notation for mathematics
is part of it), on top of lisp.

In the case of Axiom, a powerful type system is implemented, based on algebraic
properties and inheritance is implemented (e.g. rings, fields, identities
for + or *, polynomials over those base objects, etc.) The language Aldor
is part of the implementation, also implemented on Lisp.

And that's not counting the many "intermediate" languages, e.g. for
pattern matching, typesetting, etc. that may also be used inside these
systems.

You might also look up Pratt's CGOL memo to see a tour de force of
language definition.  Or Teitelman's PILOT.   Or Bobrow's STUDENT
which used a subset of English. But maybe you don't want to count
as important, very clever people doing very clever things.

see
http://www.brainyquote.com/quotes/quotes/a/abrahamlin103535.html

Please take your trolls somewhere else, Jon.

RJF

Jon Harrop <usenet@jdh30.plus.com> writes:

> I'm surprised that this group is so tolerant of misinformation.

Is that why this thread is so long?

-- 
http://www.david-steuber.com/
The UnBlog | Lisp on OS X topics for the most part
Click all the links you want.  I'll make more!

Jon Harrop <usenet@jdh30.plus.com> writes:

> I get the impression that code-as-data butts heads with static type
> checking. I'll have to study more before I can say anything definitive
> though...

It has already been proven that it does not.

Static type checking only catches a subset of programming errors
anyway.  A rather trivial subset at that.

-- 
http://www.david-steuber.com/
The UnBlog | Lisp on OS X topics for the most part
Click all the links you want.  I'll make more!

In article <pbBZe.201$Aw.3583@typhoon.sonic.net>,
 Ray Dillinger <bear@sonic.net> wrote:

> Ron Garret wrote:
> 
> > It is true that the result of performing a static type check on certain 
> > Lisp programs may be that the program is incorrect with respect to 
> > certain static criteria.  It is also true that the static type semantics 
> > of certain Lisp and Scheme programs might not be particularly 
> > interesting or useful.  But all that is beside the point.  It goes 
> > without saying that even Lisp is subject to the fundamental constraints 
> > of computation.  That does not change the fact that it is much easier to 
> > add Hindley-Milner type checking to Lisp than to any other language that 
> > does not natively possess it.
> 
> Okay; if you're not talking about an interpretation of "type checking"
> that restricts what you can write, then I'll agree; yes, any code that
> can be written and executed can be typechecked.  The point I was making
> is that no type checker can reliably detect all programs that will run
> without type errors.

Obviously.  So?

> Sometimes the type checker is able to construct a proof that a program
> will run without type errors, and sometimes not; but when it is not
> able to construct such a proof, it does not imply that the program
> will cause a type error.

Obviously.  So?

> People who ask for static typing usually want restrictions on what
> they can write.

I know of no existing system that provides that.  At best (or at worst 
depending on your proclivities) you can get restrictions on what you can 
*run*.  (I have never understood why anyone would actually consider such 
a restriction a feature rather than a bug.)

> Lisps permit such (correct but not provably correct by a given type 
> checker) code to be written (and executed) anyway.  I regard this as
> a valuable property of lisps, and a way in which they provide an
> "extension" over most typechecked languages.

Yes, and it's trivially easy to build the kind of restriction you seek:

(in-package :fascist)
(shadow 'defun)
(defmacro defun (name args &body body)
  (if (not (check-for-desired-property args body))
    (error "Bad code.  Try again.")
    `(cl:defun ,name, args, @body)))

> And turning the situation on its head, how easy do you think it is
> to take a type-checked language and add an "extension" to it that
> allows code not provably typesafe to be written and run in it?

I have no idea, but I suspect it's more than six lines of code.

rg

Richard Fateman wrote:
> Jon Harrop wrote:
>> If it really is "vastly easier" to write interpreters and compilers in
>> Lisp then people will create new languages on top of Lisp, and other
>> people will use those languages. So the existence of any widely-used
>> languages written on top of Lisp will support that claim.
> 
> Widely used is a criterion that you have inserted, Jon.

Yes.

> And I'm not sure 
> I believe that statement anyway, since it might suggest that assembler
> has great merit for writing interpreters or compilers.

If there were widely used language implementations written in assembler then
it would prove that it could be done.

If they aren't widely used then we can turn to some other form of
credibility.

> If there were merely 1,000  or 10,000  or 100,000 users of languages
> written on top of Lisp, would that count?  If so consider
> 
> (a) Tony Hearn's REDUCE.
> (b) IBM (then NAG)'s  Scratchpad (commercialized as AXIOM)
> (c) MIT's (then Symbolics') Macsyma (now mostly used as the sourceforge
> Maxima system)

REDUCE and Macsyma are probably the best examples yet, thanks. I'll have a
look at the source...

> In the case of Axiom, a powerful type system is implemented, based on
> algebraic properties and inheritance is implemented (e.g. rings, fields,
> identities for + or *, polynomials over those base objects, etc.) The
> language Aldor is part of the implementation, also implemented on Lisp.

Very interesting.

> ... But maybe you don't want to count as important, very clever people
> doing very clever things.

The link to the your CGOL source is broken, BTW.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

In article <43372dbe$0$16344$ed2619ec@ptn-nntp-reader01.plus.net>,
 Jon Harrop <usenet@jdh30.plus.com> wrote:

> Ron Garret wrote:
> > In article <43369668$0$49804$ed2e19e4@ptn-nntp-reader04.plus.net>,
> >  Jon Harrop <usenet@jdh30.plus.com> wrote:
> >> Ultimately, how many widely-used modern languages are written on top of
> >> Lisp?
> > 
> > None.  But I presume that the question is rhetorical, and that the point
> > you intended to make was that if it really were easier to implement
> > languages in Lisp then market forces would tend to drive the industry
> > towards implementing more languages in Lisp...
> 
> No, I had no idea if any were. Had there been then it would have been a
> simple killer example to settle the debate.

Yes, but the answer is "none" only because you inserted the (irrelevant) 
qualifier "widely used".  There are many examples of modern languages 
(most of them DSLs) written on top of Lisp.  None of them (to my 
knowledge) are "widely used", at least not in the sense that people who 
pose this (frequently asked) question usually mean it.

> My personal impression is that writing a simple (i.e. slow) interpreter is
> trivial in any modern FPL and writing a good (i.e. fast to compile and
> producing fast executables) native-code compiler is very hard in any
> language.

Your personal impression is wrong.

> Lisp may well be easier for a middle ground, where it is hard to
> achieve reasonable performance by other techniques but there isn't any
> solid evidence either way.

You should be careful not to confuse your personal ignorance with the 
absence of solid evidence.  I know this will come as a shock, but 
burying your head in the sand does not actually make the rest of the 
world disappear.

rg

David Steuber <david@david-steuber.com> writes:
>Static type checking only catches a subset of programming errors
>anyway.

  A part of those errors are "errors" that would not have been
  errors without static type checking, i.e., errors in static
  type declarations.

Jon Harrop <usenet@jdh30.plus.com> writes:

> This raises an interesting question. Of the enormous number of Lisp
> extensions that have been invented over the past few decades, how many of
> them have been widely adopted?

I interpret few as at least three.  So do any of the following count?

* Higher order Functions: They work quite well in Perl and a number of
  other languages.
* CLOS: Perl's OO model looks like a tiny CLOS.
* Closures: Perl has them.
* Lexical scoping: This one may be too old, but it was adopted by Lisp
  and is used in all the programming languages I know.
* Runtime Type Checking:  Java does it inspite of all that static type
  checking stuff.

High level languages in general seem to be moving closer to Lisp than
to Algol except in surface syntax.  Syntax will likely remain Lisp's
killer feature.

Maybe I didn't understand the question.

-- 
http://www.david-steuber.com/
The UnBlog | Lisp on OS X topics for the most part
Click all the links you want.  I'll make more!

In article <433730a8$0$16344$ed2619ec@ptn-nntp-reader01.plus.net>,
 Jon Harrop <usenet@jdh30.plus.com> wrote:

> Ron Garret wrote:
> > That's right.  That's because the ease of implementation arises from a
> > particular collection of language features that Lisp possesses that
> > other languages do not have and cannot have without becoming Lisp.
> 
> You make it sound like a religion. :-)
> 
> >> I wouldn't mind that if it were based upon a proof but it is based upon
> >> an entirely subjective belief (the notion of "vastly easier").
> > 
> > It is neither subjective nor is it a belief.  The effort required to
> > implement something is an objective metric.
> 
> What units do you measure effort in?

Me personally?  LOC, just because it's easy to measure.  But you can use 
works hours, dollars, etc.  It doesn't much matter.

> > It's not particularly easy 
> > to measure with precision, but it can be done.  There are even a few
> > actual data points out there, and lots and lots of anecdotal evidence.
> > Granted, it's not quantum electrodynamics (and cannot be because
> > psychology, economics and politics are involved), but it's not just a
> > "subjective belief" either.
> 
> To a physicist, psychology and politics are subjective belief.

I'm sorry, I must have missed the part where this thread got 
cross-posted to sci.physics.

rg

Charles Hoffman <nothinghappens@mchsi.com> writes:

> Anyway, I find that I do best starting with a small version of a
> language before learning the big version -- Luckily many of the big
> powerful languages are extensions in some sense from smaller ones.
> I've had a much better time of learning C than when I tried to start
> from scratch with C++, and am now having a similar experience with
> Scheme. I'll feel much more confident tackling Common Lisp now.  In
> that spirit, I'd recommend installing DrScheme and working with it for
> a while, working from any of the many excellent books that are
> included in its "Help Desk" feature, or maybe first looking into
> _The_Little_Schemer_, a really unique book that will introduce you to
> what I called above the "mindset" of Scheme starting from the very
> basics.

I'm not familiar with the implementation, but you might also want to
try Scheme48 because Taylor Campbell has added SLIME support for it.
He also has a cool structured editing package called Paredit:

http://mumble.net/~campbell/emacs/paredit.el
http://mumble.net/~campbell/emacs/paredit.html

Paredit is pretty darn cool although it does take a little adjustment
from the line oriented editing approach.

-- 
http://www.david-steuber.com/
The UnBlog | Lisp on OS X topics for the most part
Click all the links you want.  I'll make more!

Ron Garret wrote:

> Yes, and it's trivially easy to build the kind of restriction you seek:
> 
> (in-package :fascist)
> (shadow 'defun)
> (defmacro defun (name args &body body)
>   (if (not (check-for-desired-property args body))
>     (error "Bad code.  Try again.")
>     `(cl:defun ,name, args, @body)))
> 
> 
>>And turning the situation on its head, how easy do you think it is
>>to take a type-checked language and add an "extension" to it that
>>allows code not provably typesafe to be written and run in it?
> 
> 
> I have no idea, but I suspect it's more than six lines of code.

It's a lot more than six lines of code in lisp, as well.
You elided the definition of check-for-desired-property,
you know.

				Bear

In article <pJHZe.266$Aw.4506@typhoon.sonic.net>,
 Ray Dillinger <bear@sonic.net> wrote:

> Ron Garret wrote:
> 
> > Yes, and it's trivially easy to build the kind of restriction you seek:
> > 
> > (in-package :fascist)
> > (shadow 'defun)
> > (defmacro defun (name args &body body)
> >   (if (not (check-for-desired-property args body))
> >     (error "Bad code.  Try again.")
> >     `(cl:defun ,name, args, @body)))
> > 
> > 
> >>And turning the situation on its head, how easy do you think it is
> >>to take a type-checked language and add an "extension" to it that
> >>allows code not provably typesafe to be written and run in it?
> > 
> > 
> > I have no idea, but I suspect it's more than six lines of code.
> 
> It's a lot more than six lines of code in lisp, as well.
> You elided the definition of check-for-desired-property,
> you know.

Of course, but that's irrelevant.  I was responding to your point about 
static-typing people wishing to be constrained from running code that 
could not be proven correct, and I was merely pointing out that *that* 
particular feature (or bug) is trivially added to Lisp, whereas 
performing the converse operation is much harder, and in fact is 
probably impossible without either deep hacking on the implementation, 
or completely embedding an interpreter for a non-fascist [1] language 
within the statically typed language.

Obviously, adding feature X to a language that natively possesses 
feature X requires zero effort.  But that is usually an uninteresting 
observation.

rg

[1] A fascist language is one that will not allow one to even attempt 
execution of a syntactically correct program that cannot be proven 
correct with respect to some additional criterion, usually 
type-correctness.

David Steuber <david@david-steuber.com> writes:

> * CLOS: Perl's OO model looks like a tiny CLOS.

In what way?

Zach

Richard Fateman <fateman@cs.berkeley.edu> writes:
> 
> (a) Tony Hearn's REDUCE.
> (b) IBM (then NAG)'s  Scratchpad (commercialized as AXIOM)
> (c) MIT's (then Symbolics') Macsyma (now mostly used as the sourceforge Maxima system)
> 
> In each case a different language (some infix notation for
> mathematics is part of it), on top of lisp.

BTW, commercial Macsyma also includes a MATLAB->Macsyma translator,
designed for use both by users and libraries.  There was 
also the FORTRAN->Lisp translator which was used to import 
the IMSL libraries.

Ray Dillinger wrote:
> Pascal Costanza wrote:
> 
>> Ray Dillinger wrote:
>>
>>> People who ask for static typing usually want restrictions on what
>>> they can write.  Static-typing proponents typically want to be
>>> prevented from writing even correct code unless their preferred
>>> system can prove that it will not cause a type error.
>>
>> People cannot be prevented from writing "incorrect" code, they can 
>> only be prevented from _running_ "incorrect" code. In a system that 
>> allows them to run "incorrect" code, they could just refrain from 
>> running such code. It escapes me why this needs to be enforced.
> 
> This is mere pedantry.  Stop it; it does not contribute to
> the conversation.

I don't think it's pedantry. If we separate the notion of checking code 
for adherence to some typing rules and preventing non-adhering code from 
running, we can start to think about adding a type checker as a separate 
tool. If the static type checker is a separate tool, we can also start 
to think about domain-specific or programmable static type systems, for 
example.

As I said, a type checker is basically just a function that takes an 
s-expression and yields 'acceptable or 'not-acceptable.

>> The story is of course a little bit different for static type systems 
>> that change the semantics of a program...
> 
> True... but not the subject under discussion, I think.

In such cases, the type checker cannot be a separate tool, I think.


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

(This response is this late because I managed to mark the message read
with nn without actually seeing it.)

>To start with, I have to disagree with the statement that you can do
>more w/ 3 million lines of Lisp/Haskell/(Pick you language) than with
>Java/C.  In my experience, much of the LoC savings of interpretted
>languages comes from the extensive library support, and a briefer
>syntax for many things.  Once you have a couple hundred thousand lines
>of library / toolkit code integrated, the libraries and the syntax get
>closer to the interpretted language.  There is less of an advantage
>then.  Compare using standard C++ to using C++ with boost.

I don't make such a big difference between the "language" and its
"library".  If we take the minimalist approach (as in Scheme), the
"language" is really small and the "library" is most everything else.
So, yes, it takes a good library/language to be really expressive; but
"extensive" is not enough: the library/language has to be well designed. 

Almost anything that really is about the expressiveness of a
language/library can be attributed to "briefer syntax".  Actually,
briefer (but hopefully easy to remember) syntax for useful things is the
best thing a language can provide -- provided that "syntax" means
everything that the user can write; not only language-provided primitive
syntax constructs.  (As it does not make much sense to differentiate
between language and library, it does not make sense to differentiate
between "primitive syntax" and "composite syntax".)  Of course, this
includes quite deep things such as syntax transformers (in C++, they
have to be explicitly marked with template syntax) and lexical scoping
with closures (which requires boilerplate code in C++ and anonymous
subclass tinkering in Java).  So yes, C++ with boost is probably
starting to achieve the expressiveness and brevity of, say, Python (but
not near that of Haskell).

C++ (and Java, to an increasing degree) are remarkable in that they
nowadays _can_ actually be used with relative brevity but it's
remarkably difficult to learn to use them so.  And you have to go
through hoops to integrate your well designed, brief code with
badly-abstracted/evil/stupid third party code.

I have proposed code brevity as a measure of expressiveness of a
language/library (http://c2.com/cgi/wiki?NumberOfKeystrokes).  I'd like
to add a proposal that brevity of the language/library _implementation_
(to achieve some certain level of expressiveness for the user) is a
crucial measure of how well the language/library has been designed.

Jumping out of the "I claim" domain into the domain of "it has been
shown", code brevity is intrinsically bound to both programmer
performance and the ability of people to grasp chunks of code.  It's
true that a guru C++ programmer can produce relatively succinct code and
have a performance comparable to the Lisp coder.  At the same time, it's
also true that your average C++ programmer won't know how to use all
that cool stuff and will spend a lot more time writing a lot longer
program.  While the same phenomenon applies somewhat to Lisp, it does so
to a much lesser degree.  So empirically, your claim doesn't hold:
language/library really affects programmer performance, and much more
so for the programmer who is not an expert in his/her language.
Learning curves for languages vary, too.  Why spend time on learning to
use C++ "almost as well" as Lisp, when you can use Lisp from the
beginning?

>As for project size, the large projects I have been involved with are
[... an elaborate description of the type of software project involved...]
>Communication is vital, and if you end up working a feature with
>someone who doesn't understand how to plug a few systems together
>you're both doomed to schedule hell.

I think the problem is that the current software world (as the project
you describe above) is oriented towards _adaptability_ while it should
be oriented towards _wide applicability_.  Build components that last;
not some specific behaviour of some objects in some specific problem
domain, but all that code that makes the specification of behaviour
easy.  IOW, I think almost all software development should be
language/library design.  (There are some exceptions, such as UI code;
but language/library support should make those pieces of code so small
that they can be rewritten without any _need_ to reuse their parts.)

>when the user clicks "go", six million lines of code will execute
>several times before the output is achieved.  It all needs to have
>people who understand the software and how to integrate it with other
>software to add features and fix problems.

"Integration" is another word that chills down my spine.  Usually it
means, "some component(s) of this system is/are so badly designed that
they have to be changed to fit the rest".

>  I guess maybe the world of shrinkwrap software doesn't have many
>things like this - I've been doing embedded work for a long time (C++
>mostly and sometimes Java).  Maybe the skilled people aren't needed so
>much for desktop or server apps - someone else would have to speak to
>that.  I guess if you don't need the best, could you please hire the
>worst so they stop ending up on my teams! :)  When someone makes a

I think most of the whole commercial software world is doomed, because
they have to do things with people that they happen to hire, not people
who come to the project because they like it and feel confident to
contribute to it.

Panu

-- 
personal contact: atehwa@iki.fi, +35841 5323835, +3589 85619369
work contact: panu.kalliokoski@helsinki.fi, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/

Ron Garret wrote:
> Of course, but that's irrelevant.  I was responding to your point about 
> static-typing people wishing to be constrained from running code that 
> could not be proven correct, and I was merely pointing out that *that* 

And they want the compiler to tell them where they left out an important 
definition or made an error.  I like type-checking as a cheap test suite ;)

> particular feature (or bug) is trivially added to Lisp, whereas 
> performing the converse operation is much harder, and in fact is 

Agreed.  If people do fine without static checking, it's nice to have it 
be optional.

On larger projects I consider typing a good means of documentation, 
however, and DECLARE isn't doing that in a very readable way...
(consider SML signatures or even a Java class signature with documentation)

> probably impossible without either deep hacking on the implementation, 
> or completely embedding an interpreter for a non-fascist [1] language 
> within the statically typed language.

Talking about fascist languages, I have yet to see where Lisp is much 
more open than ML, but I still respect the Lisp way (and prefer it over 
ML in many ways).  The examples I've seen often amount to something 
Java-like: returning some value or list, ar returning nil or null.  Sum 
types aren't rocket science, in whatever language.

> Obviously, adding feature X to a language that natively possesses 
> feature X requires zero effort.  But that is usually an uninteresting 
> observation.
> 
> rg
> 
> [1] A fascist language is one that will not allow one to even attempt 
> execution of a syntactically correct program that cannot be proven 
> correct with respect to some additional criterion, usually 
> type-correctness.

Hm, what you consider fascist (the language requiring you to prove your 
program is runnable), in practice is an invisible effort for me, i.e. 
just a part of the language's syntax.

Is it that much harder to say (let ((:int x 5)) bla) than the same 
without the int?

Anyway, I think this discussion is open, as usual, and will never result 
in anything, be it in a Lisp newsgroup, or a functional/ML one.

-- 
Some people like democracy.  That's because it does whatever the 
majority wants, and because they happen to be part of that majority.
"Do you want the Total War?"

Ulrich Hobelmann <u.hobelmann@web.de> writes:

> Ron Garret wrote:
> > Of course, but that's irrelevant.  I was responding to your point
> > about static-typing people wishing to be constrained from running
> > code that could not be proven correct, and I was merely pointing out
> > that *that*
> 
> And they want the compiler to tell them where they left out an
> important definition or made an error.  I like type-checking as a
> cheap test suite ;)
> 
> > particular feature (or bug) is trivially added to Lisp, whereas
> > performing the converse operation is much harder, and in fact is
> 
> Agreed.  If people do fine without static checking, it's nice to have
> it be optional.
> 
> On larger projects I consider typing a good means of documentation,
> however, and DECLARE isn't doing that in a very readable way...
> (consider SML signatures or even a Java class signature with documentation)
> 
> > probably impossible without either deep hacking on the
> > implementation, or completely embedding an interpreter for a
> > non-fascist [1] language within the statically typed language.
> 
> Talking about fascist languages, I have yet to see where Lisp is much
> more open than ML, but I still respect the Lisp way (and prefer it
> over ML in many ways).  The examples I've seen often amount to
> something Java-like: returning some value or list, ar returning nil or
> null.  Sum types aren't rocket science, in whatever language.
> 
> > Obviously, adding feature X to a language that natively possesses
> > feature X requires zero effort.  But that is usually an
> > uninteresting observation.
> > rg
> > [1] A fascist language is one that will not allow one to even
> > attempt execution of a syntactically correct program that cannot be
> > proven correct with respect to some additional criterion, usually
> > type-correctness.
> 
> Hm, what you consider fascist (the language requiring you to prove
> your program is runnable), in practice is an invisible effort for me,
> i.e. just a part of the language's syntax.
> 
> Is it that much harder to say (let ((:int x 5)) bla) than the same
> without the int?

What about when you want to change all occurances of that
to a different type?  What about when you don't know ahead
of time what the abstract taxonomy should be, and it keeps
changing as you revise your ideas of how to write the program?

David Steuber wrote:

> * Higher order Functions: They work quite well in Perl and a number of
>   other languages.
> * CLOS: Perl's OO model looks like a tiny CLOS.
> * Closures: Perl has them.
> * Lexical scoping: This one may be too old, but it was adopted by Lisp
>   and is used in all the programming languages I know.
> * Runtime Type Checking:  Java does it inspite of all that static type
>   checking stuff.

When people are going to count Lisp as an old lady they often do not
have any experience in functional programming language paradigms. I
think the original poster confused two things: a) the language itself
b) the environment. It is clear that Java, C++, etc. often comes with a
full fledged programming environment which goes far beyond Emacs+Common
Lisp.

I am also in the believing that the original poster had put OCaml,
Haskell, etc. into the old featured stone age realm since the tools are
often not as well shaped as under Java.

One must also understand that often for computer scientists the
language is a tool and they are paid for developing new paradigms. The
programmer on the other side sees always only this fulld fledged
environment monster.

Schneewittchen
PS: It is interesting that nobody says that Scheme is from the stone
age.

Kris Cipa wrote:

> than coding in raw syntactic representation!
> And of course there's tons of other issue, you can imagine what: the
> braindead naming conventions: either cryptic like lambda, car, cdr,
> cdaadr, princ and company, or long winded verbosities like
> call-with-current-continuation or multiple-value-bind; the almost total
> lack of useful libraries or IDEs, the list just goes on.

It sounds you do not have any experience in functional language
paradigms. It would be better for your arguing position if you had one
since then you are more obliged to deride Common Lisp from a modern
perspective/stand-point.

A cool advice: invest a couple of month into lets say: Clean, or OCaml,
or Haskell and then again comment on whether Common Lisp is old crap.

Schneewittchen
PS: Btw: what in hell does a long name, e.g.
call-with-current-continuations all have in common with stone age - he?
You would have called Common Lisp modern if it had used e.g. "cwc" for
call-with-current-continuations - haven't you?

Christopher C. Stacy wrote:
>> Is it that much harder to say (let ((:int x 5)) bla) than the same
>> without the int?
> 
> What about when you want to change all occurances of that
> to a different type?  What about when you don't know ahead

I think you'd rarely change the type a given value has.  If you have 
more complex values (OO-style), then programming to interfaces helps 
(call it a collection of generic methods).

I can see why you find this annoying, but sometimes I think it's worth 
the tradeoff.  Matter of taste.

> of time what the abstract taxonomy should be, and it keeps
> changing as you revise your ideas of how to write the program?

Yes, prototyping/RAD is where dynamically typed languages shine...

-- 
Some people like democracy.  That's because it does whatever the 
majority wants, and because they happen to be part of that majority.
"Do you want the Total War?"

Matthias Buelow asks
> How do you ("easily") implement a polymorphic type system
> for Common Lisp (e.g., Hindley-Milner style), within
> Common Lisp (or any other well-known Lisp, such as Scheme)
> so that you can make any Common Lisp (or Scheme, ...)
> program be statically type checked?

Hindley-Milner was in my intray for a while. I programmed in
Pascal many years ago, so I know the pain of static type
checking. Then I came across articles saying that modern
static type systems were not like that. You do not have
automatic coercions, which means that the compiler can
follow the types all through your code, starting from the
initialisation data, and you ended up needing hardly any
type declarations. Very interesting.

Could one do that in CL by wrapping forms in a code walking
macro? The kind of programming involved, recursing over a
parse tree, is something Lisp excels at. 

However, there is a problem. The question of whether it is
worth the effort depends both on how hard it is to do, and
on what that effort buys you.

Hindley-Milner has been bumped from my intray by Test Driven
Development. Why would I want to write

(defun (integer my-add) ((integer x)(integer y))(* x y))

and have the compiler tell me that my code type checks, when
I could be typing

(defun my-add (x y)
  :test ((0 0) 0
         (2 2) 4
         (0 1) 1
         (1 1) 2)
  (* x y))

and have the compiler tell me 

Test failure in my-add
Test (my-add 0 1)
Desired 1
Actual 0

Since type errors will not lead to correct answers, Test
Driven Development makes static typing obsolete. So asking
how to add Hindley-Milner to CL so that programs can be
statically type checked is a bit like asking how to add
line numbers to CL to make it more like BASIC: the fact that
people are not doing it might be because it is not worth
doing.

If it is not worth doing, it doesn't matter if it is hard to
do in Lisp. Indeed, decisions in computer language
design involve trade-offs. One expects things that are not
worth doing to be hard because the ability to do them got
sacrificed to enhance the language's capabilities in more
profitable directions.

Alan Crowe
Edinburgh
Scotland

Alan Crowe wrote:
> Hindley-Milner has been bumped from my intray by Test Driven
> Development. Why would I want to write
> 
> (defun (integer my-add) ((integer x)(integer y))(* x y))
> 
> and have the compiler tell me that my code type checks, when
> I could be typing
> 
> (defun my-add (x y)
>   :test ((0 0) 0
>          (2 2) 4
>          (0 1) 1
>          (1 1) 2)
>   (* x y))
> 
> and have the compiler tell me 
> 
> Test failure in my-add
> Test (my-add 0 1)
> Desired 1
> Actual 0

Because you only approximate correctness by checking some values.  Type 
checking guarantees that your code will never be called with invalid 
values (because in ML a type can only have a number of declared values, 
such as datatype color = red | green | blue), and that your code handles 
those values correctly.  You won't need to test for strange values (that 
might crash a Lisp function that isn't expecting them), because they 
will NEVER be given as parameters.

Of course for other classes of errors you still need testing.

> Since type errors will not lead to correct answers, Test
> Driven Development makes static typing obsolete. So asking

I think Bruce Eckel said this before, but I don't completely buy it. 
Sure, in practice testing with a dynamic language is fine, but that 
doesn't mean that static checking isn't cool or useful in many cases.

> how to add Hindley-Milner to CL so that programs can be
> statically type checked is a bit like asking how to add
> line numbers to CL to make it more like BASIC: the fact that
> people are not doing it might be because it is not worth
> doing.

Don't CMUCL and SBCL do something like that (if only for more efficient 
compilation)?

> If it is not worth doing, it doesn't matter if it is hard to
> do in Lisp. Indeed, decisions in computer language
> design involve trade-offs. One expects things that are not
> worth doing to be hard because the ability to do them got
> sacrificed to enhance the language's capabilities in more
> profitable directions.

Maybe.  I think ML with Lisp syntax would be cool as well (hell, I 
should just do that sometime).

-- 
Some people like democracy.  That's because it does whatever the 
majority wants, and because they happen to be part of that majority.
"Do you want the Total War?"

Matthias Buelow frightened me by writing:
> I don't know why it seems to be difficult to understand
> that for some application domains you'd need the compiler
> to do as much work as possible to avoid any kind of
> runtime error (and that implies static type checking),
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> while for other domains it might be more beneficial to use
> a more dynamic approach.

> Everything where human life or expensive property is at
> risk would fall into the earlier domain (say, control
> software for a nuclear reactor, the fly-by-wire software
> of aircraft, car electronics).

Static type checking is the 2nd feeblest possible kind of
checking, just better than not bothering at all. It tells
you that values belong to the set from which code was
intended to select them, but not that it picked the correct
one.

Static type checking tells me that compute-control-rod-motion
returns something belonging to the control-rod-motion type,
but not whether it moves the control rod in or out. I still
need to test whether the motions are in the correct
direction and of the correct amount.

What kind of type error would survive such testing? This is
not a rhetorical question. We know how a type error can slip
through testing: when there are paths in the code that are
not exercised. So here is the scenario:

There is a path in the reactor control software that has not
been tested. If we used a dynamically typed language we
might get a type error at run time, which might trigger the
emergency shut down. If we had used a statically typed
language we would not get type error.  Either way is really
scary. If we haven't tested that path through the code, then
the control software might be pulling the control out when
it is supposed to be pushing it in. If you didn't test it,
it doesn't work.

Static typing might be OK for crappy consumer software. If
fast forward makes your video recorder rewind, then you can
probably work around it by using fast rewind to fast
forward. Bugs, yeah, they happen.

Writing high integrity software implies going so far beyond
what static typing can offer that static type offer no
techical benefit.  The impact of static typing is purely
psychological: the code compiles, so it is half way to being
correct. Since it is human nature to feel that half a loaf
is better than none, this psychological aspect undermines
safety.

Alan Crowe
Edinburgh
Scotland

Alan Crowe wrote:
> If it is not worth doing, it doesn't matter if it is hard to
> do in Lisp...

On the basis of that argument, there is no need to prove anything correct.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Stefan Ram wrote:
>   A part of those errors are "errors" that would not have been
>   errors without static type checking, i.e., errors in static
>   type declarations.

An incorrect type declaration is an error. It will be caught by a static
type checker or a dynamic one.

Also, in the presence of type inference, there are few type declarations
(usually only definitions).

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Alan Crowe wrote:
> Static type checking tells me that compute-control-rod-motion
> returns something belonging to the control-rod-motion type,
> but not whether it moves the control rod in or out. I still
> need to test whether the motions are in the correct
> direction and of the correct amount.
> ...

Look up phantom types and more sophisticated type systems.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Christopher C. Stacy wrote:
> What about when you want to change all occurances of that
> to a different type?

Use a language with type inference. It will infer the new type without you
having to specify it.

> What about when you don't know ahead 
> of time what the abstract taxonomy should be, and it keeps
> changing as you revise your ideas of how to write the program?

If the program remains type safe then it will compile and run correctly. If
the program is not type safe, the compiler will point out all of the type
errors and you must correct them before you can run the program.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Ron Garret wrote:
> In article <43372dbe$0$16344$ed2619ec@ptn-nntp-reader01.plus.net>,
>  Jon Harrop <usenet@jdh30.plus.com> wrote:
>> No, I had no idea if any were. Had there been then it would have been a
>> simple killer example to settle the debate.
> 
> Yes, but the answer is "none" only because you inserted the (irrelevant)
> qualifier "widely used".  There are many examples of modern languages
> (most of them DSLs) written on top of Lisp.  None of them (to my
> knowledge) are "widely used", at least not in the sense that people who
> pose this (frequently asked) question usually mean it.

Other people have offered a Javascript implementation, REDUCE and Macsyma.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jon Harrop wrote:

> Ron Garret wrote:
> 
>>In article <43372dbe$0$16344$ed2619ec@ptn-nntp-reader01.plus.net>,
>> Jon Harrop <usenet@jdh30.plus.com> wrote:
>>
>>>No, I had no idea if any were. Had there been then it would have been a
>>>simple killer example to settle the debate.
>>
>>Yes, but the answer is "none" only because you inserted the (irrelevant)
>>qualifier "widely used".  There are many examples of modern languages
>>(most of them DSLs) written on top of Lisp.  None of them (to my
>>knowledge) are "widely used", at least not in the sense that people who
>>pose this (frequently asked) question usually mean it.
> 
> 
> Other people have offered a Javascript implementation, REDUCE and Macsyma.
> 
And also Prolog.  So Jon, why don't you just admit that Lisp has
been shown, repeatedly, to be a good
language for building implementations of other languages, and go
troll on some other newsgroup.

Jon Harrop <usenet@jdh30.plus.com> writes:

> Christopher C. Stacy wrote:
> > What about when you want to change all occurances of that
> > to a different type?
> 
> Use a language with type inference. It will infer the new type without you
> having to specify it.
> 
> > What about when you don't know ahead 
> > of time what the abstract taxonomy should be, and it keeps
> > changing as you revise your ideas of how to write the program?
> 
> If the program remains type safe then it will compile and run correctly. If
> the program is not type safe, the compiler will point out all of the type
> errors and you must correct them before you can run the program.

It's like talking to a brick troll...

Jon Harrop <usenet@jdh30.plus.com> writes:
> Ultimately, how many widely-used modern languages are
> written on top of Lisp?

If you're just looking for a laundry list of languages
that have been ("easily") implemented in Lisp, you can 
also add Fortran, ANSI C, Pascal, ADA, and Prolog.

(I don't know what you mean by "modern language", though.
Not that I think you're anything but a random troll, anyway...)

Jon Harrop wrote:

> If the program is not type safe, the compiler will point out all of
> the type errors and you must correct them before you can run the
> program.

....without being able to run the program to see why it actually is not 
considered "type safe".


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

M Jared Finder wrote:
> ...

Great post! :-)

> 6. The language is (usually) natively compiled.  Code is output that is
>     fast and small.

One niggle - "fast" is only meaningful in comparison. Lisp is probably much
faster than similarly dynamic languages like Python, not that I have any
evidence to back that up...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Pascal Costanza wrote:
> Jon Harrop wrote:
>> If the program is not type safe, the compiler will point out all of
>> the type errors and you must correct them before you can run the
>> program.
> 
> ...without being able to run the program to see why it actually is not
> considered "type safe".

I can't think of any examples where it would be useful to run a type unsafe
program. Can you elaborate?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Christopher C. Stacy wrote:
> Jon Harrop <usenet@jdh30.plus.com> writes:
>> Ultimately, how many widely-used modern languages are
>> written on top of Lisp?
> 
> If you're just looking for a laundry list of languages
> that have been ("easily") implemented in Lisp, you can
> also add Fortran, ANSI C, Pascal, ADA, and Prolog.

Ok, I'm checking out Fortran and Prolog. Can you give more specific
citations for Pascal and Ada?

There is already a Pascal implementation in OCaml, IIRC, which would make
for an easy comparison. :-)

> (I don't know what you mean by "modern language", though.

I just meant something that did die twenty years ago. :-)

Most of the examples so far have been great but I've yet to find any code to
download, let alone code that works.

Do any of these links work for you:

  ftp://cs.utah.edu/pub/
  ftp://unix.sri.com/pub/norvig/
  ftp://endor.harvard.edu/pub/

I've a feeling its my net connection that's the problem...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jon Harrop wrote:
> Pascal Costanza wrote:
> 
>>Jon Harrop wrote:
>>
>>>If the program is not type safe, the compiler will point out all of
>>>the type errors and you must correct them before you can run the
>>>program.
>>
>>...without being able to run the program to see why it actually is not
>>considered "type safe".
> 
> I can't think of any examples where it would be useful to run a type unsafe
> program. Can you elaborate?

Assume that you have a complex program and have no idea why a value of 
an incorrect type could possibly arrive at the place where the type 
checker issues an type error. It might be useful to track down what 
happens just before this occurs.

I am not making this up. Eclipse has added this as a feature to its 
integrated Java compiler, so you are allowed to run a program in debug 
mode even if the type checker doesn't accept it. Apparently, people want 
this.

See also the example about implementing interfaces in my paper about 
dynamic vs. static type systems at http://p-cos.net/documents/dynatype.pdf


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

"Kris Cipa" <kristinacipa@yahoo.co.nz> writes:

> justinhj wrote:
> > I don't know if I'm typical but my first experience of lisp was in an
> > introductory AI programming course, where lisp was the topic for a
> > couple of weeks. In that short time all we learned was about lambda
> > expressions and their relation to lisp. After that we did some things
> > with lists and that was it. The rest of undergraduate level AI was done
> > in Prolog.
> >
> > >From that kind of introduction by someone who doesn't really know lisp,
> > you're not going to develop much enthusiasm, and I didn't.
> 
> It is not so much that the course was taught badly - I think it was
> fine as far as it goes. It is just that the programming language itself
> feels so klunky and basic.
> Actually it reminded me of my days coding in BASIC on a Spectrum as a
> kid: in both cases you have to go through hoops to make the compiler
> happy rather than the compiler making things easy for you. I mean
> there's something called parsers, they've been around for years, so why
> does the user have to use raw AST to write programs in Lisp? Just like
> in old BASICs where you had to number your lines so interpreter can
> execute them in the correct order.
> 
> Apparently it's so you can obfuscate the code with macros, but come on,
> even if you really wanted those (I don't) there must be a better way
> than coding in raw syntactic representation!
> And of course there's tons of other issue, you can imagine what: the
> braindead naming conventions: either cryptic like lambda, car, cdr,
> cdaadr, princ and company, or long winded verbosities like
> call-with-current-continuation or multiple-value-bind; the almost total
> lack of useful libraries or IDEs, the list just goes on.
> 
> >From reading the advocay pages I was pointed to etc it seems like
> people are into lisp for totally non-technical reasons: they all saw
> the light and never went back, they   have secret knowledge that others
> lack etc.  It seems more of a cult than a programming language
> community.
> So I still don't get what the real technical advantages are.
> --
> Kris

Seriously, go away.  You are wasting your time and ours.

Ulrich Hobelmann wrote:
> > Why would I want to write
> > 
> > (defun (integer my-add) ((integer x)(integer y))(* x y))
> > 
> > and have the compiler tell me that my code type checks, when
> > I could be typing
> >
> > (defun my-add (x y)
> >   :test ((0 0) 0
> >          (2 2) 4
> >          (0 1) 1
> >          (1 1) 2)
> >   (* x y))
> > 
> > and have the compiler tell me 
> > 
> > Test failure in my-add
> > Test (my-add 0 1)
> > Desired 1
> > Actual 0
>
> Because you only approximate correctness by checking some values.

I agree that static type checking checks infinitely many
values, while typing in some test cases only check a (small)
finite number of cases. It is easy to be carried away by the
magic of infinity, but I don't think that this is as
important as it at first appears, even in theory.

For a theorectical example imagine that you want to compute
(x+1)^2 but for some reason have transformed it to x^2+2x+1.
Is the transformed version correct? Perhaps your algebra foo
is weak, so you go to the REPL and type

* (dotimes (x 5)
    (print (- (expt (+ x 1) 2)
	      (+ (* x x)
		 (* 2 x)
		 1))))
0 
0 
0 
0 
0 
NIL

Well you have only done 5 cases out of infinity. It hardly
proves that the code is correct.

Wait a minute. That form is only of degree two. It cannot
have five zeros. It must be indentically zero, which
/proves/ that the transformation is correct.  So, with a
sprinklying of magic theorem pixie dust, checking a few
values provides a proof for infinitely many values.

We could coin a slogan: structure + examples = proof

To get back to code, imagine that the client is only happy
with 2 digit numbers, and wants larger answers as a string
in words.

(defun my-add (x y)
  :test ((0 0) 0
         (2 2) 4
         (0 1) 1
         (1 1) 2
	 (66 33) 99
	 (60 40) "one hundred"
	 (100 1) "one hundred one")
  (let ((total (+ x y)))
       (if (>= total 100)
	   (format nil "~R" total)
	 total)))

Now we have 7 test cases. Look at the structure of the
code. It has two branches. One branch returns an integer,
the other branch returns a string. If the arg type is
integer x integer then the return type is (or integer
string)

Now look at the test cases. Obviously the return type must
be a supertype of (or integer string) since we have both
integers and strings, but if we have 100% coverage of the
branches in the code, (easily checked) then we know that
that is exactly the return type, even though we have only
checked 7 of infinitely many cases. Again structure +
examples = proof.

Please permit me to be pedantic for a moment and pick up on
a slip in wording

     Because you only approximate correctness by checking some
				  ^^^^^^^
     values.  Type checking guarantees that your code will never
     be called with invalid values (because in ML a type can only
     have a number of declared values, such as datatype color =
     red | green | blue), and that your code handles those values
     correctly.
     ^^^^^^^

Notice that the meaning of ``correct'' is jumping
about. First it is about getting the correct value. Then it
is about getting the correct type, a much weaker notion of
correctness. This worries me. People talk confidently about
the need for static typing, and I worry that I'm missing out
on something important. On the other hand, this is not the
first time I've spotted the meaning of ``correct'' jumping.
How much of the enthusiasm for static typing comes from
sloppy thinking that conflates the two meanings of correct?

Imagine that there is a distinct jargon term, plocktal, to
use when code passes static type checks. It is much harder
to explain the merits of plocktal code without the benefit of
the warm, fuzzy feeling that comes with using the word
correct.

Using the word ``correct'' with two different meanings makes
certain thoughts hard to express. You can hardly write
``correct code is often incorrect'', yet the point that
``plocktal code is often incorrect'' is crucial and means
exactly the same.

Alan Crowe
Edinburgh
Scotland

Pascal Costanza wrote:
> Assume that you have a complex program and have no idea why a value of
> an incorrect type could possibly arrive at the place where the type
> checker issues an type error. It might be useful to track down what
> happens just before this occurs. 

Right. That's what I thought you meant. From my point of view, there are no
values in the target program during static type checking, so "...a value of
an incorrect type..." doesn't make sense.

I would say that you want to know "what type unifications happened prior to
the type error".

> I am not making this up.

Yes. This is certainly a valid point about static type checking,
particularly with type inference. In OCaml, most programmers use emacs'
Tuareg mode, which allows you to see the inferred type of an expression
with C-T.

This is probably the main hindrance to learning a statically typed language
- you need to know something about type inference and type checking in
order to interpret the error messages and fix your program.

> Eclipse has added this as a feature to its 
> integrated Java compiler, so you are allowed to run a program in debug
> mode even if the type checker doesn't accept it. Apparently, people want
> this.
>
> See also the example about implementing interfaces in my paper about
> dynamic vs. static type systems at http://p-cos.net/documents/dynatype.pdf

I was surprised that this would be needed in Java but looking at the
examples in your paper I'd just forgotten how hairy Java code looks. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

In article <1127562651.691220.257500@f14g2000cwb.googlegroups.com>,
Kris Cipa <kristinacipa@yahoo.co.nz> wrote:
>justinhj wrote:
>> I don't know if I'm typical but my first experience of lisp was in an
>> introductory AI programming course, where lisp was the topic for a
>> couple of weeks. In that short time all we learned was about lambda
>> expressions and their relation to lisp. After that we did some things
>> with lists and that was it. The rest of undergraduate level AI was done
>> in Prolog.
>>
>> >From that kind of introduction by someone who doesn't really know lisp,
>> you're not going to develop much enthusiasm, and I didn't.
>
>It is not so much that the course was taught badly - I think it was
>fine as far as it goes. It is just that the programming language itself
>feels so klunky and basic.
>Actually it reminded me of my days coding in BASIC on a Spectrum as a
>kid: in both cases you have to go through hoops to make the compiler
>happy rather than the compiler making things easy for you. I mean
>there's something called parsers, they've been around for years, so why
>does the user have to use raw AST to write programs in Lisp? Just like
>in old BASICs where you had to number your lines so interpreter can
>execute them in the correct order.
>
>Apparently it's so you can obfuscate the code with macros

It's the opposite.
Can you explain why *functions* don't obfuscate your code?

>, but come on,
>even if you really wanted those (I don't) there must be a better way
>than coding in raw syntactic representation!

First, what's so raw about it? Others here have pointed out, e.g., that
 "a.m(b)" versus "(m a b)" has the same number of parentheses, and even
 an extra ".".

Second, you contradict yourself: you don't want "raw" syntax, but reject
 a feature (macros) that allow you to produce non-"raw" syntactic forms.

>And of course there's tons of other issue, you can imagine what: the
>braindead naming conventions: either cryptic like lambda, car, cdr,
>cdaadr, princ and company, or long winded verbosities like
>call-with-current-continuation or multiple-value-bind;

In Scheme (and there is a similar way in lisp), if I don't like car or cdr:

  (define first car)
  (define rest cdr)
  (first '(1 2 3)) => 1
  (rest '(1 2 3)) => (2 3)

As for lambda, does your favorite language even have it?
If so, can you use another name for it? In Scheme (also quite doable in Lisp):

  (define-syntax function
    (syntax-rules ()
      ((function a ...) (lambda a ...))))

Now "function" can be used instead of "lambda".

Gary Baumgartner

> the almost total
>lack of useful libraries or IDEs, the list just goes on.
>
>>From reading the advocay pages I was pointed to etc it seems like
>people are into lisp for totally non-technical reasons: they all saw
>the light and never went back, they   have secret knowledge that others
>lack etc.  It seems more of a cult than a programming language
>community.
>So I still don't get what the real technical advantages are.
>--
>Kris
>

Pascal Costanza wrote:
> Jon Harrop wrote:
> 
>> If the program is not type safe, the compiler will point out all of
>> the type errors and you must correct them before you can run the
>> program.
> 
> ...without being able to run the program to see why it actually is not 
> considered "type safe".

In practice it's not that bad at all.  As the checking is purely static 
you can always see what's wrong.  An example is a function returning a 
list in one case, and a number in another case.  Yes, dependent types 
can allow this kind of code, but I've never seen an example that really 
needed it.

The compiler tells you what statical value collides with which function 
return type, and it's easy to fix that.  In the case of ML (i.e. 
inferred, not explicit types) this is interestingly non-intrusive.

-- 
Some people like democracy.  That's because it does whatever the 
majority wants, and because they happen to be part of that majority.
"Do you want the Total War?"

Jon Harrop wrote:
> M Jared Finder wrote:
>> ...
> 
> Great post! :-)
> 
>> 6. The language is (usually) natively compiled.  Code is output that is
>>     fast and small.
> 
> One niggle - "fast" is only meaningful in comparison. Lisp is probably much
> faster than similarly dynamic languages like Python, not that I have any
> evidence to back that up...

Lisp isn't, but the Python compiler (in CMUCL) might be much faster than 
the standard Python interpreter, or than Psyco.

-- 
Some people like democracy.  That's because it does whatever the 
majority wants, and because they happen to be part of that majority.
"Do you want the Total War?"

Jon Harrop wrote:
> Pascal Costanza wrote:
> 
>>Assume that you have a complex program and have no idea why a value of
>>an incorrect type could possibly arrive at the place where the type
>>checker issues an type error. It might be useful to track down what
>>happens just before this occurs. 
> 
> Right. That's what I thought you meant. From my point of view, there are no
> values in the target program during static type checking, so "...a value of
> an incorrect type..." doesn't make sense.

You misunderstood. I actually meant running the program. As in "type 
checker says no, I run the program anyway, maybe I will get an idea 
what's going on".


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

Jon Harrop <usenet@jdh30.plus.com> writes:

> I can't think of any examples where it would be useful to run a type
> unsafe program. Can you elaborate?

Let's say I want to change the representation of some data, but not
have to update 673 different places in the code where the data
representation is used before I try it out for one simple case.

For example, some chunk of data used to be a symbol, but no I want it
either to be a symbol or a cons pair containing a symbol and a string.

-russ

Ulrich Hobelmann wrote:
> Pascal Costanza wrote:
> 
>> Jon Harrop wrote:
>>
>>> If the program is not type safe, the compiler will point out all of
>>> the type errors and you must correct them before you can run the
>>> program.
>>
>> ...without being able to run the program to see why it actually is not 
>> considered "type safe".
> 
> In practice it's not that bad at all.  As the checking is purely static 
> you can always see what's wrong.  An example is a function returning a 
> list in one case, and a number in another case.  Yes, dependent types 
> can allow this kind of code, but I've never seen an example that really 
> needed it.

I know this is a deviation from the course of the discussion, but here 
is an example of a program that wouldn't satisfy a static type checker, 
but is correct anyway:

(defclass person ()
   ((name :initarg :name
          :accessor person-name)))

(defparameter *pascal*
   (make-instance 'person :name "Pascal"))

(defparameter *to-eval*
   '(defclass person ()
      ((name :initarg :name
             :accessor person-name)
       (address :initarg :address
                :accessor person-address))))

(eval *to-eval*)

(setf (person-address *pascal*) "Brussels")

The important part here is that eval is used to evaluate a conceptually 
arbitrary s-expression. In this example, a type checker may have a 
chance to detect that the expression passed to eval is a variable bound 
to a literal expression that wasn't changed, so it could use the same 
type rules as with a direct expression. But in general, the parameter to 
eval could be an arbitrary expression, and it's easy to turn this 
program into something that is not checkable.

Yet the access to the address of *pascal* is correct.

I don't want to suggest that this use of eval is good programming style, 
this is just for illustration purposes. However, there are various more 
"sound" ways to manipulate the meta-level of a Lisp program, foremostly 
by using macros and also by using the CLOS Metaobject Protocol. 
Actually, in my research, I am doing these things quite often. That's 
why it is particularly (and comparatively) easy to implement language 
extensions like AspectL and ContextL.

So one answer to the question what's so great about Lisp is that it 
allows you to fiddle with the meta-level in ways that yield useful 
language extensions.

Being able to extend the language to suit your needs is such a powerful 
tool, it shouldn't be restricted from ordinary programmers. ;)



Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

Alan Crowe wrote:

>      Because you only approximate correctness by checking some
> 				  ^^^^^^^
>      values.  Type checking guarantees that your code will never
>      be called with invalid values (because in ML a type can only
>      have a number of declared values, such as datatype color =
>      red | green | blue), and that your code handles those values
>      correctly.
>      ^^^^^^^
> 
> Notice that the meaning of ``correct'' is jumping
> about. First it is about getting the correct value. Then it
> is about getting the correct type, a much weaker notion of
> correctness. This worries me.

Especially when it is used in conjunction with languages that provide 
types called "integers" that wrap around when you increment them above a 
certain value, and that still yield "integers" when you divide an odd 
exemplar of that type by 2. Correct values don't seem to matter much in 
such languages... ;)


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

justinhj wrote:
> cdr and car actually have quite useful properties in that they are
> short and they can be combined into caddr, caaddr etc which you cannot
> do with the more expressive names 'first' or 'rest'.

If I were sent back in time to help with the first design of Lisp, I
would recommend using |first| and |rest| abbreviated as |fst| and |rst|
and make the substitutions |frrst| for |caddr|, |ffrrst| for |caaddr|,
etc.

If I could put one trivial change to the original design of Scheme, I
would say that all the arrows are backwards.  Change |number->string|
to |string<-number| and change all similar names like |from->to| to
|to<-from|.  Then they will compose properly like (vector<-list
(list<-string (string<-number n))) to get a vector of characters from a
number.

But here I am stuck in the present, and all I can do is post pointless
rants in boring threads of little noticed newsgroups, too late to have
any effect.

  -- Programmer in Chief

On 2005-09-26, Jon Harrop <usenet@jdh30.plus.com> wrote:
> I can't think of any examples where it would be useful to run a type unsafe
> program. Can you elaborate?

A multiplayer networked game where the code is actively being patched,
as has been mentioned in this thread before.  One thing I have played
with a little recently is having graceful failures when a client
accidentally hits a bit of code that is in flux.  It's not too hard to
do in lisp, given the very nice system of restarts and so on.  I've also
been impressed with the effect keyword arguments have on the stability
of a dynamically changing system like this.

Cheers.

-- 
Julian Squires

tichy wrote:
> 'Cipa' means 'pussy' in Polish... Maybe Kris & A.L. are the same
> persons ?

OK so my surname means pussy in some obscure language. What's your
point exactly? For all you know you surname could mean "obtuse moron"
in Maori. How is that relevant?
--
Kristina Pussy, thank you very much.

["Followup-To:" header set to comp.lang.scheme.]

tichy wrote:
>> 'Cipa' means 'pussy' in Polish...

Kris Cipa <kristinacipa@yahoo.co.nz> wrote:
> OK so my surname means pussy in some obscure language ....

Polish is "obscure"? If it weren't for the .co.nz in your address, I'd
guess you were American!
-- 
Bradd W. Szonye
http://www.szonye.com/bradd

On 2005-09-26, Jon Harrop <usenet@jdh30.plus.com> wrote:
> Most of the examples so far have been great but I've yet to find any code to
> download, let alone code that works.
>
> Do any of these links work for you:

Do any of these links work for you?

http://www.norvig.com/
http://www.cliki.net/
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/lang/lisp/0.html
    (which includes the Yale Haskell implementation)
http://www.alu.org/

This one should be of special interest, although I guess it should be
considered as a dead link:

http://web.archive.org/web/20041026002128/http://www.spies.com/~aek/explorer/zeta-c/ZETA-C-PD.tgz

Poplog might be worth checking out, too.

Cheers.

-- 
Julian Squires

Kenny Tilton napisał(a):
> 
> 
> tichy wrote:
> what does kristina mean?

It's a name.

English Kristina == Polish Krystyna

> googling kristina-cipa picks up some polish 
> porn sites.

:-)


-- 
Pozdrawiam,
Rafal Strzalinski (nabla)

Julian Squires wrote:
> On 2005-09-26, Jon Harrop <usenet@jdh30.plus.com> wrote:
>> I can't think of any examples where it would be useful to run a type
>> unsafe program. Can you elaborate?
> 
> A multiplayer networked game where the code is actively being patched,
> as has been mentioned in this thread before.  One thing I have played
> with a little recently is having graceful failures when a client
> accidentally hits a bit of code that is in flux.  It's not too hard to
> do in lisp, given the very nice system of restarts and so on.  I've also
> been impressed with the effect keyword arguments have on the stability
> of a dynamically changing system like this.

Right. If I were going to do that in a statically typed language then I'd
start by implementing dynamic type checking...

I did something not entirely dissimilar in OCaml recently. OCaml has
marshalling but it is type unsafe, i.e. you can marshal data between
different types to cause a segfault. If you want to do marshalling in
production code then that isn't good enough so you have to write I/O
functions for each type and implement dynamic type checking in the code.

So that is asymptotically worse in OCaml than in Lisp.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Pascal Costanza wrote:
> You misunderstood. I actually meant running the program. As in "type
> checker says no, I run the program anyway, maybe I will get an idea
> what's going on".

If we're talking about a type error in the context of a given type system
then running the program will not give you any additional type information.

If we're talking about a type error in the wider sense of the term (i.e. a
type error that lies outside the type system of the statically typed
language) then the program will pass the type checker and you can obtain
results just as you would in a dynamically typed language.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Russell McManus wrote:
> Jon Harrop <usenet@jdh30.plus.com> writes:
>> I can't think of any examples where it would be useful to run a type
>> unsafe program. Can you elaborate?
> 
> Let's say I want to change the representation of some data, but not
> have to update 673 different places in the code where the data
> representation is used before I try it out for one simple case.
> 
> For example, some chunk of data used to be a symbol, but no I want it
> either to be a symbol or a cons pair containing a symbol and a string.

Well, I can think of examples where I've had to change several occurrences
of a piece of code having tweaked something fundamental. However, I can't
see how running the broken program could have been useful.

For example, I recently wrote a mini-interpreter in OCaml. Initially, I
represented symbols as strings. Then I changed the representation of
symbols to integers. This required me to change lots of code. Specifically:

  | Seq (Sym "Plus", [Int i; Int j]) -> Int (i + j)

would be changed to:

  | Seq (Sym plusq, [Int i; Int j]) when plusq = plus -> Int (i + j)

As you can imagine, that appeared a lot and is quite tedious to change.

But without changing those occurrences, the program is fundamentally broken.
In a dynamically typed language, you could run the program but it would
just give you a run-time type error. You can, of course, run the correctly
typed parts of the program.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Julian Squires wrote:
> On 2005-09-26, Jon Harrop <usenet@jdh30.plus.com> wrote:
>> Most of the examples so far have been great but I've yet to find any code
>> to download, let alone code that works.
>>
>> Do any of these links work for you:
> 
> Do any of these links work for you?
> 
> http://www.norvig.com/

I've downloaded the source to his book from that page, thanks.

> http://www.cliki.net/
> http://www.alu.org/

Should come in handy. :-)

http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/lang/lisp/0.html
>     (which includes the Yale Haskell implementation)

Most of the links on that page seem to be dead.

> This one should be of special interest, although I guess it should be
> considered as a dead link:
> 
>
http://web.archive.org/web/20041026002128/http://www.spies.com/~aek/explorer/zeta-c/ZETA-C-PD.tgz

I can't get that one to download either...

> Poplog might be worth checking out, too.

I'll check it out. Thanks!

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jon Harrop <usenet@jdh30.plus.com> writes:

> If the program remains type safe then it will compile and run correctly. If
> the program is not type safe, the compiler will point out all of the type
> errors and you must correct them before you can run the program.

No, the program is accepted only if the type inference algorithm can
prove that the program is type safe. This algorithm is conservative,
so there are programs which are type safe, yet are rejected by the
type inferencer.

Likewise, if there are correctness properties not captured by the type
system (and there generally are; e.g., typechecking a quicksort does
not prove that the output is sorted), then passing type inference does
not mean the program will run correctly.

And finally, some of the "type errors" are not due to actual type
unsafeness, but due to limitations in the type inference procedure,
and/or due to language restrictions stemming from type inference.  A
Lisp programmer would expect that + could be used in places where ML
requires +., for example.

(This also has some bearing on your subsequent comment about running
"type unsafe" programs: the program may also be rejected for reasons
that are evidently spurious, so you want to use it anyway.)

Best,
                        Thomas
-- 
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
 

Thomas Lindgren wrote:
> Jon Harrop <usenet@jdh30.plus.com> writes:
>> If the program remains type safe then it will compile and run correctly.
>> If the program is not type safe, the compiler will point out all of the
>> type errors and you must correct them before you can run the program.
> 
> No, the program is accepted only if the type inference algorithm can
> prove that the program is type safe. This algorithm is conservative,
> so there are programs which are type safe, yet are rejected by the
> type inferencer.

The difference is whether you use the phrase "type safe" in the context of a
given type system (as I did) or more generally (as you did). I'm not sure
that the phrase can be well defined in the latter case but it clearly has a
formal description in the former case.

> Likewise, if there are correctness properties not captured by the type
> system (and there generally are; e.g., typechecking a quicksort does
> not prove that the output is sorted), then passing type inference does
> not mean the program will run correctly.

Yes. On a related note, you can use phantom types exploit the type checker
to prove that additional constraints are satisfied.

> And finally, some of the "type errors" are not due to actual type
> unsafeness, but due to limitations in the type inference procedure,
> and/or due to language restrictions stemming from type inference.  A
> Lisp programmer would expect that + could be used in places where ML
> requires +., for example.

No. SML does not use "+.", for example. Indeed, there is nothing to stop MLs
from providing the same functionality as Lisp in this respect. Making it
extensible is harder (see GCaml).

> (This also has some bearing on your subsequent comment about running
> "type unsafe" programs: the program may also be rejected for reasons
> that are evidently spurious, so you want to use it anyway.)

That is true with dynamic typing as well.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jon Harrop <usenet@jdh30.plus.com> writes:

> Russell McManus wrote:
>> Jon Harrop <usenet@jdh30.plus.com> writes:
>>> I can't think of any examples where it would be useful to run a type
>>> unsafe program. Can you elaborate?
>> 
>> Let's say I want to change the representation of some data, but not
>> have to update 673 different places in the code where the data
>> representation is used before I try it out for one simple case.
>> 
>> For example, some chunk of data used to be a symbol, but no I want it
>> either to be a symbol or a cons pair containing a symbol and a string.
>
> Well, I can think of examples where I've had to change several
> occurrences of a piece of code having tweaked something
> fundamental. However, I can't see how running the broken program
> could have been useful.

Maybe I didn't write the entire program, and seeing where the errors
are thrown would be enlightening[1]?  Perhaps I want to learn how a
big system works not only by inspection, but also by poking it and
seeing where it jumps.

Maybe it's a bad idea to make this change, and I can figure that out
just by playing with one of the 673 occurances, before editing dozens
of source files.  Lisp, at least for me, lowers the overhead for
experimentation.

The reason you can't see this is because you've never tried it!  When
I learned Pascal, I didn't think it was possible to write a program
without line numbers, like the Basic I was used to at the time.  You
know what, it is possible, and even useful!  Even though I'm a
relatively smart person, I had to confront the idea that something
existed that was useful, and I couldn't even imagine it.

Your argument here is that because _you_ can't see the usefulness of
doing things a particular way, it isn't useful.  Even though you may
be a smart person, this isn't a very smart argument.

From my rotating sig file:

  A lot of what makes Lisp so cool is that it inspires people to do
  things for sport.
             -- Kent M Pitman on comp.lang.lisp

-russ


[1] By "where the errors are thrown" not only do I mean the lines of
source code that are erroneous, but also what the run time environment
looks like when the errors are encountered.

Russell McManus wrote:
> Jon Harrop <usenet@jdh30.plus.com> writes:
>> Well, I can think of examples where I've had to change several
>> occurrences of a piece of code having tweaked something
>> fundamental. However, I can't see how running the broken program
>> could have been useful.
> 
> Maybe I didn't write the entire program, and seeing where the errors
> are thrown would be enlightening[1]?

Yes. If you break the typing of a statically typed program then you
basically get the same information as you would with dynamic typing but
much sooner. If you break the program but keep its typing ok then you get
the same result as with dynamic typing but at the same, later time.

> ...
> [1] By "where the errors are thrown" not only do I mean the lines of
> source code that are erroneous, but also what the run time environment
> looks like when the errors are encountered.

If you're talking about running a program that could be statically typed and
that contains a type error then that doesn't make sense. The error could be
"encountered" at any point between compilation and the last valid bit of
execution. So the undefined results that you get are not likely to be of
use.

> Perhaps I want to learn how a 
> big system works not only by inspection, but also by poking it and
> seeing where it jumps.

Again, either you poke it in a way that breaks its typing or you poke it in
a way that does not. In the former case, the compiler tells you "where it
jumps" without you having to run it. In the latter case, you get the same
behaviour as with dynamic typing.

> Maybe it's a bad idea to make this change, and I can figure that out
> just by playing with one of the 673 occurances, before editing dozens
> of source files.

If you're getting all of the useful information earlier with static typing
then I can't see how it could hinder that.

> Lisp, at least for me, lowers the overhead for experimentation.

That is a comparison. What alternatives have you tried?

> The reason you can't see this is because you've never tried it!  When
> I learned Pascal, I didn't think it was possible to write a program
> without line numbers, like the Basic I was used to at the time.  You
> know what, it is possible, and even useful!

Yes. I remember having that revelation myself. :-)

> Even though I'm a 
> relatively smart person, I had to confront the idea that something
> existed that was useful, and I couldn't even imagine it.
>
> Your argument here is that because _you_ can't see the usefulness of
> doing things a particular way, it isn't useful.  Even though you may
> be a smart person, this isn't a very smart argument.

Now that I come to think of it, I've been using dynamically typed languages
with such capabilities for a lot longer than I've been using statically
typed languages. I can't recall ever exploiting dynamic typing in the way
that you describe. However, I can recall many occasions where I've
leveraged the static type checker.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jon Harrop <usenet@jdh30.plus.com> writes:

>> [1] By "where the errors are thrown" not only do I mean the lines of
>> source code that are erroneous, but also what the run time environment
>> looks like when the errors are encountered.
>
> If you're talking about running a program that could be statically
> typed and that contains a type error then that doesn't make
> sense. The error could be "encountered" at any point between
> compilation and the last valid bit of execution. So the undefined
> results that you get are not likely to be of use.

You are actively trying to ignore my point.  I'm sorry I spent some
time writing a post trying to show you something.

*plonk*

-russ

Russell McManus wrote:
> Jon Harrop <usenet@jdh30.plus.com> writes:
>>> [1] By "where the errors are thrown" not only do I mean the lines of
>>> source code that are erroneous, but also what the run time environment
>>> looks like when the errors are encountered.
>>
>> If you're talking about running a program that could be statically
>> typed and that contains a type error then that doesn't make
>> sense. The error could be "encountered" at any point between
>> compilation and the last valid bit of execution. So the undefined
>> results that you get are not likely to be of use.
> 
> You are actively trying to ignore my point.  I'm sorry I spent some
> time writing a post trying to show you something.

Sorry, I really don't mean to ignore your point.

I believed your point was that you wanted to get the "run time environment"
when a type error was "encountered". My point is that, because the state of
the "run time environment" is not well defined, I can't see how it can be
of use?

Are you saying that it is well defined in Lisp? I thought Lisp used varying
degrees of type inference and type checking?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Zach Beane <xach@xach.com> writes:

> David Steuber <david@david-steuber.com> writes:
> 
> > * CLOS: Perl's OO model looks like a tiny CLOS.

Perl "classes" contain just slots (usually just a hashtable that has
been blessed).  Imediate super classes are a list evaluated from left
to right.  Perl classes do not own methods; instead you have regular
subroutines that are just called differently.

Admittedly most of the CLOS features, including all the really nice
ones like multiple dispatch are missing.  But Perl's OO model is
certainly closer to CLOS than to Java's model.

-- 
http://www.david-steuber.com/
The UnBlog | Lisp on OS X topics for the most part
Click all the links you want.  I'll make more!

Jon Harrop wrote:

> Yes. If you break the typing of a statically typed program then you
> basically get the same information as you would with dynamic typing but
> much sooner. If you break the program but keep its typing ok then you get
> the same result as with dynamic typing but at the same, later time.

I have to beg to differ. Your assumption only holds if your
intermediate results are passed on to the next function where they
/all/ will be used.

Changing things in a statically typed language is horrible to say the
least. The Clean language was often my worst enemy in this respect.

On the other side: programming in Scheme (Bigloo) turns you into
liberation. I often have got return types in Scheme which consist of a
list. In a statically typed language you are forced to take care on the
proper types in this particular list. So, changing 623 things is really
a nightmare. However, in Scheme I am often only interested in one
particular element of that particular return list even all the other
elements of that list are wrong due to my chaning of some types.

Maybe my programs are bad designed, though. But Scheme (and also Common
Lisp) stand for freedom in ones own life.

Schneewittchen

"F�rster vom Silberwald" <chain_lube@hotmail.com> writes:
> Changing things in a statically typed language is horrible to say the
> least.

At least, it's a useless burden.  

When you've had to change the type of some object two or three times
in a sizeable pascal or Modula-2 program, with all the small edits
all over the sources, it grows old.

I know that in ML-like language, the static type is not declared, but
infered.  Then for me it doesn't matter whether I get errors at
compilation time or at run-time.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein

Julian Squires  <julian@cipht.net> wrote:
+---------------
| This one should be of special interest, although I guess it should be
| considered as a dead link:
| http://web.archive.org/web/20041026002128/http://www.spies.com/~aek/explorer/zeta-c/ZETA-C-PD.tgz
+---------------

I can get *most* of it, but the tail is truncated:

   $ tar ztvf ZETA-C-PD.tgz
   ...[most of it looks o.k., then]...
   -rw-rw-r-- gyro/staff   413 Nov 13 14:50 1986 ZETA-C-PD/Include/Sys/types.h
   drwxrwsr-x gyro/staff     0 May 22 17:10 1994 ZETA-C-PD/Library/
   -rw-rw-r-- gyro/staff 27907 Jul  8 23:16 1986 ZETA-C-PD/Library/gmap.lisp

   gzip: stdin: unexpected end of file
   tar: Child returned status 1
   tar: Error exit delayed from previous errors
   $ 


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607

Jon Harrop <usenet@jdh30.plus.com> writes:

> Thomas Lindgren wrote:
> > ...
>
> The difference is whether you use the phrase "type safe" in the context of a
> given type system (as I did) or more generally (as you did). I'm not sure
> that the phrase can be well defined in the latter case but it clearly has a
> formal description in the former case.

I believe type safety is a broader concept than that, though the
terminology keeps mutating. For example, Milner used a phrase like
"well-typed programs do not go wrong" (quoting from memory), provided
a language and a semantics and then showed that his type system only
accepted programs that could not reach the "wrong" state. Or so I seem
to recall.

> > A
> > Lisp programmer would expect that + could be used in places where ML
> > requires +., for example.
> 
> No. SML does not use "+.", for example. 

Point taken, the (+.) comes from OCaml. What is the type signature of
a function adding two numbers in SML?

> Indeed, there is nothing to stop MLs
> from providing the same functionality as Lisp in this respect. Making it
> extensible is harder (see GCaml).

If an ML started using the CL numeric tower, it would, as far as I can
figure it out, fall back on the equivalent of dynamic checking: e.g.,
declare the "numeric" type as an algebraic type and pattern match on
the tags when a particular type is needed (and generating an exception
when it does not). But perhaps there is a better solution.

Anyway, the larger point still remains:

> > And finally, some of the "type errors" are not due to actual type
> > unsafeness, but due to limitations in the type inference procedure,
> > and/or due to language restrictions stemming from type inference.  

Moving on.

> > (This also has some bearing on your subsequent comment about running
> > "type unsafe" programs: the program may also be rejected for reasons
> > that are evidently spurious, so you want to use it anyway.)
> 
> That is true with dynamic typing as well.

I'm not sure to which "that" you refer, but with dynamic typing you
then _can_ run the program. There is no type inference gatekeeper.

Well, that has to be it for now.

Best,
                        Thomas
-- 
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
 

rpw3@rpw3.org (Rob Warnock) writes:
> Julian Squires  <julian@cipht.net> wrote:
> | This one should be of special interest, although I guess it should be
> | considered as a dead link:
> | http://web.archive.org/web/20041026002128/http://www.spies.com/~aek/explorer/zeta-c/ZETA-C-PD.tgz
> I can get *most* of it, but the tail is truncated:

I have asked "aek" to resurrect the file as his new site, bitsavers.org.

In the meantime, maybe someone else has a copy?

Bradd W. Szonye wrote:
> Polish is "obscure"? If it weren't for the .co.nz in your address, I'd
> guess you were American!

Well trekking in the Arctic doesn't happen to be one of my hobbies so
you must excuse my ignorance about the dialectology of those regions.

--
Kris

* Lars Brinkhoff [2005-09-27 12:33]:
> rpw3@rpw3.org (Rob Warnock) writes:
> > Julian Squires  <julian@cipht.net> wrote:
> > | This one should be of special interest, although I guess it should be
> > | considered as a dead link:
> > | http://web.archive.org/web/20041026002128/http://www.spies.com/~aek/explorer/zeta-c/ZETA-C-PD.tgz
> > I can get *most* of it, but the tail is truncated:
> 
> I have asked "aek" to resurrect the file as his new site, bitsavers.org.
> 
> In the meantime, maybe someone else has a copy?

You can get it here:

http://members.hellug.gr/adia/m/ZETA-C-PD.tgz
http://members.hellug.gr/adia/m/ZETA-C-PD_releaseMail.txt

-- 
Alexandros Diamantidis * adia@hellug.gr

In comp.lang.lisp Christopher C. Stacy <cstacy@news.dtpq.com> wrote:

>What about when you want to change all occurances of that
>to a different type?  What about when you don't know ahead
>of time what the abstract taxonomy should be, and it keeps
>changing as you revise your ideas of how to write the program?

The classical approach is to sit down at the desk with pencil and paper
and think for a long time and sketch out the design and a rough
implementation roadmap _before_ writing the code.  Unfortunately, this
isn't really fashionable anymore today (otoh, UML and case tools seem to
gain acceptance; on closer inspection, that's better than nothing,
although a bit too bureaucratic and stiff for my taste.) However, this
"I start with the empty word and then debug my program into existence"
approach (basically the bottom-up extreme) is imho the root cause of all
evil in the "software crisis".

mkb.

Christopher C. Stacy wrote:

> It's like talking to a brick troll...
> 
Only if you bother to talk to it.

Programmer in Chief wrote:

> If I could put one trivial change to the original design of Scheme, I
> would say that all the arrows are backwards.  Change |number->string|
> to |string<-number| and change all similar names like |from->to| to
> |to<-from|.  Then they will compose properly like (vector<-list
> (list<-string (string<-number n))) to get a vector of characters from a
> number.
> 
> But here I am stuck in the present, and all I can do is post pointless
> rants in boring threads of little noticed newsgroups, too late to have
> any effect.
> 

You're wrong about that, you know; you can design an experimental
lisp dialect and do things the way you want 'em; people might
grab and use it.

Incidentally, your idea about reversing the arrows to make
composability look better seems like a good idea to me...  I
think that I will steal it for my own experimental lisp dialect.
See, you've already had an effect!

I'd read <- as "from" rather than "to", so instead of str2num or
str->num pronounced "string to number", you'd have num<-string
pronounced "number from string."

				Bear

Ron Garret <rNOSPAMon@flownet.com> wrote:

>The problem with this reasoning is that markets are not efficient, and 
>markets for infrastructure (which is what languages are) are 
>particularly inefficient because there are very strong positive feedback 
>forces that tend to drive infrastructure markets towards standardization 
>and the status quo.

This is normally true for new products which have to fight against an
established market.  But Lisp has been around for 50 years, much longer
than any of the languages that are now dominating the market.  If it has
been mainly ignored for 50 years, and new languages have popped up and
succeeded during that time, then isn't that at least some indication
that it doesn't quite fulfil the expectations of a large number of
programmers?

mkb.

Matthias Buelow wrote:

> In comp.lang.lisp Christopher C. Stacy <cstacy@news.dtpq.com> wrote:
> 
>>What about when you want to change all occurances of that
>>to a different type?  What about when you don't know ahead
>>of time what the abstract taxonomy should be, and it keeps
>>changing as you revise your ideas of how to write the program?
> 
> The classical approach is to sit down at the desk with pencil and paper
> and think for a long time and sketch out the design and a rough
> implementation roadmap _before_ writing the code.

Meanwhile the computer that I could have at my disposal is doing 
nothing. That's a waste of computational resources.

While doing pencil-and-paper designs, I typically need to run test cases 
in my head to see whether what I attempt to achieve actually works or 
not. I prefer to run those test cases directly on the computer, which 
gives the additional benefit that I didn't make any mistakes in actually 
running them.

The computer is an extension of my thinking capabilities that allows me 
to try out new ideas without being sure whether they will actually work 
out or not. I regard this as an advantage.


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

In comp.lang.lisp Pascal Costanza <pc@p-cos.net> wrote:

>Meanwhile the computer that I could have at my disposal is doing 
>nothing. That's a waste of computational resources.

What, you don't have a screensaver?

mkb.

>If I were sent back in time to help with the first design of Lisp, I
>would recommend using |first| and |rest| abbreviated as |fst| and |rst|
>and make the substitutions |frrst| for |caddr|, |ffrrst| for |caaddr|,
>etc.

I don't know if it's just the airconditioning is on too high, but
ffrrst makes me feel cold ;-)

Justin

Matthias Buelow <mkb@incubus.de> writes:

> Ron Garret <rNOSPAMon@flownet.com> wrote:
>
>>The problem with this reasoning is that markets are not efficient,
>>and markets for infrastructure (which is what languages are) are
>>particularly inefficient because there are very strong positive
>>feedback forces that tend to drive infrastructure markets towards
>>standardization and the status quo.
>
> This is normally true for new products which have to fight against
> an established market. But Lisp has been around for 50 years, much
> longer than any of the languages that are now dominating the market.
> If it has been mainly ignored for 50 years, and new languages have
> popped up and succeeded during that time, then isn't that at least
> some indication that it doesn't quite fulfil the expectations of a
> large number of programmers?

Only if you believe that large numbers of programmers gave it an
honest try and *then* voted with their feet. Also relevant, I believe,
to any discussion of programming language popularity is the phenomenon
of "information cascade". For more on that see _The Wisdom of Crowds_,
particularly the section on "Plank Road Fever" starting on page 53,
possibly the best explanation for the rise of C++ that I've ever read.

-Peter

-- 
Peter Seibel           * peter@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp  * http://www.gigamonkeys.com/book/

In article <3ptfndFc5d26U2@news.dfncis.de>,
 Matthias Buelow <mkb@incubus.de> wrote:

> Ron Garret <rNOSPAMon@flownet.com> wrote:
> 
> >The problem with this reasoning is that markets are not efficient, and 
> >markets for infrastructure (which is what languages are) are 
> >particularly inefficient because there are very strong positive feedback 
> >forces that tend to drive infrastructure markets towards standardization 
> >and the status quo.
> 
> This is normally true for new products which have to fight against an
> established market.  But Lisp has been around for 50 years, much longer
> than any of the languages that are now dominating the market.  If it has
> been mainly ignored for 50 years

That's not true.  Lisp was actually quite popular in the late seventies 
and early eighties.  At the time it was not at all clear that Lisp would 
not end up taking over the world.

> and new languages have popped up and
> succeeded during that time, then isn't that at least some indication
> that it doesn't quite fulfil the expectations of a large number of
> programmers?

Of course, but 1) a large number of programmers have the wrong 
expectations and 2) so what?  The Lotus Elise doesn't quite fulfill the 
expectations of a large number of drivers, but it's still a pretty great 
car.

Also if you're going to draw any conclusions from market results you 
also have to keep in mind some historical context.  Lisp hitched its 
fortunes to AI as its "killer ap", and to custom-hardware as its 
implementation platform of choice.  AI over-promised and 
under-delivered, and custom hardware couldn't take advantage of 
economies of scale.  So it's not at all clear whether the market was 
rejecting Lisp per se, or rejecting AI and Lisp *machines*.

rg

Ray Dillinger wrote:

> Incidentally, your idea about reversing the arrows to make
> composability look better seems like a good idea to me...

It's been my practice for a while in languages like Lisp
where I can use names with "<-" in them. In languages
with traditionally impoverished token syntax, the extra
length of "_from_" versus "_to_" or even "2" is enough
to dissuade me. :-)

-- 
Gareth McCaughan
..sig under construc

"Kris Cipa" <kristinacipa@yahoo.co.nz> writes:

> Well trekking in the Arctic doesn't happen to be one of my hobbies so
> you must excuse my ignorance about the dialectology of those regions.

You don't appear to be too well versed in the geography either. :-)

Poland is just east of Germany, south of Scandinavia, on the border of
western Europe. You won't find many polar bears there...

-- 
Troels "Athas" Henriksen

Thomas Lindgren wrote:
>> No. SML does not use "+.", for example.
> 
> Point taken, the (+.) comes from OCaml.

Yes.

> What is the type signature of a function adding two numbers in SML?

During unification, something akin to number -> number -> number but it
defaults to int -> int -> int when "exposed". For example, a function to
add the real "3.0" to "x", and a function to add two numbers "i" and "j":

$ sml
Standard ML of New Jersey v110.52 [built: Fri Jan 21 16:42:10 2005]
- fun add3 x = x + 3.0;;
val add3 = fn : real -> real
- fun add i j = i+j;;
val add = fn : int -> int -> int

The defaulting only happens in a top-level, AFAIK. So if you use a compiler
like MLton the types are never "exposed" and it never needs to default to
"int". On the other hand, this means that you cannot call "add" with ints
one time and reals the next.

>> Indeed, there is nothing to stop MLs
>> from providing the same functionality as Lisp in this respect. Making it
>> extensible is harder (see GCaml).
> 
> If an ML started using the CL numeric tower, it would, as far as I can
> figure it out, fall back on the equivalent of dynamic checking: e.g.,
> declare the "numeric" type as an algebraic type and pattern match on
> the tags when a particular type is needed (and generating an exception
> when it does not).

Yes, you can do it that way. This could be implemented as a macro. However,
this incurs the pain and performance-hit of dynamic typing.

> But perhaps there is a better solution.

Actually there are several better solutions. :-)

Firstly, you can just use ordinary static typing with ad-hoc polymorphism,
as SML does for "+" and OCaml does for "printf". Types are then "flexible"
but ossified at compilation so the resulting code is not dynamically typed
and, therefore, is much faster.

Secondly, you could use the extensible form of polymorphism offered by
GCaml. This gives you even more flexible types (e.g. your program can
supplement "+" with a definition vec -> vec -> vec) whilst still retaining
top-notch performance due to static typing.

Finally, you could use type classes. I don't know much about this option but
I believe it will incur a performance cost. However, I suspect it will be
much easier to optimise than general dynamic typing (like Lisp's) because
the type system conveys a lot of information to the optimiser.

> Anyway, the larger point still remains:
> 
>> > And finally, some of the "type errors" are not due to actual type
>> > unsafeness, but due to limitations in the type inference procedure,
>> > and/or due to language restrictions stemming from type inference.
> 
> Moving on.
> 
>> > (This also has some bearing on your subsequent comment about running
>> > "type unsafe" programs: the program may also be rejected for reasons
>> > that are evidently spurious, so you want to use it anyway.)
>> 
>> That is true with dynamic typing as well.
> 
> I'm not sure to which "that" you refer, but with dynamic typing you
> then _can_ run the program. There is no type inference gatekeeper.

With dynamic typing you can try to run the program but the dynamic type
checker can still reject correct code (i.e. code that would run fine in an
untyped language).

Compared to Hindley-Milner, static typing will reject some programs that
dynamic typing will allow (e.g. polymorphic recursion).

I don't know whether or not static type systems exist that allow the same
set of programs as dynamic type checking. Given how obscure code must be to
be rejected by a simple static type system, I think the expressiveness of
the type system is much more important.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

F�rster vom Silberwald wrote:
> Jon Harrop wrote:
>> Yes. If you break the typing of a statically typed program then you
>> basically get the same information as you would with dynamic typing but
>> much sooner. If you break the program but keep its typing ok then you get
>> the same result as with dynamic typing but at the same, later time.
> 
> I have to beg to differ. Your assumption only holds if your
> intermediate results are passed on to the next function where they
> /all/ will be used.

If your program calls functions that would not type check and then ignores
the results, yes.

However, I don't do that in my code and I can't see any use for it. Indeed,
I can't see how that could be anything but a source of bugs.

> Changing things in a statically typed language is horrible to say the
> least. The Clean language was often my worst enemy in this respect.

While I can somewhat understand that point of view, it still surprises me. I
think we need some code here. Look at my ray tracer. :-)

If you change the type of the scene tree to include a new object, say:

  type scene = Sphere of vec * float | UnitCube | Group of scene list

The program is now incorrect because it contains pattern matches that fail
to account for UnitCube. However, then the program still compiles and runs
ok. If the program were to fail at run-time then it would raise a
Match_failure exception.

So that example is strictly better than dynamic typing because the errors
are reported immediately.

Now, if you change the type of a vector:

  type vec = float * float * float

then all of the vector arithmetic becomes incorrect. The program will not
compile because the functions acting on vectors refer to names that don't
exist (members of the old vec record). You can't run it.

With dynamic typing you can run it. It will give a run-time type error
almost immediately in this case. That conveys the same information in this
case.

All of the other types are not declared. So if you change them then they
will just be inferred to have a different type.

> On the other side: programming in Scheme (Bigloo) turns you into
> liberation. I often have got return types in Scheme which consist of a
> list. In a statically typed language you are forced to take care on the
> proper types in this particular list.

The "proper type" can be polymorphic, of course.

> So, changing 623 things is really 
> a nightmare. However, in Scheme I am often only interested in one
> particular element of that particular return list even all the other
> elements of that list are wrong due to my chaning of some types.

Sounds like you want tuples instead of lists.

> Maybe my programs are bad designed, though. But Scheme (and also Common
> Lisp) stand for freedom in ones own life.

That's interesting. I deliberately use the static type system to restrict
what I can do, to reduce mistakes. You must be more disciplined than I
am. ;-)

Do you not worry about type errors that remain in your programs?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jon Harrop <usenet@jdh30.plus.com> writes:
>> Maybe my programs are bad designed, though. But Scheme (and also Common
>> Lisp) stand for freedom in ones own life.
>
> That's interesting. I deliberately use the static type system to restrict
> what I can do, to reduce mistakes. You must be more disciplined than I
> am. ;-)
>
> Do you not worry about type errors that remain in your programs?

See?  This is the (an) answer to the question "What's so great about Lisp?"
We've burnt all the leather, and cast away all the iron!


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
The rule for today:
Touch my tail, I shred your hand.
New rule tomorrow.

<david.golden@oceanfree.net> wrote:
>Well, the problem stems from "atom" (meaning indivisible
>thing: a-tom) being applied by physicists to something 
>that later turned out to be divisible.  D'oh.  

By philosophers, not physicists.
Physicists would never make such a mistake, would they? ;)

Roberto Waltman

[ Please reply to the group, ]
[ return address is invalid. ]

Gareth McCaughan wrote:
> Ray Dillinger wrote:
>> Incidentally, your idea about reversing the arrows to make
>> composability look better seems like a good idea to me...
> 
> It's been my practice for a while in languages like Lisp
> where I can use names with "<-" in them. In languages
> with traditionally impoverished token syntax, the extra
> length of "_from_" versus "_to_" or even "2" is enough
> to dissuade me. :-)

Ironically, other versions of my ray tracer used ', +|, *|, -| and
lambda. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Alexandros Diamantidis  <adia@hellug.gr> wrote:
+---------------
| * Lars Brinkhoff [2005-09-27 12:33]:
| > rpw3@rpw3.org (Rob Warnock) writes:
| > > I can get *most* of it, but the tail is truncated:
| > I have asked "aek" to resurrect the file as his new site, bitsavers.org.
| > In the meantime, maybe someone else has a copy?
| 
| You can get it here:
| http://members.hellug.gr/adia/m/ZETA-C-PD.tgz
| http://members.hellug.gr/adia/m/ZETA-C-PD_releaseMail.txt
+---------------

Thanks!

Hmmm... Interesting... The truncated one I got was missing exactly
one byte at the end:

  $ ls -l ZE*
  -rw-r--r--  1 rpw3  rpw3  253581 Sep 28 01:08 ZETA-C-PD.tgz
  -rw-r--r--  1 rpw3  rpw3  253580 Sep 27 02:40 ZETA-C-PD.tgz.bad

And the missing byte is a #\Null, at that!  Web server bug? ;-}


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607

Programmer in Chief wrote 
> If I could put one trivial change to the original design
> of Scheme, I would say that all the arrows are backwards.
> Change |number->string| to |string<-number| and change all
> similar names like |from->to| to |to<-from|.  Then they
> will compose properly like (vector<-list (list<-string
> (string<-number n))) to get a vector of characters from a
> number.

I was making the same suggestion on c.l.l. in august.

http://groups.google.co.uk/group/comp.lang.lisp/browse_thread/thread/c24da5ee0394335d/326f8f2ce5a3a4a4?lnk=st&q=joel+group:comp.lang.lisp+author:Alan+author:Crowe&rnum=1&hl=en#326f8f2ce5a3a4a4

perhaps it is an idea whose time has come

Alan Crowe
Edinburgh
Scotland

Jon Harrop <usenet@jdh30.plus.com> writes:

> With dynamic typing you can run it. It will give a run-time type
> error almost immediately in this case. That conveys the same
> information in this case.

Wrong.  I'm missing a stack trace.  Why is this so hard for you to
understand?

-russ

Russell McManus wrote:
> Jon Harrop <usenet@jdh30.plus.com> writes:
> 
>> With dynamic typing you can run it. It will give a run-time type
>> error almost immediately in this case. That conveys the same
>> information in this case.
> 
> Wrong.  I'm missing a stack trace.  Why is this so hard for you to
> understand?

You have the static call stack (or can write a tool to generate it for 
you), i.e. you can look at the source to see where some function gets 
called.  The actual dynamic call stack might differ, but a static 
checker will make sure that *all* possible call stacks always transmit 
correctly typed values.

-- 
Do or do not.  There is no try.
   Yoda

Ulrich Hobelmann <u.hobelmann@web.de> writes:

> You have the static call stack (or can write a tool to generate it
> for you), i.e. you can look at the source to see where some function
> gets called.  The actual dynamic call stack might differ, but a
> static checker will make sure that *all* possible call stacks always
> transmit correctly typed values.

Yes, I know that I can look at the source, thanks for this insight.

But keep in mind that a tool that prints out all possible static call
stacks if of no practical value, because there are 50 gazillion
possible static call stacks!

Which is the one that actually happens on the data that I've actually
got in front of me now?  This is what I want to know.  Are you guys
being dense on purpose?

-russ

On 2005-09-27, Troels Henriksen <athas@sigkill.dk> wrote:

>> Well trekking in the Arctic doesn't happen to be one of my hobbies so
>> you must excuse my ignorance about the dialectology of those regions.
>
> You don't appear to be too well versed in the geography either. :-)
>
> Poland is just east of Germany, south of Scandinavia, on the border of
> western Europe. You won't find many polar bears there...

Well, he probably thinks the North Pole is a Polander from the Arctic,
which is perfectly logical.

Is it Troels Henriksen or Henriksen Troels? ;-)

Russell McManus wrote:
> But keep in mind that a tool that prints out all possible static call
> stacks if of no practical value, because there are 50 gazillion
> possible static call stacks!
> 
> Which is the one that actually happens on the data that I've actually
> got in front of me now?  This is what I want to know.  Are you guys
> being dense on purpose?

No, it's just that you don't *need* the call stacks in a static 
language, because all type information is local.  You don't need to see 
what could *happen* in the function, you can look at it (or rather, see 
what the compiler found in the function) and resolve the error.

Static type systems are vastly simpler than anything you might analyze 
in a dynamic, running program, so the only errors it will mention are of 
the nature "different types returned in different COND clauses", or 
"calling function with wrong typed arguments", something of that kind. 
All these errors can be resolved by looking at the local piece of code 
at hand.  A call stack couldn't really help there.

What a non-static language allows you to do is run these kind of 
programs anyway, or use shortcuts that aren't necessarily well-typed (in 
a Hindley-Milner or C context), but will still run.  For instance I 
think that macros (i.e. operations on sexps) don't have a meaningful 
type (sexp -> sexp usually).  You can think of Lisp having a similarly 
loose type system, so if you want to know why some value is passed to a 
function, causing a crash, you need the call stack to see what happened 
there.  A static type system forces you to more clearly define the 
argument and return types, thus narrowing down what can happen.  This 
might either lead to lots of type declarations, or (like in the macro 
case) mean that you choose a very wide type and need dynamic debugging 
anyway.

-- 
Do or do not.  There is no try.
   Yoda