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.
> 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
"Ben" <········@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.
Pascal Bourguignon wrote:
> "Ben" <········@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. :)
In <························@g14g2000cwa.googlegroups.com> "Ben" <········@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: ······@iki.fi, +35841 5323835, +3589 85619369
work contact: ················@helsinki.fi, +35850 3678003
kotisivu (henkkoht): http://www.iki.fi/atehwa/
homepage (technical): http://sange.fi/~atehwa/
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.
From: Edi Weitz
Subject: Re: Software methodology [Re: What's so great about lisp?]
Date:
Message-ID: <umzm2v7op.fsf@agharta.de>
On 24 Sep 2005 02:19:33 -0700, "Ben" <········@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 ·········@agharta.de" 5) "edi")
(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: ······@iki.fi, +35841 5323835, +3589 85619369
work contact: ················@helsinki.fi, +35850 3678003
kotisivu (henkkoht): http://www.iki.fi/atehwa/
homepage (technical): http://sange.fi/~atehwa/
On 24 Sep 2005 05:59:55 GMT, Panu Kalliokoski <······@sange.fi>
wrote:
>In <························@g14g2000cwa.googlegroups.com> "Ben" <········@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
From: Ulrich Hobelmann
Subject: Re: Software methodology [Re: What's so great about lisp?]
Date:
Message-ID: <3pl78gFatc20U1@individual.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)
In <··································@4ax.com> A.L. <········@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.
On 24 Sep 2005 16:49:49 GMT, Panu Kalliokoski <······@sange.fi>
wrote:
>In <··································@4ax.com> A.L. <········@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.
In <··································@4ax.com> A.L. <········@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: ······@iki.fi, +35841 5323835, +3589 85619369
work contact: ················@helsinki.fi, +35850 3678003
kotisivu (henkkoht): http://www.iki.fi/atehwa/
homepage (technical): http://sange.fi/~atehwa/
In <·················@ram.dialup.fu-berlin.de> ···@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: ······@iki.fi, +35841 5323835, +3589 85619369
work contact: ················@helsinki.fi, +35850 3678003
kotisivu (henkkoht): http://www.iki.fi/atehwa/
homepage (technical): http://sange.fi/~atehwa/
Panu Kalliokoski <······@sange.fi> writes:
> In <·················@ram.dialup.fu-berlin.de> ···@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------
From: Matthias Buelow
Subject: Re: Software methodology [Re: What's so great about lisp?]
Date:
Message-ID: <3pll13Fb4ipoU1@news.dfncis.de>
In comp.lang.lisp Stefan 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.scheme Matthias Buelow <···@incubus.de> wrote:
> In comp.lang.lisp Stefan 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...
In real world, external constraints often make it impossible, as
some needed choices for this (like 'rearchitect') are eliminated
rather early.
>
> mkb.
--
Sander
+++ Out of cheese error +++
Pascal Bourguignon wrote:
> "Ben" <········@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
From: Duane Rettig
Subject: Re: What's so great about lisp?
Date:
Message-ID: <47jd7hmgk.fsf@franz.com>
"Kris Cipa" <············@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 ·····@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 <·······················@z14g2000cwz.googlegroups.com>,
"Kris Cipa" <············@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).
In <·······························@news.gha.chartermi.net> Ron Garret <·········@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: ······@iki.fi, +35841 5323835, +3589 85619369
work contact: ················@helsinki.fi, +35850 3678003
kotisivu (henkkoht): http://www.iki.fi/atehwa/
homepage (technical): http://sange.fi/~atehwa/
Ron Garret wrote:
> In article <·······················@z14g2000cwz.googlegroups.com>,
> "Kris Cipa" <············@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�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
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�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
In comp.lang.lisp Ron Garret <·········@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.
In article <··············@news.dfncis.de>,
Matthias Buelow <···@incubus.de> wrote:
> In comp.lang.lisp Ron Garret <·········@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
Ron Garret <·········@flownet.com> writes:
> In article <··············@news.dfncis.de>,
> Matthias Buelow <···@incubus.de> wrote:
>
>> In comp.lang.lisp Ron Garret <·········@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
In article <··············@hanabi.local>,
Matthias Blume <····@my.address.elsewhere> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@news.dfncis.de>,
> > Matthias Buelow <···@incubus.de> wrote:
> >
> >> In comp.lang.lisp Ron Garret <·········@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
Ron Garret <·········@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
In article <··············@hanabi.local>,
Matthias Blume <····@my.address.elsewhere> wrote:
> Ron Garret <·········@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
["Followup-To:" header set to comp.lang.lisp.]
On 2005-09-24, Matthias Blume <····@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
Matthias Blume wrote:
> Ron Garret <·········@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 <······@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 ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Sat, 24 Sep 2005 20:51:31 +0100, Jon Harrop <······@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! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Edi Weitz <········@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
Edi Weitz <········@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.
Matthias Buelow wrote:
> Edi Weitz <········@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
Kenny Tilton <·······@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.
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.
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
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 ++++
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
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 ++++
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
From: Bulent Murtezaoglu
Subject: Re: What's so great about lisp?
Date:
Message-ID: <87ll1lfj4t.fsf@p4.internal>
>>>>> "JH" == Jon Harrop <······@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..."
( <·························@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
Bulent Murtezaoglu wrote:
>>>>>> "JH" == Jon Harrop <······@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.
> ( <·························@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
Jon Harrop <······@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!
Ron Garret wrote:
> In article <··············@news.dfncis.de>,
> Matthias Buelow <···@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
In article <···············@typhoon.sonic.net>,
Ray Dillinger <····@sonic.net> wrote:
> Ron Garret wrote:
> > In article <··············@news.dfncis.de>,
> > Matthias Buelow <···@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
Ron Garret <·········@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! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
In comp.lang.lisp Thomas F. Burdick <···@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.
Matthias Buelow wrote:
> In comp.lang.lisp Thomas F. Burdick <···@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
Matthias Buelow <···@incubus.de> writes:
> In comp.lang.lisp Thomas F. Burdick <···@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! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
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
On 2005-09-25, Jon Harrop <······@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
Julian Squires wrote:
> On 2005-09-25, Jon Harrop <······@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
In comp.lang.lisp Thomas F. Burdick <···@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.
···@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!
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/
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:
> 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
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
In article <·················@typhoon.sonic.net>,
Ray Dillinger <····@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
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 <·················@typhoon.sonic.net>,
Ray Dillinger <····@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.
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 <···········@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?
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?"
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
Jon Harrop <······@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 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 ++++
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
Jon Harrop <······@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
Russell McManus wrote:
> Jon Harrop <······@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
Jon Harrop <······@jdh30.plus.com> writes:
> Russell McManus wrote:
>> Jon Harrop <······@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 <······@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 <······@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 <······@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
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" <··········@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
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 <······@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.
Jon Harrop <······@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 <······@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 <···········@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
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
Ulrich Hobelmann <···········@web.de> writes:
> 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.
I see that you didn't answer my question. If I've got a particular
test case in hand, and I change this one data representation, what
breaks? I'm forced to conclude that you can't answer this.
Also you're incorrectly assuming that I haven't programmed in ML
before. Please stop this. And while you're at it, stop telling me
what I need and what I don't need; how can you possibly know? Your
attempt to read my mind has failed.
> 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.
You're not listening. I don't want to change "all these errors",
i.e. 673 usages of a type in the code, just too see what would break
for the test case I have in hand.
And please stop assuming that I don't know how static type systems
work.
-russ
Russell McManus wrote:
> I see that you didn't answer my question. If I've got a particular
> test case in hand, and I change this one data representation, what
> breaks? I'm forced to conclude that you can't answer this.
I don't know what class of change or breakage you're talking about. I
said that for the kind of error static checking catches you don't need a
dynamic trace, but for everything else you do.
> Also you're incorrectly assuming that I haven't programmed in ML
> before. Please stop this. And while you're at it, stop telling me
> what I need and what I don't need; how can you possibly know? Your
> attempt to read my mind has failed.
I never claimed you don't know ML. I only tried to explain that dynamic
stack info doesn't help you in any way to catch an error that violates
static typing. I never even thought about reading anyone's mind either,
because I couldn't care less.
>> 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.
>
> You're not listening. I don't want to change "all these errors",
> i.e. 673 usages of a type in the code, just too see what would break
> for the test case I have in hand.
Ok, that's a point.
> And please stop assuming that I don't know how static type systems
> work.
Ok, maybe by your post I did (wrongly) assume that, but I'll stop now :)
--
Do or do not. There is no try.
Yoda
Russell McManus wrote:
> I see that you didn't answer my question. If I've got a particular
> test case in hand, and I change this one data representation, what
> breaks? I'm forced to conclude that you can't answer this.
I'm not sure that I understand your question but I think the answer is: your
program breaks and the static type checker tells you where and how and
forces you to fix it before you can run your program. You are saying that
you want to be able to run a program knowing that it is unsound. You are
quite right that you cannot do that in a statically typed language.
I don't think any of those points are up for discussion any more - we all
agree. The question now is, is it really useful to run programs when you
know they are wrong?
You say yes. I agree entirely if you're using a dynamically typed language
because it is the only way you can find type errors.
However, for errors that can be caught statically, I think it is pointless
because you get no useful information. If you're actually trying to get the
state at a particular point then set a break point or raise an exception.
> You're not listening. I don't want to change "all these errors",
> i.e. 673 usages of a type in the code, just too see what would break
> for the test case I have in hand.
That is a feature that I don't miss. Can you give an example where you think
this would be a problem?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> The question now is, is it really useful to run programs when you
> know they are wrong?
>
> You say yes. I agree entirely if you're using a dynamically typed language
> because it is the only way you can find type errors.
I always run programs I know are wrong. Nearly any program longer
than a page has bugs in it.
> However, for errors that can be caught statically, I think it is pointless
> because you get no useful information.
Not true. A static check will tell you that it is possible for an
error to occur, but running the code to the failure point gives you a
concrete example of the error condition.
The error messages one gets from a static type checker are often obscure.
Joe Marshall wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> The question now is, is it really useful to run programs when you
>> know they are wrong?
>>
>> You say yes. I agree entirely if you're using a dynamically typed
>> language because it is the only way you can find type errors.
>
> I always run programs I know are wrong. Nearly any program longer
> than a page has bugs in it.
Ok. If I wrote a 2 page program I wouldn't assert that it was wrong. If the
static type checker was happy with it then I'd assert that it was probably
right. The more static analysis that showed up no flaws, the more confident
I would be. If I unit tested it then I'd be slightly more confident.
>> However, for errors that can be caught statically, I think it is
>> pointless because you get no useful information.
>
> Not true. A static check will tell you that it is possible for an
> error to occur, but running the code to the failure point gives you a
> concrete example of the error condition.
Your statement is orthogonal to mine. Both are true, IMHO.
For example, if your program accidentally passes a string as an argument
when an int is expected, a "concrete example of the error condition"
conveys no useful information. Who cares what string was passed, it wasn't
supposed to be a string.
> The error messages one gets from a static type checker are often obscure.
We'll have to agree to disagree on that one.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> For example, if your program accidentally passes a string as an argument
> when an int is expected, a "concrete example of the error condition"
> conveys no useful information. Who cares what string was passed, it wasn't
> supposed to be a string.
What if it were the string "/usr/jharrop/.bashrc" ? Might this get
you thinking about where filenames come into the system? What if it
were "12pt"? Might you start thinking about font sizes?
Joe Marshall wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> For example, if your program accidentally passes a string as an argument
>> when an int is expected, a "concrete example of the error condition"
>> conveys no useful information. Who cares what string was passed, it
>> wasn't supposed to be a string.
>
> What if it were the string "/usr/jharrop/.bashrc" ? Might this get
> you thinking about where filenames come into the system? What if it
> were "12pt"? Might you start thinking about font sizes?
Sure, if it were "huge dangles" it might get me thinking about familiar
disorders. That's just distracting.
It would still have no effect on my fixing the bug, which I would do by
going to the type mismatch reported by the type checker and correcting the
expression.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Joe Marshall wrote:
>> Jon Harrop <······@jdh30.plus.com> writes:
>>> For example, if your program accidentally passes a string as an argument
>>> when an int is expected, a "concrete example of the error condition"
>>> conveys no useful information. Who cares what string was passed, it
>>> wasn't supposed to be a string.
>>
>> What if it were the string "/usr/jharrop/.bashrc" ? Might this get
>> you thinking about where filenames come into the system? What if it
>> were "12pt"? Might you start thinking about font sizes?
>
> Sure, if it were "huge dangles" it might get me thinking about familiar
> disorders. That's just distracting.
>
> It would still have no effect on my fixing the bug, which I would do by
> going to the type mismatch reported by the type checker and correcting the
> expression.
I approach debugging completely differently, then.
Suppose I encountered the string "12pt" where an int were expected.
Like as not, what was desired was the font size in some measure
(probably even points). Clearly the string needs to be parsed, but it
is not so clear that the erring expressing is the one to be fixed.
For the sake of argument, let's suppose that I had written something
like this:
int fontHeight = Font.Find ("foobar").height;
not realizing that the ".height" field simply returned a string from a
config file somewhere. I could fix this by modifying the code here:
string fontHeightString = Font.Find ("foobar").height;
int fontHeight = Integer.Parse (fontHeightString);
but the *real* bug is that the Font class is using strings to
represent quantities rather than numbers.
If the string `huge dangles' appeared at random (and I am assuming
that I didn't deliberately enter that string myself as either part of
the program or part of the input), I'd immediately grep for it to find
out where on earth it came from.
Joe Marshall wrote:
> I approach debugging completely differently, then.
Yes. I think this is the real underlying difference here. I've completely
changed the way that I debug since moving to static typing. Most of the
bugs that I fix are found by the static type checker (although the
proportion is very application dependent, e.g. I'm getting a lot more
dynamic bugs in my GUI code). But I do still look at run-time values
occasionally.
> ...
> If the string `huge dangles' appeared at random (and I am assuming
> that I didn't deliberately enter that string myself as either part of
> the program or part of the input), I'd immediately grep for it to find
> out where on earth it came from.
Interesting. Perhaps the difference is in application rather than anything
to do with typing or languages. The vast majority of values flying around
inside my programs might as well be random. It would take me a lot longer
to work out why "v12" happens to equal 7.245745 than it would to find out
why I had added an int to a string.
My ray tracer, for example, is not unrepresentative of the code that I
write. If you break the typing of that program just about anywhere, the
run-time values that you would get are irrelevant.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Ok. If I wrote a 2 page program I wouldn't assert that it was wrong. If the
> static type checker was happy with it then I'd assert that it was probably
> right.
int fact (int i) {
if (i==0) {
return 1;
} else {
return i * fact(i);
}
}
The type checker is perfectly happy. :)
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> Jon Harrop <······@jdh30.plus.com> writes:
>
>> Ok. If I wrote a 2 page program I wouldn't assert that it was wrong. If the
>> static type checker was happy with it then I'd assert that it was probably
>> right.
>
> int fact (int i) {
> if (i==0) {
> return 1;
> } else {
> return i * fact(i);
> }
> }
>
> The type checker is perfectly happy. :)
I like this example:
(defun sort (x predicate)
x)
From: Duane Rettig
Subject: Re: What's so great about lisp?
Date:
Message-ID: <4br24hacw.fsf@franz.com>
Joe Marshall <·········@alum.mit.edu> writes:
> ···@sevak.isi.edu (Thomas A. Russ) writes:
>
>> Jon Harrop <······@jdh30.plus.com> writes:
>>
>>> Ok. If I wrote a 2 page program I wouldn't assert that it was wrong. If the
>>> static type checker was happy with it then I'd assert that it was probably
>>> right.
>>
>> int fact (int i) {
>> if (i==0) {
>> return 1;
>> } else {
>> return i * fact(i);
>> }
>> }
>>
>> The type checker is perfectly happy. :)
>
> I like this example:
>
> (defun sort (x predicate)
> x)
Not a good example - Even if you were to rename the function
so as not to redefine a Common Lisp function (for those lisps
which protect themselves), all the CLs I know of will generate
a warning anyway when the function is compiled. Does that
constitute a type checker failure?
--
Duane Rettig ·····@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
Joe Marshall wrote:
> I like this example:
>
> (defun sort (x predicate)
> x)
Is that:
let sort x predicate = x
So you're looking for a warning because "predicate" was bound but never
used?
I've been looking at how many of the errors that I make are caught by the
static type checker and how many require debugging. I must say that the
vast majority are caught at compile time.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Joe Marshall wrote:
>> I like this example:
>>
>> (defun sort (x predicate)
>> x)
>
> Is that:
>
> let sort x predicate = x
>
> So you're looking for a warning because "predicate" was bound but never
> used?
No, I wanted a warning that the output isn't sorted.
Yeah, I expect a warning that predicate isn't used, and of course I
can't redefine the built-in sort, but that's not the point.
Joe Marshall wrote:
> No, I wanted a warning that the output isn't sorted.
>
Why Dependent Types Matter
http://www.cs.nott.ac.uk/~txa/publ/ydtm.pdf
In this article we exhibit the rationale behind Epigram's design,
using refinements of a well known program --merge sort-- as a running
example. Our starting point is the implementation shown in Figure 1: it
is written in Epigram, but it could have been written in any functional
language. We start by revisiting the question of totality versus
partiality in section 3, showing how sort can be made structurally
recursive. Section 4 continues by addressing the problem of how to
maintain static invariants which is illustrated by implementing a sized
sort. In section 5 we how to use dependent types to maintain static
invariants about dynamic data, which is illustrated by implementing a
version of sort which certifies that its output is in order.
Joe Marshall wrote:
> No, I wanted a warning that the output isn't sorted.
Ah, ok. I don't contest that. However, the question is "how likely are you
to write those kinds of errors"? I don't think we can answer question that
to anyone's satisfaction.
> Yeah, I expect a warning that predicate isn't used, and of course I
> can't redefine the built-in sort, but that's not the point.
You don't even get a warning in OCaml BTW.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Joe Marshall wrote:
>> No, I wanted a warning that the output isn't sorted.
>
> Ah, ok. I don't contest that. However, the question is "how likely are you
> to write those kinds of errors"? I don't think we can answer question that
> to anyone's satisfaction.
I think we can. We would need to quantify what you mean by
`likelihood', nail down specifically `those kind of errors', and
develop a criteria for `satisfaction'.
Joe Marshall wrote:
> I think we can. We would need to quantify what you mean by
> `likelihood', nail down specifically `those kind of errors', and
> develop a criteria for `satisfaction'.
I am unsatisfied already. It would be easier to unify physics, IMHO. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Joe Marshall wrote:
>> I think we can. We would need to quantify what you mean by
>> `likelihood', nail down specifically `those kind of errors', and
>> develop a criteria for `satisfaction'.
>
> I am unsatisfied already. It would be easier to unify physics, IMHO. :-)
The real issue is not about static vs. dynamic typing. I don't think
anyone in their right mind would object to the computer automatically
finding errors as soon as possible. There are actually two issues
that are of interest:
1. How much does the computer interfere with the task at hand when
it discovers errors, and
2. How willing is the programmer to change his style to aid (or
conform to) the computer's static checking.
`Strong-arm' type checking appears to be a popular choice in the
static typing camp. In this model, it is not possible to compile a
program until the type checker is satisfied that the program is free
from type errors. While it is true that once the program compiles it
will not have type errors (a trivial tautology), it can seriously
interfere with interactive development. When developing
interactively, it doesn't matter whether the untaken branch is type
safe. Being forced to write type-safe `stubs' that won't be executed
is simply useless busywork.
Static typing with inference and all the modern amenities is a far
cry from the static typing found in C or Java. Nonetheless, there are
programs that the type checker cannot prove correct, or cannot prove
correct without assistance from the programmer. The programmer must
either provide hints to the type checker *or* modify his programming
style to avoid constructs that will stymie the type checker. Some
people don't mind doing this because they percieve a real benefit to
satisfying the type checker.
Personally, I want as much static checking as possible provided that
it *never* rejects a program, even one that is provably wrong (it
should compile to a call to the runtime error handler!), never
complains when it cannot determine if the program is type safe, and
requires exactly *zero* effort on my part to use. I may be willing to
provide type hints and guarantees at some point of development, but I
never want the computer to force me to do so *before* I am ready.
Joe Marshall wrote:
> The real issue is not about static vs. dynamic typing. I don't think
> anyone in their right mind would object to the computer automatically
> finding errors as soon as possible. There are actually two issues
> that are of interest:
>
> 1. How much does the computer interfere with the task at hand when
> it discovers errors, and
>
> 2. How willing is the programmer to change his style to aid (or
> conform to) the computer's static checking.
Similarly:
How many errors can be fixed more quickly by exploiting static type
checking?
How difficult is it to learn how to exploit static type checking?
How effective is static type checking at forcing the programmer to provide
machine-checked interface definitions?
Also:
What functionality is lost in the trade with static type checking (e.g. type
safe marshalling, dynamically typed printing, multiple or ad-hoc
polymorphic arithmetic operators)?
> `Strong-arm' type checking appears to be a popular choice in the
> static typing camp. In this model, it is not possible to compile a
> program until the type checker is satisfied that the program is free
> from type errors.
SML and OCaml tend not to reject programs with incomplete pattern matches,
IIRC. Are those type errors?
> While it is true that once the program compiles it
> will not have type errors (a trivial tautology), it can seriously
> interfere with interactive development. When developing
> interactively, it doesn't matter whether the untaken branch is type
> safe. Being forced to write type-safe `stubs' that won't be executed
> is simply useless busywork.
Yes.
> Static typing with inference and all the modern amenities is a far
> cry from the static typing found in C or Java. Nonetheless, there are
> programs that the type checker cannot prove correct, or cannot prove
> correct without assistance from the programmer. The programmer must
> either provide hints to the type checker *or* modify his programming
> style to avoid constructs that will stymie the type checker. Some
> people don't mind doing this because they percieve a real benefit to
> satisfying the type checker.
Yes.
> Personally, I want as much static checking as possible provided that
> it *never* rejects a program, even one that is provably wrong (it
> should compile to a call to the runtime error handler!),
and give a warning?
> never complains when it cannot determine if the program is type safe,
You don't even want a warning that a program may be type-unsafe?
> and requires exactly *zero* effort on my part to use.
This seems like a silly criterion to me. Static type checkers clearly save
some programmer effort. If the overall result is that you have to do less
work, why reject it?
> I may be willing to
> provide type hints and guarantees at some point of development, but I
> never want the computer to force me to do so *before* I am ready.
Ok.
Like you, I want as much static type checking as possible but I don't care
if it rejects code deemed to be incorrect provided it accepts most of my
correct code. I don't mind learning about type inference and checking, and
coercing my programming style to fit in with static typing provided that
the resulting code remains concise and the additional functionality allows
me to prove that parts of my production code cannot produce run-time errors
(an otherwise infeasible task).
I am particularly keen to avoid deciphering stack traces whenever possible.
That takes a long time and requires me to write a lot more code so I am
willing to go to some lengths to detect errors at compile time.
Also, I want to be able to choose between explicitly declared types and
inferred types (e.g. records vs tuples and variants vs polymorphic variants
in OCaml).
During development, I don't find myself fixing type errors in unused
functions so that doesn't bother me.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
From: Alexander Schmolck
Subject: Re: What's so great about lisp?
Date:
Message-ID: <yfswtkq8vdt.fsf@gmx.net>
Jon Harrop <······@jdh30.plus.com> writes:
> I am particularly keen to avoid deciphering stack traces whenever possible.
> That takes a long time and requires me to write a lot more code so I am
> willing to go to some lengths to detect errors at compile time.
That dichotomy seems bogus to me -- why would a good implementation of a
dynamic language force you to expend effort to decipher stack traces and write
lots of extra code?
What's so bad with ending up in a nice interactive debugger in which moving up
and down the frames etc. displays the corresponding source code in your editor
and where you can ideally see the state of all relevant variables at a glance?
You should be able to investigate the error conveniently and test hypothesises
directly by entering code -- possibly even fix the problem on the fly -- and
in many cases this seems rather preferable to me to having to figure out in a
largely unassisted fashion were some non-obvious compile time type error came
from.
'as
Alexander Schmolck wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> I am particularly keen to avoid deciphering stack traces whenever
>> possible. That takes a long time and requires me to write a lot more code
>> so I am willing to go to some lengths to detect errors at compile time.
>
> That dichotomy seems bogus to me -- why would a good implementation of a
> dynamic language force you to expend effort to decipher stack traces and
> write lots of extra code?
If I get a run-time error then I am likely to need to examine the program's
state in order to fix the error. Whether or not the language is dynamic is
irrelevant.
> What's so bad with ending up in a nice interactive debugger in which
> moving up and down the frames etc. displays the corresponding source code
> in your editor and where you can ideally see the state of all relevant
> variables at a glance?
I can rarely comprehend the contents of my variables without machine
assistance. So, if I am forced to study program state then I must write
more programs to decipher that state.
> this seems rather preferable to me to having to figure out in a largely
> unassisted fashion were some non-obvious compile time type error came
> from.
This last bit seems to be based upon a misunderstanding of static typing.
Firstly, deciphering a stack trace after a run-time error has nothing to do
with static vs dynamic typing unless a static type system could have proven
that you will never get such a run-time error, in which case you wouldn't
have needed to resort to examining the program's state.
Secondly, static type errors are not studied in a "largely unassisted
fashion". For a start, you have inferred types to help you.
Thirdly, static type errors are inherently easier to fix than run-time
errors because static type systems tend to be much simpler than running
programs. So static type errors are rarely "non-obvious". I doubt I have
ever spent >60secs fixing a static type error but I often spend days fixing
run-time errors. Certainly, there are run-time errors that I have never
fixed but I have never been unable to fix a static type error.
Ultimately, you can choose to write in a statically or dynamically typed
style in a statically typed language. I choose to exploit the static type
checker because it makes development much easier. For example, if a section
of code only ever handles a list containing exactly four elements then I
would use a 4-tuple instead of a list. The static type checker would then
statically prove that none of the code handling the 4-tuple could cause a
run-time error because there were too few or too many values.
Unlike Joe, I am willing to put in quite a bit of effort in order to make
these assurances to my users.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Ultimately, you can choose to write in a statically or dynamically typed
> style in a statically typed language. I choose to exploit the static type
> checker because it makes development much easier. For example, if a section
> of code only ever handles a list containing exactly four elements then I
> would use a 4-tuple instead of a list. The static type checker would then
> statically prove that none of the code handling the 4-tuple could cause a
> run-time error because there were too few or too many values.
>
> Unlike Joe, I am willing to put in quite a bit of effort in order to make
> these assurances to my users.
I've never discussed what effort I'm willing to put in for the users
of my code. I'm not willing to put in *any* effort during development
because it is a premature optimization. However, once the code is
stable and I *know* what is going on I then consider how to ensure
that the code is used correctly. This includes declamations of
function types, DEFTYPES, CHECK-TYPE expressions etc. In addition, I
shadow some of the standard Common Lisp symbols to provide `safer'
versions. (As an example, I have my own version of COND that
complains if there is no `catch-all' clause.) I have at times written
meta-code that walks the other code and performs custom static checks.
Joe Marshall wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> Unlike Joe, I am willing to put in quite a bit of effort in order to make
>> these assurances to my users.
>
> I've never discussed what effort I'm willing to put in for the users
> of my code. I'm not willing to put in *any* effort during development
Surely the effort you put in during development is for your users?
> because it is a premature optimization.
You mean it is unnecessary?
> However, once the code is
> stable and I *know* what is going on I then consider how to ensure
> that the code is used correctly. This includes declamations of
> function types, DEFTYPES, CHECK-TYPE expressions etc. In addition, I
> shadow some of the standard Common Lisp symbols to provide `safer'
> versions. (As an example, I have my own version of COND that
> complains if there is no `catch-all' clause.) I have at times written
> meta-code that walks the other code and performs custom static checks.
Ok. That sounds like quite a bit of work!
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Joe Marshall wrote:
> > I've never discussed what effort I'm willing to put in for the users
> > of my code. I'm not willing to put in *any* effort during development
>
> Surely the effort you put in during development is for your users?
I guess so - but isn't this an even better reason to not waste the
time?
Jon Harrop wrote:
> Joe Marshall wrote:
> > because it is a premature optimization.
>
> You mean it is unnecessary?
No /premature/ - there _is_ a difference! ;-)
Jon Harrop wrote:
> Joe Marshall wrote:
> > However, once the code is
> > stable and I *know* what is going on I then consider how to ensure
> > that the code is used correctly. This includes declamations of
> > function types, DEFTYPES, CHECK-TYPE expressions etc. In addition, I
> > shadow some of the standard Common Lisp symbols to provide `safer'
> > versions. (As an example, I have my own version of COND that
> > complains if there is no `catch-all' clause.) I have at times written
> > meta-code that walks the other code and performs custom static checks.
>
> Ok. That sounds like quite a bit of work!
One can automate and reuse alot of this stuff.
Jochen Schmidt
Jon Harrop wrote:
> Joe Marshall wrote:
> > However, once the code is
> > stable and I *know* what is going on I then consider how to ensure
> > that the code is used correctly.
>
> Ok. That sounds like quite a bit of work!
Since it's exactly the work that static typing requires on ALL code,
the only difference being the name of the tokens involved, Harrop's
objection is "curious".
Marshall only did that work on the end product (and parts at that),
so he's ahead of the game.
However, once again I'll ask what Harrop hopes to accomplish with
his advocacy of static typing in comp.lang.lisp . Surely he's figured
out by now that we understand static typing quite well. Yes, we've
rejected his conclusion, but hasn't his persistence become rude?
-andy
······@earthlink.net wrote:
> Jon Harrop wrote:
>> Ok. That sounds like quite a bit of work!
>
> Since it's exactly the work that static typing requires on ALL code...
Of course not, you don't need to write your own type checker...
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> ······@earthlink.net wrote:
> > Jon Harrop wrote:
> >> Ok. That sounds like quite a bit of work!
> >
> > Since it's exactly the work that static typing requires on ALL code...
>
> Of course not, you don't need to write your own type checker...
Who said anything about writing a type checker? Marshall isn't
writing one - he's using the one that Common Lisp provides.
Note that Marshall actually goes beyond type checking to enforcing
coding-standards. That does require code beyond that for
type-checking,
but he's getting something that type checking doesn't give him.
······@earthlink.net wrote:
> Jon Harrop wrote:
>> ······@earthlink.net wrote:
>> > Jon Harrop wrote:
>> >> Ok. That sounds like quite a bit of work!
>> >
>> > Since it's exactly the work that static typing requires on ALL code...
>>
>> Of course not, you don't need to write your own type checker...
>
> Who said anything about writing a type checker? Marshall isn't
> writing one - he's using the one that Common Lisp provides.
Joe said:
"I have my own version of COND that complains if there is no `catch-all'
clause"
and:
"meta-code that walks the other code and performs custom static checks."
ML does the former test with much more generality, of course.
> Note that Marshall actually goes beyond type checking to enforcing
> coding-standards. That does require code beyond that for type-checking,
That depends upon your definition of "type". Some people seem to include
anything and everything in their definition...
> but he's getting something that type checking doesn't give him.
Different type systems provide different functionality. I think that is the
real issue here. Joe says it is worthwhile writing your own static checkers
in Lisp. However, I'd wager that most programmers could not do this or, at
least, it would take them so long that it wouldn't be worth doing. It would
certainly take me a long time to write an OCaml type checker, for example.
The next question is, how well does a given type system fit what you
actually need? If OCaml's type system can't be used to do the static checks
that Joe needs then there's no point in him trying to use it for that. I
sometimes write my code in a different style just to exploit the type
checker. So there is a trade-off between altering your code and writing
your own type checker. I don't think it is clear when/if each is a win.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Joe said:
>
> "I have my own version of COND that complains if there is no `catch-all'
> clause"
Which isn't type checking....
> ML does the former test with much more generality, of course.
If with no else isn't legal ML? How lame.
As I've asked - why is Harrop RUDELY bothering with the lisp heathens?
They clearly don't appreciate his wisdom.
> I think that is the real issue here. Joe says it is worthwhile writing
> your own static checkers
And he's correct because he's working in a language that makes it easy
to write static checkers. He can even write domain or context-specific
static-checkers. First-class syntax does have some advantages.
But, ML is the perfect language. Harrop should keep quiet before the
rest of us figure that out. Or, he should keep quiet because we'd
spoil it with our grubby fingrs. Or he should keep quiet because we
don't deserve it.
-andy
······@earthlink.net wrote:
> Jon Harrop wrote:
>> Joe said:
>>
>> "I have my own version of COND that complains if there is no `catch-all'
>> clause"
>
> Which isn't type checking....
It is static checking.
>> ML does the former test with much more generality, of course.
>
> If with no else isn't legal ML? How lame.
It is in OCaml, for example:
$ ocaml
Objective Caml version 3.08.0
# if true then ();;
- : unit = ()
>> I think that is the real issue here. Joe says it is worthwhile writing
>> your own static checkers
>
> And he's correct because he's working in a language that makes it easy
> to write static checkers. He can even write domain or context-specific
> static-checkers. First-class syntax does have some advantages.
Yes. When implementing static checking, a static type checker has some
advantages too.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> ······@earthlink.net wrote:
> > Which isn't type checking....
>
> It is static checking.
The fact that an ox can tow a thousand pounds isn't all that relevant
when discussing how much a dog can tow.
> >> ML does the former test with much more generality, of course.
> >
> > If with no else isn't legal ML? How lame.
>
> It is in OCaml, for example:
In other words, OCaml doesn't have the static check that Marshall
wants.
I suppose that there might be a *L language that satisfies Marshall's
requirements for one project, or at least one part of one project, but
why should he have to use different languages for different projects
or for different parts of the same project? Oh, to get some static
checks that he could easily write in Lisp.
That's why second-class syntax is such a great idea.
> Yes. When implementing static checking, a static type checker has some
> advantages too.
Actually, a static type checker is only a small part of what one needs
for a static checker. And Lisp has a static type checker. It's use
is optional. That lets folks use it when it helps and ignore it when
it
doesn't.
BTW - I gave Harrop an unjustified pass wrt ifs without elses. His
OCaml
example demonstrates that you can't rely on the provided static
checking.
Marshall's code has the virtue of actually checking the desired
condition.
Yes, ML is perfect and we heathens should be exposed to it.
······@earthlink.net wrote:
> Jon Harrop wrote:
>> > If with no else isn't legal ML? How lame.
>>
>> It is in OCaml, for example:
>
> In other words, OCaml doesn't have the static check that Marshall
> wants.
Your example was purely syntactic. It has nothing to do with type checking.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> ······@earthlink.net wrote:
> > Jon Harrop wrote:
> >> > If with no else isn't legal ML? How lame.
> >>
> >> It is in OCaml, for example:
> >
> > In other words, OCaml doesn't have the static check that Marshall
> > wants.
>
> Your example was purely syntactic. It has nothing to do with type checking.
I never wrote that it did have anything to do with type checking. I
wrote
that it was a static check that Marshall wanted in certain
circumstances.
One of the other Harrops claimed that the relevant check was possible
in
some *L language, but ducked the "can it be used without altering
source"
question.
I'll repeat my question - why is Harrop bothering with the Lisp
heathen?
Could it be that he's worn out his welcome in the *L world?
Oh, and he's wrong about the overlap between the static and dynamic
checking camps. The vast majority of the dynamic checking folk
have a lot of experience with static checking. The converse is
not true.
In other words, we know about static checkers. That's why we like to
have dynamic ones. And we have static ones.
Jon Harrop wrote:
> Joe said:
>
> "I have my own version of COND that complains if there is no `catch-all'
> clause"
>
> and:
>
> "meta-code that walks the other code and performs custom static checks."
>
> ML does the former test with much more generality, of course.
Can you make the ML compiler check other properties than types statically?
If not, then what do you mean by "much more generality"?
--
Jens Axel S�gaard
Jens Axel S�gaard wrote:
> > "I have my own version of COND that complains if there is no `catch-all'
> > clause"
>
> Can you make the ML compiler check other properties than types statically?
This goes back to "what is a type?". You can use ML's static type checker to
check a few things that most people might not regard as types (e.g. phantom
types). There are also many languages with more sophisticated type systems
that can represent and statically check lots of much more complicated
constraints, e.g. Haskell and theorem provers such a Coq.
> If not, then what do you mean by "much more generality"?
In this case, ML doesn't just check for a catch-all clause, it tries to
prove that the given clauses match all possibilities. For example, you can
match over an empty or non-empty list:
# let rec map f = function
| [] -> []
| h :: t -> f h :: map f t;;
val map : ('a -> 'b) -> 'a list -> 'b list = <fun>
The compiler understands that these two clauses cover all possible lists so
it doesn't give a warning. In this case, you could have written the pattern
match with a catch-all clause:
# let rec map f = function
| h :: t -> f h :: map f t;;
| _ -> []
val map : ('a -> 'b) -> 'a list -> 'b list = <fun>
However, in most cases you can (and want to!) eliminate the catch-all
clauses when they are a source of run-time errors. Also, pattern matching
is the only way to extract the data associated with a variant type
constructor. For example, you cannot rearrange this pattern match from my
ray tracer in order to replace the last clause with a catch-all because
both clauses extract data from the given value (either a Sphere or a
Group):
let rec aux ((l, _) as first) = function
Sphere (center, radius) ->
let l' = ray_sphere orig dir center radius in
if l' >= l then first else
l', unitise (orig +| l' *| dir -| center)
| Group (center, radius, scenes) ->
let l' = ray_sphere orig dir center radius in
if l' >= l then first else List.fold_left aux first scenes
Unlike SML, the situation is slightly more complicated in OCaml due to the
ability to guard patterns with an arbitrary function. The compiler is then
conservative when checking guarded patterns (i.e. it assumes that they may
not match). For example, it cannot prove that these two clauses cover all
eventualities, so it criticises your style:
# let f = function
| n when n = 0 -> 0
| n when n <> 0 -> 1;;
Warning: Bad style, all clauses in this pattern-matching are guarded.
val f : int -> int = <fun>
The testing of patterns really comes into its own when you're doing
complicated manipulations of trees, e.g. in a compiler. In this case, the
ability of the compiler to spot redundant or missing clauses (and give
examples) is very useful.
I'm not sure how pattern match testing is classified by computer scientists.
It is certainly a form of static checking but it is probably not static
type checking.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> In this case, ML doesn't just check for a catch-all clause, it tries to
> prove that the given clauses match all possibilities.
That's actually why I wrote a COND that requires catch-all clauses. I
encountered code that I didn't write and that didn't have an else
clause. It was not clear to me whether the author of the code had
thought that he had an exhaustive partition of the cases, whether he
wanted to return NIL if it wasn't exhaustive, or whether he hadn't
noticed the problem. By requiring the author to supply a catch-all
case, the intent becomes clear:
(cond ((condition1) ...)
((condition2) ...)
(t (error "This shouldn't happen!")))
(cond ((condition1) ...)
((condition2) ...)
(t nil))
In theory, if the partition is exhastive, the catch-all clause is
eliminated as dead-code.
> For example, you can
> match over an empty or non-empty list:
>
> # let rec map f = function
> | [] -> []
> | h :: t -> f h :: map f t;;
> val map : ('a -> 'b) -> 'a list -> 'b list = <fun>
>
> The compiler understands that these two clauses cover all possible lists so
> it doesn't give a warning.
Yes, but did the author understand it? We don't know.
Joe Marshall wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> In this case, ML doesn't just check for a catch-all clause, it tries to
>> prove that the given clauses match all possibilities.
>
> That's actually why I wrote a COND that requires catch-all clauses. I
> encountered code that I didn't write and that didn't have an else
> clause. It was not clear to me whether the author of the code had
> thought that he had an exhaustive partition of the cases, whether he
> wanted to return NIL if it wasn't exhaustive, or whether he hadn't
> noticed the problem. By requiring the author to supply a catch-all
> case, the intent becomes clear:
>
> (cond ((condition1) ...)
> ((condition2) ...)
> (t (error "This shouldn't happen!")))
>
> (cond ((condition1) ...)
> ((condition2) ...)
> (t nil))
>
> In theory, if the partition is exhastive, the catch-all clause is
> eliminated as dead-code.
Interesting. So the ML equivalents would be:
match t with
| pat1 -> expr1
| pat2 -> expr2
if the compiler was happy that pat1 and pat2 covered all eventualities, or:
match t with
| pat1 -> expr1
| pat2 -> expr2
| _ -> invalid_arg "foo"
if it wasn't. I am constantly trying to go the other way, to leverage the
static checker into proving that the "invalid_arg" is redundant and cannot
be a source of run-time errors.
In the latter case, you'd probably have to wrap the result in an option type
to mimic dynamic typing:
match t with
| pat1 -> Some expr1
| pat2 -> Some expr2
| _ -> None
>> For example, you can
>> match over an empty or non-empty list:
>>
>> # let rec map f = function
>> | [] -> []
>> | h :: t -> f h :: map f t;;
>> val map : ('a -> 'b) -> 'a list -> 'b list = <fun>
>>
>> The compiler understands that these two clauses cover all possible lists
>> so it doesn't give a warning.
>
> Yes, but did the author understand it? We don't know.
Well, I'd say that I definitely understand it in the code that I write. When
I study other people's code it is usually obvious that all eventualities
are covered because the patterns are just all constructors of a given
variant type (or implicitly covered because the patterns imply all of the
constructors of a type-inferred polymorphic variant).
I can't remember having difficulty with other people's code in this way.
That's not to say that my memory isn't failing though. ;-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Jens Axel S�gaard wrote:
>
>>>"I have my own version of COND that complains if there is no `catch-all'
>>>clause"
>>
>>Can you make the ML compiler check other properties than types statically?
>
> This goes back to "what is a type?". You can use ML's static type checker to
> check a few things that most people might not regard as types (e.g. phantom
> types). There are also many languages with more sophisticated type systems
> that can represent and statically check lots of much more complicated
> constraints, e.g. Haskell and theorem provers such a Coq.
Can these properties be checked without any alterations of the program?
(Which Marshall so cleverly avoided)
>>If not, then what do you mean by "much more generality"?
>
> In this case, ML doesn't just check for a catch-all clause, it tries to
> prove that the given clauses match all possibilities.
Sorry - I think I cut a little too much context here. It was the
generality of the type of static checking I was refering to - and
in specific what kind of facilitites for custom static checking the user
can use.
> For example, you can match over an empty or non-empty list:
> # let rec map f = function
> | [] -> []
> | h :: t -> f h :: map f t;;
> val map : ('a -> 'b) -> 'a list -> 'b list = <fun>
I agree that the static checking of patterns is very nice. It is
a specific example, where static checking shines. It say
anything about the generality of user defined static checking
though.
In my implementation of choice pattern matching
is available through a library:
> (require (lib "plt-match.ss"))
> (define (map f l)
(match l
['() ()]
[(cons h t) (cons (f h) (map f t))]))
> (map odd? (list 1 2 3))
(#t #f #t)
As is some static checks are done:
> (define (map f l)
(match l
[foo ()]
[(cons h t) (cons (f h) (map f t))]))
Warning: unreachable match clause ((cons h t) (cons (f h) (map f t))) in
(match l (foo ()) ((cons h t) (cons (f h) (map f t))))
The author of plt-match.ss decided which static checkes were to be done.
Extending it so it makes the same "exhaustion" check as in ML would
be no more difficult than it was to implement pattern matching in ML.
Whether or not this is have been done not affect the generality of user
controlled static checking in the language.
--
Jens Axel S�gaard
Jens Axel S�gaard wrote:
> Jon Harrop wrote:
>> Jens Axel S�gaard wrote:
>>
>>>>"I have my own version of COND that complains if there is no `catch-all'
>>>>clause"
>>>
>>>Can you make the ML compiler check other properties than types
>>>statically?
>>
>> This goes back to "what is a type?". You can use ML's static type checker
>> to check a few things that most people might not regard as types (e.g.
>> phantom types). There are also many languages with more sophisticated
>> type systems that can represent and statically check lots of much more
>> complicated constraints, e.g. Haskell and theorem provers such a Coq.
>
> Can these properties be checked without any alterations of the program?
For my ML programming, I think I am too biased to give a decent answer to
that. Most of my code is statically type checked without my consciously
having to program in a particular style. When I want to leverage the type
checker to eliminate more source of run-time errors, I have to think about
it. However, this may be because I have grown accustomed to static type
checking.
In the case of languages with more powerful type systems, I have no real
experience of them but I believe they theoretically can require type
annotations to help them but, with Haskell for example, I am told that most
code doesn't need to contain type annotations (i.e. you only specify them
when you are exploiting that functionality).
> (Which Marshall so cleverly avoided)
Although there are many useful cases where you can (most cases?), I do not
believe you can avoid doing so in general - sooner or later the type
checker is going to need human intervention when trying to prove something
too complicated.
>>>If not, then what do you mean by "much more generality"?
>>
>> In this case, ML doesn't just check for a catch-all clause, it tries to
>> prove that the given clauses match all possibilities.
>
> Sorry - I think I cut a little too much context here.
Ok. When I said "much more generality" I was referring specifically to
checked pattern matches.
> It was the
> generality of the type of static checking I was refering to - and
> in specific what kind of facilitites for custom static checking the user
> can use.
The most common technique I use is to replace constant- but arbitrary-length
containers (e.g. lists) with statically-sized containers (e.g. tuples).
That removes lots of catch-all clauses that are sources of run-time errors,
i.e. you end up replacing code like:
let f = function
| [a; b] -> ...
| _ -> invalid_arg "f"
with code like:
let f (a, b) = ...
In the latter case, the compiler forces you to pass only 2-tuples to the
function "f".
I used this approach in my GUI code to replace lists containing 1-4 elements
with tuples:
a
(a, b)
(a, (b, c))
(a, (b, (c, d)))
Then I factored out HOFs that deal with 2-tuples representing heads and
tails of fixed-size lists.
Previously, I had been using dynamic checking, generating run-time errors
via catch-all clauses. That was phenomenally tedious. Although leveraging
the built-in static checking took quite a bit of design and implementation,
it eliminated lots of bugs that would have taken me a lot longer to find
via dynamic checking.
>> For example, you can match over an empty or non-empty list:
>> # let rec map f = function
>> | [] -> []
>> | h :: t -> f h :: map f t;;
>> val map : ('a -> 'b) -> 'a list -> 'b list = <fun>
>
> I agree that the static checking of patterns is very nice. It is
> a specific example, where static checking shines. It say
> anything about the generality of user defined static checking
> though.
To statically check Lisp, you implement your own static checker. To
statically check a statically typed language, you'd first try to leverage
the existing checker. Only if that wasn't possible would you resort to
implementing your own checker.
So the question is - can your user-defined static checking be "fitted into"
an existing static checker? If so, your life will be much easier. If not
and you're using a statically typed language with a complicated syntax,
your life will be much harder.
> In my implementation of choice pattern matching is available through a
> library:
>
> > (require (lib "plt-match.ss"))
> > (define (map f l)
> (match l
> ['() ()]
> [(cons h t) (cons (f h) (map f t))]))
> > (map odd? (list 1 2 3))
> (#t #f #t)
>
> As is some static checks are done:
>
> > (define (map f l)
> (match l
> [foo ()]
> [(cons h t) (cons (f h) (map f t))]))
> Warning: unreachable match clause ((cons h t) (cons (f h) (map f t))) in
> (match l (foo ()) ((cons h t) (cons (f h) (map f t))))
>
> The author of plt-match.ss decided which static checkes were to be done.
> Extending it so it makes the same "exhaustion" check as in ML would
> be no more difficult than it was to implement pattern matching in ML.
Yes, and pattern matching implementations in ML compilers are hard. Type
checkers are typically much harder (e.g. OCaml's, let alone Haskell's).
> Whether or not this is have been done not affect the generality of user
> controlled static checking in the language.
Yes.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Ingvar <······@hexapodia.net> writes:
>> Joe said:
>>
>> "I have my own version of COND that complains if there is no `catch-all'
>> clause"
>
> Well, as far as coding goes, it's Not Very Complicated (I'd say about
> six lines of code, in semi-nice formatting):
>
> (defmacro econd (&rest clauses)
> (let ((last-clause (first (last clauses))))
> (let ((last-test (first last-clause)))
> (if (and (constantp last-test) (not (null last-test)))
> `(cond ,@clauses)
> (error "Missing catch-all clause in (econd ~a)" clauses)))))
>
> * (econd ((= n 3) 'true))
>
> debugger invoked on a SIMPLE-ERROR in thread 575:
> Missing catch-all clause in (econd (((= N 3) 'TRUE)))
>
>
> * (econd ((= n 3) 'true) (t 'false))
>
> TRUE
>
> * (econd ((= n 3) 'true) (nil 'signal-error))
>
> debugger invoked on a SIMPLE-ERROR in thread 575:
> Missing catch-all clause in (econd (((= N 3) 'TRUE) (NIL 'SIGNAL-ERROR)))
I also added the `=>' hack that Scheme has. If the second element in
a COND clause is a symbol whose name is string-equal to "=>", then the
clause must have exactly three elements: the first being the
predicate, the second the =>, and the third a procedure of exactly one
argument that is invoked on the result of the predicate.
(cond ((position-if #'oddp '(2 3 4)) => #'print)
(t (format t "Not found")))
prints 1
Ingvar <······@hexapodia.net> writes:
> An anaphoric cond? Well, it shouldn't be *much* harder (though it'd
> require "more" checking of the clauses list).
It turned out to be a little tricky getting the scoping right if
the receiving clause was a literal lambda expression.
Jon Harrop <······@jdh30.plus.com> writes:
> Joe Marshall wrote:
>> Jon Harrop <······@jdh30.plus.com> writes:
>>> Unlike Joe, I am willing to put in quite a bit of effort in order to make
>>> these assurances to my users.
>>
>> I've never discussed what effort I'm willing to put in for the users
>> of my code. I'm not willing to put in *any* effort during development
>
> Surely the effort you put in during development is for your users?
Not necessarily. When I'm trying to figure out how to solve a problem
I often write a lot of code just to get a handle on what the problem
is about. I throw a lot of it away.
To give an example, I was working on a `diff' program a few years ago.
It went through *many* iterations before I was happy with it. The
final code has things like this:
(deftype rectilinear-row-index ()
`(integer 0 ,(floor array-dimension-limit 2)))
(deftype rectilinear-column-index ()
`(integer 0 ,(floor array-dimension-limit 2)))
(deftype diagonal-row-index ()
`(integer ,(- (floor array-dimension-limit 2))
,(floor array-dimension-limit)))
(deftype diagonal-column-index ()
`(integer 0 ,array-dimension-limit))
;; Convert from rectilinear row and column to
;; diagonal row and column.
(declaim (ftype (function (rectilinear-row-index rectilinear-column-index)
(values diagonal-row-index diagonal-column-index))
rect->diag)
(ftype (function (diagonal-row-index diagonal-column-index)
(values rectilinear-row-index rectilinear-column-index))
diag->rect)
(inline rect->diag)
(inline diag->rect))
(defun rect->diag (row col)
(declare (type rectilinear-row-index row)
(type rectilinear-column-index col)
#.(performance-optimizations))
(values (- row col) (+ row col)))
(defun diag->rect (diag-row diag-col)
(declare (type diagonal-row-index diag-row)
(type diagonal-column-index diag-col)
#.(performance-optimizations))
(values (ash (+ diag-col diag-row) -1)
(ash (- diag-col diag-row) -1)))
But in a much earlier version, I have code like this:
(defun D (row col row-content col-content gamma)
(cond ((= row 0) (values col (make-list col :initial-element :insert)))
((= col 0) (values row (make-list row :initial-element :delete)))
(t (multiple-value-bind (drep prep)
(D (- row 1) (- col 1) row-content col-content gamma)
(multiple-value-bind (ddel pdel)
(D (- row 1) col row-content col-content gamma)
(multiple-value-bind (din pin)
(D row (- col 1) row-content col-content gamma)
(let ((crep (+ drep (funcall gamma
(funcall row-content (- row 1))
(funcall col-content (- col 1)))))
(cdel (+ ddel (funcall gamma
(funcall row-content (- row 1))
*epsilon*)))
(cin (+ din (funcall gamma
*epsilon*
(funcall col-content (- col 1))))))
(cond ((and (< crep cdel) (< crep cin))
(values crep (cons :replace prep)))
((and (<= cin crep) (<= cin cdel))
(values cin (cons :insert pin)))
(t
(values cdel (cons :delete pdel)))))))))))
Note that there are no type declarations at all in this. It would
have been a complete waste of time, too, because this code doesn't
exist in the final version. Notice how the value returned by D is
just a cons cell with a keyword in the CAR. In the final version, an
`INDEL' (insertion/deletion) structure with type checking and a fancy
print function is defined.
In some sense, this is part of the development for the user, but no
one but me has ever used it.
>> because it is a premature optimization.
>
> You mean it is unnecessary?
Premature. Suppose I had gone through the effort of declaring and
checking the argument and return values? I could get the compiler to
understand and check that rows and columns are indexes into the
sequence to diff, but there is little chance of getting that wrong
because there is only a stub routine that calls this.
Once I had a satisfactory version (which is *very* different from
this), the stub routine was promoted to being one of the test routines
and I went back and put the type checks in.
Joe Marshall wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> Surely the effort you put in during development is for your users?
>
> Not necessarily. When I'm trying to figure out how to solve a problem
> I often write a lot of code just to get a handle on what the problem
> is about. I throw a lot of it away.
Yes. I do the same.
> Note that there are no type declarations at all in this. It would
> have been a complete waste of time, too, because this code doesn't
> exist in the final version.
Yes. I don't declare types unless they are useful for documentation or if
they are hairy enough that they need more checking.
>>> because it is a premature optimization.
>>
>> You mean it is unnecessary?
>
> Premature. Suppose I had gone through the effort of declaring and
> checking the argument and return values? I could get the compiler to
> understand and check that rows and columns are indexes into the
> sequence to diff, but there is little chance of getting that wrong
> because there is only a stub routine that calls this.
Yes. I'd leave declarations to type inference.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Yes. I don't declare types unless they are useful for documentation or if
> they are hairy enough that they need more checking.
Who determines "need more checking"? Marshall always makes that call
when he's writing Lisp. ML sometimes makes that call.
On code that gets thrown out, Marshall does less work with Lisp.
That's why ML is the perfect language.
······@earthlink.net wrote:
> Jon Harrop wrote:
>> Yes. I don't declare types unless they are useful for documentation or if
>> they are hairy enough that they need more checking.
>
> Who determines "need more checking"?
The programmer.
> Marshall always makes that call when he's writing Lisp.
Yes.
> ML sometimes makes that call.
No. The programmer always makes that call.
> On code that gets thrown out, Marshall does less work with Lisp.
Do you do more work on the majority of code that wouldn't get thrown out?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Do you do more work on the majority of code that wouldn't get thrown out?
I throw out the majority of my code.
Joe Marshall wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>
>> Do you do more work on the majority of code that wouldn't get thrown out?
>
> I throw out the majority of my code.
LOL. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Joe Marshall wrote:
>>However, once the code is
>>stable and I *know* what is going on I then consider how to ensure
>>that the code is used correctly. This includes declamations of
>>function types, DEFTYPES, CHECK-TYPE expressions etc. In addition, I
>>shadow some of the standard Common Lisp symbols to provide `safer'
>>versions. (As an example, I have my own version of COND that
>>complains if there is no `catch-all' clause.) I have at times written
>>meta-code that walks the other code and performs custom static checks.
>
>
> Ok. That sounds like quite a bit of work!
I hope the point is that *you* (and not the compiler) decide which
properties should be statically checked ;-)
--
Jens Axel S�gaard
Ingvar <······@hexapodia.net> writes:
>
> Well, as far as coding goes, it's Not Very Complicated (I'd say about
> six lines of code, in semi-nice formatting):
>
> (defmacro econd (&rest clauses)
> (let ((last-clause (first (last clauses))))
> (let ((last-test (first last-clause)))
> (if (and (constantp last-test) (not (null last-test)))
> `(cond ,@clauses)
> (error "Missing catch-all clause in (econd ~a)" clauses)))))
Wouldn't a more "Lispy" solution be to do something like ECASE and just
insert a final test that throws an error:
(defmacro econd (&rest clauses)
(let* ((last-clause (first (last clauses)))
(last-test (first last-clause)))
(if (and (constantp last-test) (not (null last-test)))
`(cond ,@clauses)
`(cond ,@clauses (t (error "Fell through all clauses of ECOND."))))))
That way if you write exhaustive clauses for your normal operation
you get an error message only if your "exhaustive" clauses weren't
really exhaustive.
Examples:
USER> (dolist (i '(0 1 2 3 -4))
(econd ((= i 0) (print :zip))
((> i 0) (print :something))))
:ZIP
:SOMETHING
:SOMETHING
:SOMETHING
Error: Fell through all clauses of ECOND.
Restart actions (select using :continue):
0: Return to Top Level (an "abort" restart)
1: Abort #<PROCESS Initial Lisp Listener>
[1] USER>
(dolist (i '(0 1 2 3 -4))
(econd ((= i 0) (print :zip))
((> i 0) (print :something))
((< i 0) (print :loss))))
(dolist (i '(0 1 2 3 -4))
(econd ((= i 0) (print :zip))
((> i 0) (print :something))
((< i 0) (print :loss))))
[1] USER> [1] USER>
:ZIP
:SOMETHING
:SOMETHING
:SOMETHING
:LOSS
NIL
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> Wouldn't a more "Lispy" solution be to do something like ECASE and just
> insert a final test that throws an error:
>
> (defmacro econd (&rest clauses)
> (let* ((last-clause (first (last clauses)))
> (last-test (first last-clause)))
> (if (and (constantp last-test) (not (null last-test)))
> `(cond ,@clauses)
> `(cond ,@clauses (t (error "Fell through all clauses of ECOND."))))))
>
> That way if you write exhaustive clauses for your normal operation
> you get an error message only if your "exhaustive" clauses weren't
> really exhaustive.
Probably.
In the case I was describing, though, I would have had a hard time
getting the other developer to adopt using the ECOND construct.
Jon Harrop <······@jdh30.plus.com> writes:
> Joe Marshall wrote:
>> No, I wanted a warning that the output isn't sorted.
> However, the question is "how likely are you to write those kinds of
> errors"?
Or, "how likely is there to be an error, not detectable by a type
system, in your algorithm or its implementation (be it sorting or
otherwise)?". Not unlikely, I'd say.
Lars Brinkhoff wrote:
> Or, "how likely is there to be an error, not detectable by a type
> system, in your algorithm or its implementation (be it sorting or
> otherwise)?". Not unlikely, I'd say.
From my experience, that is very true when dynamic typing is required, e.g.
my GUI code. However, there are many places (most of my code) where I think
the type checker is likely to catch most (>50%?) errors. I watched myself
(?!) writing a rewrite interpreter last night and the OCaml and SML type
checkers literally caught all of my errors (it worked perfectly the first
time it ran).
Ultimately, this is so subjective that I can't see anyone drawing any useful
conclusions. It seems that most people either adopt dynamic or static
typing out of preference, as their programming skills evolve. I use both
but I choose to gravitate towards static typing when it is available.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Lars Brinkhoff wrote:
> > Or, "how likely is there to be an error, not detectable by a type
> > system, in your algorithm or its implementation (be it sorting or
> > otherwise)?". Not unlikely, I'd say.
>
> From my experience, that is very true when dynamic typing is required, e.g.
> my GUI code. However, there are many places (most of my code) where I think
> the type checker is likely to catch most (>50%?) errors. I watched myself
> (?!) writing a rewrite interpreter last night and the OCaml and SML type
> checkers literally caught all of my errors (it worked perfectly the first
> time it ran).
Yikes, do you not see what you just said here?!?! For normal code,
dynamic typing helps you get your work done -- but for building
interpreters for general-purpose languages, the ML type system is
really helpful. So, ML is good for implementing ML, and things like
ML, and Lisp is good for everything else?!?! Why bother with ML then?
For the record, yes, I found static type checking to be very helpful
when writing a CPS-transforming CL-to-CL compiler. It found 80% of my
errors, and runtime type assertions found the others. The type
checking infrastructure cost me 120 lines of CL. Just like the
ability to write custom interpreters, the ability to write
domain-specific type checkers is an important tool -- and once you
have that, and a language that supports you in it (like, eg, CL), you
always have custom type systems available. The only limit is your
ability to read type theory papers :-)
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> Lars Brinkhoff wrote:
>> > Or, "how likely is there to be an error, not detectable by a type
>> > system, in your algorithm or its implementation (be it sorting or
>> > otherwise)?". Not unlikely, I'd say.
>>
>> From my experience, that is very true when dynamic typing is required,
>> e.g. my GUI code. However, there are many places (most of my code) where
>> I think the type checker is likely to catch most (>50%?) errors. I
>> watched myself (?!) writing a rewrite interpreter last night and the
>> OCaml and SML type checkers literally caught all of my errors (it worked
>> perfectly the first time it ran).
>
> Yikes, do you not see what you just said here?!?! For normal code,
> dynamic typing helps you get your work done -- but for building
> interpreters for general-purpose languages, the ML type system is
> really helpful. So, ML is good for implementing ML, and things like
> ML, and Lisp is good for everything else?!?! Why bother with ML then?
I said that static type checkers catch >50% of my errors in most of my code.
Quite how you got to "Why bother with ML" from there I do not know...
> For the record, yes, I found static type checking to be very helpful
> when writing a CPS-transforming CL-to-CL compiler. It found 80% of my
> errors, and runtime type assertions found the others. The type
> checking infrastructure cost me 120 lines of CL. Just like the
> ability to write custom interpreters, the ability to write
> domain-specific type checkers is an important tool -- and once you
> have that, and a language that supports you in it (like, eg, CL), you
> always have custom type systems available. The only limit is your
> ability to read type theory papers :-)
Most of the programs that I write are numerical or graphical. I find static
typing very useful there. Static typing was much less useful in my GUI code
but I was still able to leverage it to guarantee that much of my GUI code
cannot produce run-time errors.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> I said that static type checkers catch >50% of my errors in most of my code.
> Quite how you got to "Why bother with ML" from there I do not know...
So, how do you deal with the other errors? If you write tests to catch
them, then the benefit of static typing becomes less, since most of
those bugs will be found by the other tests. The more thoroughly
you test your code to find those remaining bugs, the more thoroughly
you make the static typing redundant.
The interesting figure should not be 'how many bugs does static
typing catch', but rather, 'how many bugs does static typing catch
that thorough testing would not also catch'? I suggest this is often
a very small number.
Paul
Paul Dietz wrote:
> Jon Harrop wrote:
>> I said that static type checkers catch >50% of my errors in most of my
>> code. Quite how you got to "Why bother with ML" from there I do not
>> know...
>
> So, how do you deal with the other errors? If you write tests to catch
> them, then the benefit of static typing becomes less, since most of
> those bugs will be found by the other tests. The more thoroughly
> you test your code to find those remaining bugs, the more thoroughly
> you make the static typing redundant.
Yes, exactly. Ultimately, you can static type check the code yourself, by
hand.
> The interesting figure should not be 'how many bugs does static
> typing catch', but rather, 'how many bugs does static typing catch
> that thorough testing would not also catch'? I suggest this is often
> a very small number.
The way I see it, the two advantages are: you can find and fix static type
errors more quickly, and you can automate the process of removing such
errors from blocks of code. The utility of this varies depending upon the
application.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
> I said that static type checkers catch >50% of my errors in most of my code.
I'm probably in the minority here, but I happen to like static
typechecking.
Nice as it is, however, Hindley-Damas-Milner is not all there is to
static typechecking. My preference is to use a Lisp environment with
good type propagation (and in practice that limits me to CMUCL or
SBCL) and declare the argument types of all non-trivial functions. In
practice, this tends to catch most of what Hindley-Milner would catch
(as compile-time warnings rather than errors) while still allowing you
to use all the goodies present in Lisp but missing in Caml or Haskell.
Note that this is from a practical point of view. From a theoretical
point of view the CMUCL typechecker is an ugly hack -- but an
amazingly convenient one. (Just like Common Lisp itself.)
Juliusz
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: What's so great about lisp?
Date:
Message-ID: <87achl1bro.fsf@qrnik.zagroda>
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> Nice as it is, however, Hindley-Damas-Milner is not all there is to
> static typechecking. My preference is to use a Lisp environment with
> good type propagation (and in practice that limits me to CMUCL or
> SBCL) and declare the argument types of all non-trivial functions.
> In practice, this tends to catch most of what Hindley-Milner would
> catch (as compile-time warnings rather than errors)
I doubt that. Static typechecking is most useful with higher order and
polymorphic functions, e.g. when writing and using monads and monad
transformers. In these cases type errors don't look as obvious as
(CAR "foo").
With dynamic typing an error in using higher order functions would
often be reported far away from the real cause. When you pass a
function of a wrong type, you don't immediately get a runtime error;
you get it only when the function is ultimately applied.
In Common Lisp you can't declare relationships between types in
polymorphic functions, e.g. that a function returns a value of the
same type as elements of the list it was applied to, which is also
the same type as the type of two arguments of the function it takes
as another argument.
Another place where a static type system as found in most functional
languages is useful, is checking consistency of code working with
tree structures, like abstract syntax trees. This includes valuable
"patterns not exhaustive" warnings which are emitted before a tester
would invent an example which would actually trigger the error. This
is important when the structure of the tree is changed and all parts
of the code which depend on the changed place must be updated.
I'm sick of arguments that static typing is useless because it doesn't
catch all errors and you have to test code anyway. It still catches
most of them, and often it makes easier to pinpoint the location of
the bug than runtime errors.
Having said that, I generally prefer dynamic typing, because it makes
the language mich simpler, and because I value the ability to write
code which would be hard to express in static types (e.g. a generic
serialization framework) more than a support for catching a subset
of bugs.
Static typing and dynamic typing are two important and useful
tradeoffs. Neither subsumes the other, even if you add CL-style
type declarations to the dynamic typing side.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> In Common Lisp you can't declare relationships between types in
> polymorphic functions, e.g. that a function returns a value of the
> same type as elements of the list it was applied to, which is also
> the same type as the type of two arguments of the function it takes
> as another argument.
You can write
(declaim (declaration type-equation))
(defun f (l)
(declare (type-equation
(every (lambda (x) (eql (type-of x) (type-of (result f)))) l)))
...)
My point is that type inference and static typing, along with
assertion and pre/post condition checking need not necessarily be
embedded into the language/compiler. You can have modular tools that
do the job when needed.
> [...]
> I'm sick of arguments that static typing is useless because it doesn't
> catch all errors and you have to test code anyway. It still catches
> most of them, and often it makes easier to pinpoint the location of
> the bug than runtime errors.
>
> Having said that, I generally prefer dynamic typing, because it makes
> the language mich simpler, and because I value the ability to write
> code which would be hard to express in static types (e.g. a generic
> serialization framework) more than a support for catching a subset
> of bugs.
>
> Static typing and dynamic typing are two important and useful
> tradeoffs. Neither subsumes the other, even if you add CL-style
> type declarations to the dynamic typing side.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
On Fri, 07 Oct 2005 18:06:02 +0200, Juliusz Chroboczek wrote:
>
> I'm probably in the minority here, but I happen to like static
> typechecking.
>
Fair enough... Can't stand it myself.
Working with static type-checking reminds me of a movie I once saw (can't
remember the name), which has a scene where a man is giving a woman oral
sex and the woman just keeps saying "No... nope... no... *sigh*... no..."
Working with Lisp it's much easier to get something off the ground quickly
because, as you work on your program, Lisp tells you "No... better...
worse... much better... good" rather than just "no, no, no". I frequently
have programs in a state where much of the code is completely broken with
respect to type-correctness, and I *know* that, but I still want to
compile it so that I can work on the other bits.
Best wishes,
Bill.
William Bland <···············@gmail.com> writes:
> I frequently have programs in a state where much of the code is
> completely broken with respect to type-correctness, and I *know*
> that, but I still want to compile it so that I can work on the other
> bits.
Exactly.
Now I want as much static checking as possible, but I'm going to get
really irritated if it gets in the way.
Joe Marshall wrote:
> William Bland <···············@gmail.com> writes:
>
>
>>I frequently have programs in a state where much of the code is
>>completely broken with respect to type-correctness, and I *know*
>>that, but I still want to compile it so that I can work on the other
>>bits.
>
>
> Exactly.
>
> Now I want as much static checking as possible,
Nonsense,...
> ...but I'm going to get
> really irritated if it gets in the way.
>
...if you have it, it is in the way. Now stare at your navel and get
back to me when you can explain that to the kiddies listening at home.
--
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
Joe Marshall wrote:
> I like the compiler to notice situations like the above. They are
> almost always errors (except when they are tests for the compiler).
> Nonetheless, I want the compiler to produce code. A warning that it
> is replacing a call to (car x y z) with a call to (error "Wrong number
> of arguments to CAR" ...) is what I expect.
I don't think your idea generalises well to curried functions because the
program state is not then well defined, i.e. how many curried arguments
should be accepted before the error is thrown?
> (Actually, it should be a
> continuable runtime error that allows me to drop the excess
> arguments!)
Do you often put superfluous arguments after the correct one by accident
though? I doubt you'd want to drop the excess arguments very often in
practice...
> These simple checks are trivially decidable. You can't redefine
> CL:CONS, so you either have the correct number of arguments or you
> don't. There's no possibility that some later code will change the
> argument count and suddenly make the call site valid.
What if the code is quoted?
> The problem occurs when the checks are more complicated.
>
> Static checks often have three possible outcomes: provably correct,
> provably incorrect (i.e. the code will deterministically and always
> generate an error at runtime), and `other'. Obviously, nothing need
> be done if the code is provably correct.
The run-time checks can be removed, sometimes greatly increasing
performance.
> It is the other two cases that are interesting.
>
> If the static check can prove that the code will deterministically and
> always generate an error at runtime, I would appreciate it if the
> compiler generated a warning (and still compiled the code). I can see
> no reason why anyone would not want as many of these kind of checks
> possible, provided they could be muffled when you are deliberatly
> testing error situations.
Yes.
> But most aficionados of static typing want something a little
> different: if the compiler cannot prove that the code will
> deterministically and always *not* generate an error at runtime, they
> don't want the code to be compiled.
Oh no, absolutely not. Firstly, there are lots of ways to generate run-time
errors, including effectively-type errors, in statically typed code. For
example, decapitating a list that we know has >1 element in Lisp:
* (defun decapitate (list) (values (car list) (cdr list)))
DECAPITATE
* (decapitate '(1 2 3))
1
(2 3)
and in OCaml:
# let decapitate list = (List.hd list, List.tl list);;
val decapitate : 'a list -> 'a * 'a list = <fun>
# decapitate [1;2;3];;
- : int * int list = (1, [2; 3])
The OCaml code statically type checks just fine even though it clearly is
not guaranteed to not generate an error at run-time, as you claimed.
Specifically, applying decapitate to the empty list gives you a run-time
error just as the Lisp does:
# decapitate [];;
Exception: Failure "tl".
You can then examine the program state to debug the program, just as you do
with dynamic typing.
> I definitely consider this to be `getting in the way'.
The critical point here is that the programmer can choose whether or not to
exploit static typing. You are never forced to use it. However, you
sometimes have to work around it = "getting in the way" as you say.
In this case, if you want to leverage the static type checker then you
replace your >1-element list with a 2-tuple of the head and tail:
# let decapitate (h, t) = (h, t);;
val decapitate : 'a * 'b -> 'a * 'b = <fun>
# decapitate (1, [2;3]);;
- : int * int list = (1, [2; 3])
All sources of run-time errors have now been removed from this code.
The disadvantage is that this "gets in the way" because you have to rewrite
your code. But unless you do that, you don't get the advantages of static
type checking.
It is vitally important to distinguish between static type errors and type
errors in the wider sense. Your statement is correct for static type errors
(that, by definition, do not occur at run time). But not all (general) type
errors are static type errors in a statically typed languages. So it is
definitely not correct to say "if the compiler cannot prove that the code
will deterministically and always *not* generate an error at runtime, they
don't want the code to be compiled".
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Joe Marshall wrote:
>> I like the compiler to notice situations like the above. They are
>> almost always errors (except when they are tests for the compiler).
>> Nonetheless, I want the compiler to produce code. A warning that it
>> is replacing a call to (car x y z) with a call to (error "Wrong number
>> of arguments to CAR" ...) is what I expect.
>
> I don't think your idea generalises well to curried functions because the
> program state is not then well defined, i.e. how many curried arguments
> should be accepted before the error is thrown?
That isn't an issue in Common Lisp because there is no `automatic'
currying.
>> (Actually, it should be a
>> continuable runtime error that allows me to drop the excess
>> arguments!)
>
> Do you often put superfluous arguments after the correct one by accident
> though? I doubt you'd want to drop the excess arguments very often in
> practice...
Not often. Of course never in debugged code. But sometimes I am
working on a program that takes a lot of time to build up a lot of
state before it hits some stupid typo that I have made. In these
cases, I can on occasion continue working by using the debugger to
work around the problem for this iteration rather than being forced to
go back to square one.
>> These simple checks are trivially decidable. You can't redefine
>> CL:CONS, so you either have the correct number of arguments or you
>> don't. There's no possibility that some later code will change the
>> argument count and suddenly make the call site valid.
>
> What if the code is quoted?
It isn't a call site until it gets evaled or compiled.
>> The problem occurs when the checks are more complicated.
>>
>> Static checks often have three possible outcomes: provably correct,
>> provably incorrect (i.e. the code will deterministically and always
>> generate an error at runtime), and `other'. Obviously, nothing need
>> be done if the code is provably correct.
>
> The run-time checks can be removed, sometimes greatly increasing
> performance.
Yes, but I was addressing safety, not performance.
>> It is the other two cases that are interesting.
>>
>> If the static check can prove that the code will deterministically and
>> always generate an error at runtime, I would appreciate it if the
>> compiler generated a warning (and still compiled the code). I can see
>> no reason why anyone would not want as many of these kind of checks
>> possible, provided they could be muffled when you are deliberatly
>> testing error situations.
>
> Yes.
>
>> But most aficionados of static typing want something a little
>> different: if the compiler cannot prove that the code will
>> deterministically and always *not* generate an error at runtime, they
>> don't want the code to be compiled.
>
> Oh no, absolutely not. Firstly, there are lots of ways to generate run-time
> errors, including effectively-type errors, in statically typed code. For
> example, decapitating a list that we know has >1 element in Lisp:
>
> * (defun decapitate (list) (values (car list) (cdr list)))
>
> DECAPITATE
> * (decapitate '(1 2 3))
>
> 1
> (2 3)
>
> and in OCaml:
>
> # let decapitate list = (List.hd list, List.tl list);;
> val decapitate : 'a list -> 'a * 'a list = <fun>
> # decapitate [1;2;3];;
> - : int * int list = (1, [2; 3])
>
> The OCaml code statically type checks just fine even though it clearly is
> not guaranteed to not generate an error at run-time, as you claimed.
> Specifically, applying decapitate to the empty list gives you a run-time
> error just as the Lisp does:
>
> # decapitate [];;
> Exception: Failure "tl".
>
> You can then examine the program state to debug the program, just as you do
> with dynamic typing.
Cool.
>> I definitely consider this to be `getting in the way'.
>
> The critical point here is that the programmer can choose whether or not to
> exploit static typing. You are never forced to use it. However, you
> sometimes have to work around it = "getting in the way" as you say.
>
> In this case, if you want to leverage the static type checker then you
> replace your >1-element list with a 2-tuple of the head and tail:
>
> # let decapitate (h, t) = (h, t);;
> val decapitate : 'a * 'b -> 'a * 'b = <fun>
> # decapitate (1, [2;3]);;
> - : int * int list = (1, [2; 3])
>
> All sources of run-time errors have now been removed from this code.
>
> The disadvantage is that this "gets in the way" because you have to rewrite
> your code. But unless you do that, you don't get the advantages of static
> type checking.
Ugh. The problem is that migrating from the first version of
decapitate to the second would seem to require extensive code changes.
> It is vitally important to distinguish between static type errors and type
> errors in the wider sense. Your statement is correct for static type errors
> (that, by definition, do not occur at run time). But not all (general) type
> errors are static type errors in a statically typed languages. So it is
> definitely not correct to say "if the compiler cannot prove that the code
> will deterministically and always *not* generate an error at runtime, they
> don't want the code to be compiled".
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> http://www.ffconsultancy.com
Joe Marshall wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> I don't think your idea generalises well to curried functions because the
>> program state is not then well defined, i.e. how many curried arguments
>> should be accepted before the error is thrown?
>
> That isn't an issue in Common Lisp because there is no `automatic'
> currying.
Well, the problem exists but it isn't likely to be a problem. :-)
>> Do you often put superfluous arguments after the correct one by accident
>> though? I doubt you'd want to drop the excess arguments very often in
>> practice...
>
> Not often. Of course never in debugged code. But sometimes I am
> working on a program that takes a lot of time to build up a lot of
> state before it hits some stupid typo that I have made. In these
> cases, I can on occasion continue working by using the debugger to
> work around the problem for this iteration rather than being forced to
> go back to square one.
Good point.
>>> These simple checks are trivially decidable. You can't redefine
>>> CL:CONS, so you either have the correct number of arguments or you
>>> don't. There's no possibility that some later code will change the
>>> argument count and suddenly make the call site valid.
>>
>> What if the code is quoted?
>
> It isn't a call site until it gets evaled or compiled.
Are you saying that static checks are done when "eval" is invoked?
>> The OCaml code statically type checks just fine even though it clearly is
>> not guaranteed to not generate an error at run-time, as you claimed.
>> Specifically, applying decapitate to the empty list gives you a run-time
>> error just as the Lisp does:
>>
>> # decapitate [];;
>> Exception: Failure "tl".
>>
>> You can then examine the program state to debug the program, just as you
>> do with dynamic typing.
>
> Cool.
The HM type system is really very unobtrusive. So it only "gets in your way"
when you deliberately put it in your way because you're trying to get the
compiler to force you to fix bugs.
The only time I've ever had to sit down and think how to "work around" the
static type system was when I realised that the last little bit of code I
needed to write was a key stone that brought everything else together in a
giant mutual recursion. Of the various solutions, I decided that OCaml's
objects were the most elegant. It took me a couple of days to decide that
though...
>> In this case, if you want to leverage the static type checker then you
>> replace your >1-element list with a 2-tuple of the head and tail:
>>
>> # let decapitate (h, t) = (h, t);;
>> val decapitate : 'a * 'b -> 'a * 'b = <fun>
>> # decapitate (1, [2;3]);;
>> - : int * int list = (1, [2; 3])
>>
>> All sources of run-time errors have now been removed from this code.
>>
>> The disadvantage is that this "gets in the way" because you have to
>> rewrite your code. But unless you do that, you don't get the advantages
>> of static type checking.
>
> Ugh. The problem is that migrating from the first version of
> decapitate to the second would seem to require extensive code changes.
Yes, it requires extensive changes. A lot of the work can be factored out (I
use a module that implements a >1-element list) but the more you want to
exploit the type system, the more work you have to do. The advantage is, of
course, the elimination of lots of bugs.
I recently applied exactly this technique to some code. I had been using
run-time debugging on a relatively dynamically typed version for weeks and
it still had bugs. It took me 3 days to convert the code to stronger static
typing and, when I'd finished, the compiler had forced me to fix all of the
bugs and I haven't had a run-time error in that code since. Indeed, the
transformation removed all sources of run-time errors from most of the
code.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Joe Marshall wrote:
> > It isn't a call site until it gets evaled or compiled.
>
> Are you saying that static checks are done when "eval" is invoked?
With the obvious implementation, of course. However, first-class
syntax gives programmers other options for programming static
checks. (Don't tell Harrop, but we can also auto-insert domain
specific dynamic checks using global analysis.)
Of course, languages that don't support eval or code-walking are
obviously superior. If Harrop can't figure it out or would likely
misues it, it shouldn't be done.
-andy
Jon Harrop wrote:
> Joe Marshall wrote:
>>Jon Harrop <······@jdh30.plus.com> writes:
>>
>>>What if the code is quoted?
>>
>>It isn't a call site until it gets evaled or compiled.
>
> Are you saying that static checks are done when "eval" is invoked?
Think about what happens if I define a macro like this:
(defmacro illegal (&rest params)
"It is illegal to call this macro from anywhere, for any reason."
(cerror "You called the illegal macro! Bad coder!"))
The Lisp environment is always on, so of course there are no static
checks. But that doesn't prevent you from performing runtime checks at
read-time, compile-time, macro-expansion-time, evaluation-time, or
some-other-time.
-- MJF
Jon Harrop <······@jdh30.plus.com> writes:
> Joe Marshall wrote:
> > (Actually, it should be a continuable runtime error
> > that allows me to drop the excess arguments!)
>
> Do you often put superfluous arguments after the correct one by
> accident though? I doubt you'd want to drop the excess arguments
> very often in practice...
I usually want to restart the frame with different arguments,
one (or more) of which was provided for the errant call.
Jon Harrop wrote:
>
> Oh no, absolutely not. Firstly, there are lots of ways to generate run-time
> errors, including effectively-type errors, in statically typed code. For
> example, decapitating a list that we know has >1 element in Lisp:
>
> * (defun decapitate (list) (values (car list) (cdr list)))
>
> DECAPITATE
> * (decapitate '(1 2 3))
>
> 1
> (2 3)
>
> and in OCaml:
>
> # let decapitate list = (List.hd list, List.tl list);;
> val decapitate : 'a list -> 'a * 'a list = <fun>
> # decapitate [1;2;3];;
> - : int * int list = (1, [2; 3])
>
> The OCaml code statically type checks just fine even though it clearly is
> not guaranteed to not generate an error at run-time, as you claimed.
> Specifically, applying decapitate to the empty list gives you a run-time
> error just as the Lisp does:
>
> # decapitate [];;
> Exception: Failure "tl".
Ummm ... the lisp code is perfectly legal, and will not generate an
error when applied to the empty list.
(car nil) => nil
(cdr nil) => nil.
So to me, the only thing you've proven is, not only can the static
checks get in your way, but the run-time checks do as well!
and this is easier then lisp how? :)
drewc
>
> You can then examine the program state to debug the program, just as you do
> with dynamic typing.
>
>
>>I definitely consider this to be `getting in the way'.
>
>
> The critical point here is that the programmer can choose whether or not to
> exploit static typing. You are never forced to use it. However, you
> sometimes have to work around it = "getting in the way" as you say.
>
> In this case, if you want to leverage the static type checker then you
> replace your >1-element list with a 2-tuple of the head and tail:
>
> # let decapitate (h, t) = (h, t);;
> val decapitate : 'a * 'b -> 'a * 'b = <fun>
> # decapitate (1, [2;3]);;
> - : int * int list = (1, [2; 3])
>
> All sources of run-time errors have now been removed from this code.
>
> The disadvantage is that this "gets in the way" because you have to rewrite
> your code. But unless you do that, you don't get the advantages of static
> type checking.
>
> It is vitally important to distinguish between static type errors and type
> errors in the wider sense. Your statement is correct for static type errors
> (that, by definition, do not occur at run time). But not all (general) type
> errors are static type errors in a statically typed languages. So it is
> definitely not correct to say "if the compiler cannot prove that the code
> will deterministically and always *not* generate an error at runtime, they
> don't want the code to be compiled".
>
--
Drew Crampsie
drewc at tech dot coop
"... the most advanced use of lisp in the field of bass lure sales"
-- Xach on #lisp
Joe Marshall wrote:
> I like the compiler to notice situations like the above. They are
> almost always errors (except when they are tests for the compiler).
> Nonetheless, I want the compiler to produce code. A warning that it
> is replacing a call to (car x y z) with a call to (error "Wrong number
> of arguments to CAR" ...) is what I expect.
I don't think your idea generalises well to curried functions because the
program state is not then well defined, i.e. how many curried arguments
should be accepted before the error is thrown?
> (Actually, it should be a
> continuable runtime error that allows me to drop the excess
> arguments!)
Do you often put superfluous arguments after the correct one by accident
though? I doubt you'd want to drop the excess arguments very often in
practice...
> These simple checks are trivially decidable. You can't redefine
> CL:CONS, so you either have the correct number of arguments or you
> don't. There's no possibility that some later code will change the
> argument count and suddenly make the call site valid.
What if the code is quoted?
> The problem occurs when the checks are more complicated.
>
> Static checks often have three possible outcomes: provably correct,
> provably incorrect (i.e. the code will deterministically and always
> generate an error at runtime), and `other'. Obviously, nothing need
> be done if the code is provably correct.
The run-time checks can be removed, sometimes greatly increasing
performance.
> It is the other two cases that are interesting.
>
> If the static check can prove that the code will deterministically and
> always generate an error at runtime, I would appreciate it if the
> compiler generated a warning (and still compiled the code). I can see
> no reason why anyone would not want as many of these kind of checks
> possible, provided they could be muffled when you are deliberatly
> testing error situations.
Yes.
> But most aficionados of static typing want something a little
> different: if the compiler cannot prove that the code will
> deterministically and always *not* generate an error at runtime, they
> don't want the code to be compiled.
Oh no, absolutely not. Firstly, there are lots of ways to generate run-time
errors, including effectively-type errors, in statically typed code. For
example, decapitating a list that we know has >1 element in Lisp:
* (defun decapitate (list) (values (car list) (cdr list)))
DECAPITATE
* (decapitate '(1 2 3))
1
(2 3)
and in OCaml:
# let decapitate list = (List.hd list, List.tl list);;
val decapitate : 'a list -> 'a * 'a list = <fun>
# decapitate [1;2;3];;
- : int * int list = (1, [2; 3])
The OCaml code statically type checks just fine even though it clearly is
not guaranteed to not generate an error at run-time, as you claimed.
Specifically, applying decapitate to the empty list gives you a run-time
error just as the Lisp does:
# decapitate [];;
Exception: Failure "tl".
You can then examine the program state to debug the program, just as you do
with dynamic typing.
> I definitely consider this to be `getting in the way'.
The critical point here is that the programmer can choose whether or not to
exploit static typing. You are never forced to use it. However, you
sometimes have to work around it = "getting in the way" as you say.
In this case, if you want to leverage the static type checker then you
replace your >1-element list with a 2-tuple of the head and tail:
# let decapitate (h, t) = (h, t);;
val decapitate : 'a * 'b -> 'a * 'b = <fun>
# decapitate (1, [2;3]);;
- : int * int list = (1, [2; 3])
All sources of run-time errors have now been removed from this code.
The disadvantage is that this "gets in the way" because you have to rewrite
your code. But unless you do that, you don't get the advantages of static
type checking.
It is vitally important to distinguish between static type errors and type
errors in the wider sense. Your statement is correct for static type errors
(that, by definition, do not occur at run time). But not all (general) type
errors are static type errors in a statically typed languages. So it is
definitely not correct to say "if the compiler cannot prove that the code
will deterministically and always *not* generate an error at runtime, they
don't want the code to be compiled".
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> * (defun decapitate (list) (values (car list) (cdr list)))
>
> DECAPITATE
> * (decapitate '(1 2 3))
>
> 1
> (2 3)
>
> and in OCaml:
>
> # let decapitate list = (List.hd list, List.tl list);;
> val decapitate : 'a list -> 'a * 'a list = <fun>
> # decapitate [1;2;3];;
> - : int * int list = (1, [2; 3])
>
> The OCaml code statically type checks just fine even though it clearly is
> not guaranteed to not generate an error at run-time, as you claimed.
> Specifically, applying decapitate to the empty list gives you a run-time
> error just as the Lisp does:
>
> # decapitate [];;
> Exception: Failure "tl".
Not in lisp:
[230]> (defun decapitate (list) (values (car list) (cdr list)))
DECAPITATE
[231]> (DECAPITATE '())
NIL ;
NIL
OCaml type analysis is "wrong": it doesn't match the type analysis in
lisp. You can write the OCaml code for decapitate equivalent to the
lisp semantics, and you'll be Greenspuning.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Kitty like plastic.
Confuses for litter box.
Don't leave tarp around.
Joe Marshall wrote:
> Now I want as much static checking as possible, but I'm going to get
> really irritated if it gets in the way.
If that were available then I'd want the final statically-checked code to be
compiled efficiently, i.e. without unnecessary run-time checks and with
optimised pattern matches and so on.
Any idea if such a language exists or if Lisp could be coerced into doing
this? It would probably require two different run-times...
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Joe Marshall wrote:
>
>>Now I want as much static checking as possible, but I'm going to get
>>really irritated if it gets in the way.
>
> If that were available then I'd want the final statically-checked code to be
> compiled efficiently, i.e. without unnecessary run-time checks and with
> optimised pattern matches and so on.
That doesn't make sense. The majority of a program is executed very
rarely, typically only few parts are executed most of the time. It's one
of those 80:20 things: 80% of the time only 20% of the code is executed.
(These are, of course, not the exact numbers, but that's the idea.)
This means that the "efficiency" of the resulting code doesn't really
pay off in the majority of the code - you wouldn't actually notice any
difference. On the other hand, the removed run-time checks are areas
where potential problems can occur. Think about security leaks or lack
of information in case the program fails in unexpected ways.
The only reasonable way to get efficient programs is to try to identify
the "hot spots" and optimize them and only them. The best way to
optimize them is to completely get rid of them. This boils down to
finding better algorithms / execution stratetegies rather than
fine-tuning what are essentially bad algorithms, etc.
> Any idea if such a language exists or if Lisp could be coerced into doing
> this? It would probably require two different run-times...
Common Lisp provides declarations with which you can declare your
intentions. (declaim (optimize speed)) would result in more efficient
code, (declaim (optimize debug)) would result in code with more debug
information, (declaim (optimize compilation-speed)) would focus on
generating the code as quickly as possible, (declaim (optimize safety))
would result in code that omits run-time safety checks. These are some
of the standardized optimization qualities, and you get even more
fine-grained control by assigning degrees with those qualities (0 = low
to 3 = high).
Common Lisp implementations are allowed to ignore these declarations,
but many do a pretty good job at interpreting them in useful ways. CMUCL
and SBCL are especially interesting because they have a type inferencer
that interacts with these settings (IIUC). (This doesn't mean that I
generally recommend to focus just on those two implementations - their
compiler is relatively slow because it apparently spends quite some time
on optimizing code, and sometimes it is more important to a have fast
compiler rather than have fast code.)
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:
>> If that were available then I'd want the final statically-checked code to
>> be compiled efficiently, i.e. without unnecessary run-time checks and
>> with optimised pattern matches and so on.
>
> That doesn't make sense.
I think it makes sense. Moreover, I think it is widely accepted and there is
a lot of evidence that it is true. For example, SBCL tries to remove
run-time checks where possible in order to improve performance.
> The majority of a program is executed very
> rarely, typically only few parts are executed most of the time. It's one
> of those 80:20 things: 80% of the time only 20% of the code is executed.
> (These are, of course, not the exact numbers, but that's the idea.)
Yes. Removing run-time checks speeds up all of the code, including the ~20%
where most of the time is spent. The advantage is significantly faster
programs.
> This means that the "efficiency" of the resulting code doesn't really
> pay off in the majority of the code - you wouldn't actually notice any
> difference. On the other hand, the removed run-time checks are areas
> where potential problems can occur.
> Think about security leaks or lack of information in case the program
> fails in unexpected ways.
No. In ML, the run-time checks are only removed when it is statically proven
to be safe to do so. SBCL can remove run-times checks without requiring
such proof, leading to unsafe programs, but only when instructed to do so.
> The only reasonable way to get efficient programs is to try to identify
> the "hot spots" and optimize them and only them. The best way to
> optimize them is to completely get rid of them. This boils down to
> finding better algorithms / execution stratetegies rather than
> fine-tuning what are essentially bad algorithms, etc.
While that is certainly true, it has nothing to do with the compiler
removing run-time checks for you.
When I want to optimise a C++ program, for example, I start by requesting
compiler optimisations on the command line (e.g. -O2) because it is easy to
do. Automated removal of run-time checks falls into the same category.
> Common Lisp implementations are allowed to ignore these declarations,
> but many do a pretty good job at interpreting them in useful ways. CMUCL
> and SBCL are especially interesting because they have a type inferencer
> that interacts with these settings (IIUC). (This doesn't mean that I
> generally recommend to focus just on those two implementations - their
> compiler is relatively slow because it apparently spends quite some time
> on optimizing code, and sometimes it is more important to a have fast
> compiler rather than have fast code.)
Does that mean that "eval" is slow to invoke with CMUCL and SBCL?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Pascal Costanza wrote:
>
>>Jon Harrop wrote:
>>
>>>If that were available then I'd want the final statically-checked code to
>>>be compiled efficiently, i.e. without unnecessary run-time checks and
>>>with optimised pattern matches and so on.
>>
>>That doesn't make sense.
>
> I think it makes sense. Moreover, I think it is widely accepted and there is
> a lot of evidence that it is true. For example, SBCL tries to remove
> run-time checks where possible in order to improve performance.
I know it's counter-intuitive, but the evidence goes in the other
direction. For example, read papers about implementations and
performance optimizations for Self, Strongtalk and the Java HotSpot JVM.
Or read papers about benchmarks and optizimation in general.
>>The majority of a program is executed very
>>rarely, typically only few parts are executed most of the time. It's one
>>of those 80:20 things: 80% of the time only 20% of the code is executed.
>>(These are, of course, not the exact numbers, but that's the idea.)
>
> Yes. Removing run-time checks speeds up all of the code, including the ~20%
> where most of the time is spent. The advantage is significantly faster
> programs.
You can't make such claims without showing the numbers. If you had the
numbers, you'd see that it isn't true. See also
http://www-plan.cs.colorado.edu/~hauswirt/Research/
>>This means that the "efficiency" of the resulting code doesn't really
>>pay off in the majority of the code - you wouldn't actually notice any
>>difference. On the other hand, the removed run-time checks are areas
>>where potential problems can occur.
>>Think about security leaks or lack of information in case the program
>>fails in unexpected ways.
>
> No. In ML, the run-time checks are only removed when it is statically proven
> to be safe to do so.
That's impossible. Note again that I was referring to things like
security leaks. For example, there is a paper that shows how a JVM or a
.NET runtime enviroment are susceptible to security attacks _because_,
not in spite, of static type checks. See
http://citeseer.ist.psu.edu/govindavajhala03using.html
>>Common Lisp implementations are allowed to ignore these declarations,
>>but many do a pretty good job at interpreting them in useful ways. CMUCL
>>and SBCL are especially interesting because they have a type inferencer
>>that interacts with these settings (IIUC). (This doesn't mean that I
>>generally recommend to focus just on those two implementations - their
>>compiler is relatively slow because it apparently spends quite some time
>>on optimizing code, and sometimes it is more important to a have fast
>>compiler rather than have fast code.)
>
> Does that mean that "eval" is slow to invoke with CMUCL and SBCL?
What do you think this depends on?
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Judging by your response I think perhaps we are talking at cross purposes...
Pascal Costanza wrote:
> Jon Harrop wrote:
>> I think it makes sense. Moreover, I think it is widely accepted and there
>> is a lot of evidence that it is true. For example, SBCL tries to remove
>> run-time checks where possible in order to improve performance.
>
> I know it's counter-intuitive, but the evidence goes in the other
> direction. For example, read papers about implementations and
> performance optimizations for Self, Strongtalk and the Java HotSpot JVM.
> Or read papers about benchmarks and optizimation in general.
Can you cite some papers claiming that removing run-time checking degrades
performance?
>> Yes. Removing run-time checks speeds up all of the code, including the
>> ~20% where most of the time is spent. The advantage is significantly
>> faster programs.
>
> You can't make such claims without showing the numbers.
> If you had the
> numbers, you'd see that it isn't true. See also
> http://www-plan.cs.colorado.edu/~hauswirt/Research/
This seems to be the same problem that I noted before. These comparisons
only look at Java and you seem to be incorrectly generalising the results
to "static typing".
Can you cite any papers making similar comparisons with statically typed
functional languages such as SML, OCaml, Haskell etc.?
>>>This means that the "efficiency" of the resulting code doesn't really
>>>pay off in the majority of the code - you wouldn't actually notice any
>>>difference. On the other hand, the removed run-time checks are areas
>>>where potential problems can occur.
>>>Think about security leaks or lack of information in case the program
>>>fails in unexpected ways.
>>
>> No. In ML, the run-time checks are only removed when it is statically
>> proven to be safe to do so.
>
> That's impossible.
We must be talking at cross purposes. Many compilers already do this.
> Note again that I was referring to things like
> security leaks. For example, there is a paper that shows how a JVM or a
> .NET runtime enviroment are susceptible to security attacks _because_,
> not in spite, of static type checks. See
> http://citeseer.ist.psu.edu/govindavajhala03using.html
Again, a security leak in Java does not imply that statically typed
languages are insecure.
>>>Common Lisp implementations are allowed to ignore these declarations,
>>>but many do a pretty good job at interpreting them in useful ways. CMUCL
>>>and SBCL are especially interesting because they have a type inferencer
>>>that interacts with these settings (IIUC). (This doesn't mean that I
>>>generally recommend to focus just on those two implementations - their
>>>compiler is relatively slow because it apparently spends quite some time
>>>on optimizing code, and sometimes it is more important to a have fast
>>>compiler rather than have fast code.)
>>
>> Does that mean that "eval" is slow to invoke with CMUCL and SBCL?
>
> What do you think this depends on?
Compile time.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
>>>>This means that the "efficiency" of the resulting code doesn't really
>>>>pay off in the majority of the code - you wouldn't actually notice any
>>>>difference. On the other hand, the removed run-time checks are areas
>>>>where potential problems can occur.
>>>>Think about security leaks or lack of information in case the program
>>>>fails in unexpected ways.
>>>
>>>No. In ML, the run-time checks are only removed when it is statically
>>>proven to be safe to do so.
>>
>>That's impossible.
>
> We must be talking at cross purposes. Many compilers already do this.
_Note again that I was referring to things like security leaks!_
Maybe you don't read stuff that's mentioned just once, so here I'll go
again: _Note again that I was referring to things like security leaks!_
BTW, see what I have written in my original response:
>>Note again that I was referring to things like
>>security leaks.
>> For example, there is a paper that shows how a JVM or a
>>.NET runtime enviroment are susceptible to security attacks _because_,
>>not in spite, of static type checks. See
>>http://citeseer.ist.psu.edu/govindavajhala03using.html
>
> Again, a security leak in Java does not imply that statically typed
> languages are insecure.
I have given you references and hints to find references on your own.
It's not my problem that you don't read them.
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:
> I have given you references and hints to find references on your own.
> It's not my problem that you don't read them.
I already read them.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Pascal Costanza wrote:
>> No. In ML, the run-time checks are only removed when it is statically
>> proven
>> to be safe to do so.
>
> That's impossible. Note again that I was referring to things like
> security leaks. For example, there is a paper that shows how a JVM or a
> .NET runtime enviroment are susceptible to security attacks _because_,
> not in spite, of static type checks. See
> http://citeseer.ist.psu.edu/govindavajhala03using.html
Ok, but that's a different kind of security attack. That the JVM is
insecure, has been well known for years.
What I consider security is that my program doesn't execute arbitrary
code, not that much that my VM can securely execute arbitrary foreign
code. In a secure environment you'd only allow foreign code to run in a
sandbox, and there I'd not bother checking the binary code, but just
block all system resources unless explicitly allowed (assuming that the
OS isn't some kind of retarded thing from the 70s or 80s, like the OSes
most of us use that only discriminate between users and where root can
do anything she wants).
--
We're glad that graduates already know Java,
so we only have to teach them how to program.
somewhere in a German company
(credit to M. Felleisen and M. Sperber)
Pascal Costanza wrote:
>> If that were available then I'd want the final statically-checked code
>> to be
>> compiled efficiently, i.e. without unnecessary run-time checks and with
>> optimised pattern matches and so on.
>
> That doesn't make sense. The majority of a program is executed very
> rarely, typically only few parts are executed most of the time. It's one
> of those 80:20 things: 80% of the time only 20% of the code is executed.
> (These are, of course, not the exact numbers, but that's the idea.)
>
> This means that the "efficiency" of the resulting code doesn't really
> pay off in the majority of the code - you wouldn't actually notice any
Maybe not, but the reduced size of the code could still make a (small)
difference. Anyway, why have checks that aren't needed? In Lisp you
need those checks, and that's perfectly fine, but in ML you don't, so
I'd rather that the compiler doesn't insert them ;)
> difference. On the other hand, the removed run-time checks are areas
> where potential problems can occur. Think about security leaks or lack
> of information in case the program fails in unexpected ways.
That can only happen in a language with a non-sound or incomplete type
system. In C many things aren't part of the type system, and there are
ways (unchecked typecasts) that circumvent the type system. Of course
that's unsafe. But for instance a well-typed ML program will never have
any security problems (that are type-related). Likewise if you can
statically prove that an array subscript is always in range, then you
can *safely* remove it in the code. It's not unsafe because it's
statically proved that it can *never* happen.
> The only reasonable way to get efficient programs is to try to identify
> the "hot spots" and optimize them and only them. The best way to
> optimize them is to completely get rid of them. This boils down to
> finding better algorithms / execution stratetegies rather than
> fine-tuning what are essentially bad algorithms, etc.
True, but I don't mind the compiler removing (proven) unneeded runtime
checks anyway.
--
We're glad that graduates already know Java,
so we only have to teach them how to program.
somewhere in a German company
(credit to M. Felleisen and M. Sperber)
Jon Harrop wrote:
> If that were available then I'd want the final statically-checked code to be
> compiled efficiently, i.e. without unnecessary run-time checks and with
> optimised pattern matches and so on.
>
> Any idea if such a language exists or if Lisp could be coerced into doing
> this? It would probably require two different run-times...
I can't imagine why anyone would think that different implementations
for
add would require different run-times.
I wonder what Harrop thinks that lisp compilers do with type
declarations.
Since they are optional, many programs are likely to use multiple
implementations (chosen automatically by the compiler/interpreter).
William Bland wrote:
> Working with Lisp it's much easier to get something off the ground quickly
> because, as you work on your program, Lisp tells you "No... better...
> worse... much better... good" rather than just "no, no, no". I frequently
> have programs in a state where much of the code is completely broken with
> respect to type-correctness, and I *know* that, but I still want to
> compile it so that I can work on the other bits.
That's very interesting. There seems to be a huge difference in the way that
dynamic and static coders evolve. That certainly explains the curiously
small overlaps between the camps.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Ingvar wrote:
> I think a warning is in order because the implications to the reader
> (that "sotr" sotrs things) is not fulfilled. That is something that
> you won't catch with *any* amount of type-checking (well, no, I can
> sort-of see how you can declare a sequence type such that the first
> element fulfills <predicate> against the second and so on, but...).
I see.
On a related note, you can use phantom types to enforce the correct passing
of appropriately sorted containers, for example.
>> I've been looking at how many of the errors that I make are caught by the
>> static type checker and how many require debugging. I must say that the
>> vast majority are caught at compile time.
>
> This is a sufficiently short example of a bug that would require
> debugging. It doesn't look like it, because it's so short and
> trivially wrong, though.
:-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Ulrich Hobelmann wrote:
> 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.
Exactly.
> 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.
Yes. You can choose to use the static type checker to prove the soundness of
the types in your program or you can resort to dynamic type checking and
handle run-time errors instead. The more familiar you get with a static
type system, the more you can exploit it.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Ulrich Hobelmann wrote:
> Russell McManus wrote:
> > Jon Harrop <······@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.
It seems to me there is a serious communication gap here. For me "stack
trace" means a call chain PLUS *values* of variables in the stack
(dynamic or lexical).
Looking at the source in any but the most trivial programs does not
tell you the *values* of variables or function arguments that occur at
run-time, and presumably influence the behavior of the program.
Sometimes one gets the impression that static typing zealots don't even
feel the need to run their programs once they pass the type checking
phase.
··············@hotmail.com wrote:
> It seems to me there is a serious communication gap here.
I concur. :-)
> For me "stack
> trace" means a call chain PLUS *values* of variables in the stack
> (dynamic or lexical).
Yes.
> Looking at the source in any but the most trivial programs does not
> tell you the *values* of variables or function arguments that occur at
> run-time, and presumably influence the behavior of the program.
Herein lies the discrepancy. If a statically typed program is unsound
according to the type system, you cannot compile it so you cannot run it so
you cannot get a stack trace. However, there is no well defined stack trace
in this situation. Hence, you're not missing out.
> Sometimes one gets the impression that static typing zealots don't even
> feel the need to run their programs once they pass the type checking
> phase.
I think the miscommunication is the opposite of that - with static typing
you can fix type errors without having to run the program. But you do not
_have_ to. You can choose.
You can raise run-time errors and handle them, examine your call stack and
so forth, just as you would in a dynamically typed language. I do that all
the time in dynamically typed languages. I sometimes to do it in statically
typed languages but it is rarely necessary with an expressive type system
because the type checker picks up the vast majority of my mistakes.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
··············@hotmail.com wrote:
> It seems to me there is a serious communication gap here. For me "stack
> trace" means a call chain PLUS *values* of variables in the stack
> (dynamic or lexical).
There is no gap. I only said that the class of errors that static
checking removes doesn't need (or even profit) from a dynamic stack. If
you don't care about rigid typing, of course that doesn't help you ;)
> Looking at the source in any but the most trivial programs does not
> tell you the *values* of variables or function arguments that occur at
> run-time, and presumably influence the behavior of the program.
In my humble experience lots of values can be typed in ML-style, but
that's just me and my coding style (I guess I grew up with static typing
and only learned Lisp/Scheme too late to change that significantly).
> Sometimes one gets the impression that static typing zealots don't even
> feel the need to run their programs once they pass the type checking
> phase.
No, but sometimes static typing means that I *know* that a function
can't return a wrong value, simply because it expresses what I want it
to do, and because it has the correct type. There's no room for weird
side effects or inconsistent return values that I didn't anticipate.
Again: that's just static typing. If you don't want it, feel free to
leave it ;)
--
Do or do not. There is no try.
Yoda
Ulrich Hobelmann wrote:
> In my humble experience lots of values can be typed in ML-style, but
> that's just me and my coding style (I guess I grew up with static typing
> and only learned Lisp/Scheme too late to change that significantly).
I grew up on dynamically typed languages and I agree with you. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Russell McManus wrote:
> Jon Harrop <······@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.
The stack trace is undefined and, therefore, conveys no information. Note
that I specifically said "in this case" (twice).
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Russell McManus wrote:
>> Jon Harrop <······@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.
>
> The stack trace is undefined and, therefore, conveys no
> information. Note that I specifically said "in this case" (twice).
Wrong again. The stack trace is perfectly well defined. I can see it
in my Lisp system. This is called 'proof by existence'.
-russ
Russell McManus wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> Russell McManus wrote:
>>> Jon Harrop <······@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.
I misread the bit of my post that you quoted. You will get a stack trace in
this event. It will convey the same information. Dynamic or static typing is
irrelevant.
>> The stack trace is undefined and, therefore, conveys no
>> information. Note that I specifically said "in this case" (twice).
>
> Wrong again. The stack trace is perfectly well defined. I can see it
> in my Lisp system. This is called 'proof by existence'.
In this case, the stack is well defined and you will get a stack trace.
Incidentally, showing a random stack trace does not prove that it is well
defined.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Do you not worry about type errors that remain in your programs?
I can give you at least one real-life example from own experience. I
once had a Clean-program which had to read-in lines from a file. The
program actually worked for some weeks. However, at one day it stumped
across a particular file. At this time I had no chance to investigate
the case. It was impossible for me to reach a conclusion what might go
wrong. Okay, I must say Clean does not have any exception mechanics
whereas Ocaml would feature one.
However, I wrote the program in Common Lisp or Scheme (can't remember).
The Scheme program did not stop. However, the last line as indicated by
Bigloo its output was given a "#f". Oh man, it was a empty line and my
programming code expected always some content since it had to turn a
string-line into floating point numbers.
In this particular case a bullet type proof program was rather
worthless for me.
In Scheme it is much easier for me to change and adapt things. In Clean
or OCaml I would always have to create new data structures. Hey, I
often put new things into an return list and Scheme will not complain.
However, putting things into an OCaml list turns out much harder since
it always wants from me to care about all the correct return structures
and types.
Schneewittchen
On 2005-09-26, Jon Harrop <······@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
Julian Squires wrote:
> On 2005-09-26, Jon Harrop <······@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
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 ++++
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
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 ++++
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
On Mon, 26 Sep 2005 20:58:25 +0200, Pascal Costanza <··@p-cos.net> wrote:
>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".
>
Here's an example of what this feature actually does. I purposefully
add an error to a method:
public final boolean isCancelled()
{
int foo = "1"; // <<-- compile error reported for this
return m_cancelled;
}
and when I decompile the class file, I find literally:
public final boolean isCancelled()
{
throw new Error("Unresolved compilation problem: \n\tType mismatch: cannot convert from
String to" + " int\n" );
}
It's almost a kludge, really, but still very handy when dealing with large
projects with many contributors.
--
Jack
Jack Unrue wrote:
> ... when dealing with large projects with many contributors.
That is an interesting point that I hadn't considered. So someone comes
along and breaks the typing of part of your program that you aren't
actually using. Then you can't compile your code until you've satisfied the
type checker even though you could theoretically have run it anyway. In
Lisp, you execute the code and maybe get a run-time type error.
I think your tool could be implemented very easily in ML but I don't think
anyone has done so yet.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Jack Unrue wrote:
>> ... when dealing with large projects with many contributors.
>
> That is an interesting point that I hadn't considered. So someone comes
> along and breaks the typing of part of your program that you aren't
> actually using. Then you can't compile your code until you've satisfied the
> type checker even though you could theoretically have run it anyway. In
> Lisp, you execute the code and maybe get a run-time type error.
That's a point, but it's more of the non-technical kind. The simple
policy that all code in CVS compiles is enough. If anybody can't test
his checked-in code to that degree, he shouldn't be a programmer and be
kicked out immediately.
All collaboration issues I encountered so far involved functions
belonging to other people returning incorrect values. But that's what
stubs are for (they return incorrect values, but they compile), and in
that case you have to live with the problem at runtime until your
colleague fixes it.
Also, by using mock objects or methods you can still compile and test
your own code (even if your colleague's code wouldn't compile), so
that's not much of an issue, until you integrate and want to test the
whole system. By that time it had better compile ;)
--
Do or do not. There is no try.
Yoda
Ulrich Hobelmann wrote:
> That's a point, but it's more of the non-technical kind. The simple
> policy that all code in CVS compiles is enough.
Yes. Then a static type system would go a long way to checking your
interfaces...
> If anybody can't test
> his checked-in code to that degree, he shouldn't be a programmer and be
> kicked out immediately.
True. :-)
--
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".
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?"
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 ++++
Jon Harrop <······@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 <······@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 <······@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
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
Jon Harrop <······@jdh30.plus.com> writes:
> I don't know whether or not static type systems exist that allow the
> same set of programs as dynamic type checking.
No. (Well, not unless you either allow the static type checker to run
the program, which stretches the meaning of the word `static', or you
project all types into a single tagged union, which stretches the
meaning of the phrase `type check'.)
> Given how obscure code must be to be rejected by a simple static type system...
Huh? Most simple static type systems have difficulty with
heterogeneous lists. These are hardly obscure.
Joe Marshall <·········@alum.mit.edu> wrote:
>Huh? Most simple static type systems have difficulty with
>heterogeneous lists. These are hardly obscure.
I never really understood what the problem is here but maybe you can
provide an example. Normally, one can make a conceptually heterogenous
list homogenous by defining an appropriate union type. Or the concrete
type is not required for defining a certain function that operates on
the list and type variables will do (for example, in SML, the hd
function (equivalent to Lisp's car) has the type 'a list -> 'a, where 'a
("alpha") is a type variable). If you absolutely don't know what kind
of values might appear in a list, and you need to access the concrete
values, this rather smells of chaotic program design, doesn't it?
mkb.
Matthias Buelow <···@incubus.de> writes:
> Joe Marshall <·········@alum.mit.edu> wrote:
>
>>Huh? Most simple static type systems have difficulty with
>>heterogeneous lists. These are hardly obscure.
>
> I never really understood what the problem is here but maybe you can
> provide an example.
How about a list of `test procedures' and their results?
(list (list (lambda () (car '(a b c))) 'a)
(list (lambda () (cadr '("foo" "bar" "baz"))) "bar")
(list (lambda () (+ 2 3)) 5))
Joe Marshall wrote:
> How about a list of `test procedures' and their results?
>
> (list (list (lambda () (car '(a b c))) 'a)
> (list (lambda () (cadr '("foo" "bar" "baz"))) "bar")
> (list (lambda () (+ 2 3)) 5))
{-# OPTIONS -fglasgow-exts #-}
data UnitT = forall a. (Eq a) => T a a
data Symbols = A | B | C deriving Eq
main = putStrLn $ if (and (map check tests))
then "All passed."
else "Some tests failed."
tests = [T (head [A,B,C]) A,
T (head (tail ["foo", "bar", "baz"])) "bar",
T (2 + 3) 5]
check (T q a) = (q == a)
Joe Marshall <·········@alum.mit.edu> wrote:
>How about a list of `test procedures' and their results?
>
>(list (list (lambda () (car '(a b c))) 'a)
> (list (lambda () (cadr '("foo" "bar" "baz"))) "bar")
> (list (lambda () (+ 2 3)) 5))
Good point, however why the need for this exact form here?
You could just make a list of test functions that do the comparison
(or whatever you want to do) themselves, like:
(list (lambda () (= (car '(a b c)) 'a)
...))
Or rather
(list (lambda () (= (my-program-functionality-to-test ...)
expected-result))
...)
Which, translated to a statically typed language like SML,
would end up as a list of unit -> bool;
It's not the same but probably does the job in the same way.
Most likely each of these entries is just a dummy function anyways, that
calls one or more of the program functions, and checks the result.
Actually, I've done a few things that way in SML and I've never ran into
problems with such unit-testing style code.
mkb.
Matthias Buelow <···@incubus.de> writes:
> Joe Marshall <·········@alum.mit.edu> wrote:
>
>>How about a list of `test procedures' and their results?
>>
>>(list (list (lambda () (car '(a b c))) 'a)
>> (list (lambda () (cadr '("foo" "bar" "baz"))) "bar")
>> (list (lambda () (+ 2 3)) 5))
>
> Good point, however why the need for this exact form here?
> You could just make a list of test functions that do the comparison
> (or whatever you want to do) themselves, like:
>
> (list (lambda () (= (car '(a b c)) 'a)
> ...))
>
> Or rather
> (list (lambda () (= (my-program-functionality-to-test ...)
> expected-result))
> ...)
You *could*, and you could probably rework nearly any use of
heterogeneous lists into such a form, but why should you *have* to?
Joe Marshall <·········@alum.mit.edu> wrote:
>You *could*, and you could probably rework nearly any use of
>heterogeneous lists into such a form, but why should you *have* to?
To be able to get the benefit of a type-checked program.
As the above example has shown, there are "intuitive" cases that use
heterogenous types that can with relative ease be rewritten into a
polymorphic (in the above, even monomorphic) version (not everything
could be rewritten that way, of course.)
It might not always be necessary, or desired, to use compile-time
type-checking, but I never advocated to use only statically checked
languages but rather to decide according to the problem domain.
Both approaches have their use. A statically type-checked scripting
language would most likely be more effort than it's worth, for example.
For critical code, I think it's a necessity.
mkb.
Matthias Buelow wrote:
> Joe Marshall <·········@alum.mit.edu> wrote:
>
>>You *could*, and you could probably rework nearly any use of
>>heterogeneous lists into such a form, but why should you *have* to?
>
> To be able to get the benefit of a type-checked program.
Stop here and breathe for a moment!
This is exactly the difference that is important to grasp: "Static
typers" don't mind to change the program so that the static type checker
is happy about it. "Dynamic typers" _do_ mind - they want the program to
look the way they think about the problem / solution domain, without
being forced in any direction by the programming language.
In simple toy examples, like the one Joe has given, it doesn't matter a
lot whether you change things a little just to make the static type
system happy, but in large real programs, it gets in your way because
sometimes it just takes a _lot_ of time to do so. "Dynamic typers" don't
want to spend _a single millisecond_ on this! (And they have their own
ways to ensure that their programs will finally do what they should.)
"Static typers" now probably think "but there are _soooo many_
advantages when you make the static type system happy", but that is
completely besides the point! If you are happy with being forced to
change your programs to adapt to some static typing rules, that's fine,
I don't think it makes sense to try to convince you otherwise - you
probably even write good programs that way. However, "dynamic typers"
are _not_ happy with being forced to change their programs, and they
also write good programs that way, and if you want to _understand_ why
"dynamic typers" prefer dynamic type system, _that is it_! Yes, it
matters _a lot_ to us!
Of course, if you don't want to understand, go ahead arguing...
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Pascal Costanza <··@p-cos.net> wrote:
>probably even write good programs that way. However, "dynamic typers"
>are _not_ happy with being forced to change their programs, and they
>also write good programs that way, and if you want to _understand_ why
>"dynamic typers" prefer dynamic type system, _that is it_! Yes, it
>matters _a lot_ to us!
Hmm, I like both runtime- aswell as compile-time type checking, although
the decision for which to use depends on the application domain. What
does that make me?
mkb.
P.S. I also like Lisp's simple symbolic expression syntax, aswell as a
CFG-derived ALGOL-style operator syntax[1]. Although that is a bit more
difficult to classify over application domains, if at all. Maybe it
makes more sense when talking about the target user clientele. I also
like reverse-polish notation aswell as almost everything else. Am I a
weirdo?
[1] I think the context-free distinction is important. Although
there're ambiguities that can be forgiven to some extent (C-style
if-then[-else] is a typical one), others (like
<flamewar-warning-don't-read-further>Python's context-sensitive
whitespace block-structure</flamewar-warning-don't-read-further>) are a
line that shouldn't be crossed.
Matthias Buelow wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>
>>probably even write good programs that way. However, "dynamic typers"
>>are _not_ happy with being forced to change their programs, and they
>>also write good programs that way, and if you want to _understand_ why
>>"dynamic typers" prefer dynamic type system, _that is it_! Yes, it
>>matters _a lot_ to us!
>
> Hmm, I like both runtime- aswell as compile-time type checking, although
> the decision for which to use depends on the application domain. What
> does that make me?
Sometimes a dynamic typer and sometimes a static typer. ;)
(I am using these extreme positions to make the difference clear.)
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:
> Stop here and breathe for a moment!
Hhhhhhhhh
> This is exactly the difference that is important to grasp: "Static
> typers" don't mind to change the program so that the static type checker
> is happy about it. "Dynamic typers" _do_ mind - they want the program to
> look the way they think about the problem / solution domain, without
> being forced in any direction by the programming language.
Seems like my brain-damage is indeed that severe that I don't mind
annotating my stuff with types (in a good type system; Java is another
story). So from my view, my programs do look the way I think about the
problem.
Funny how different views result in different language requirements.
That said I still prefer Lisp over ML, mostly because of syntax and
other flexibilities (keyword arguments etc.). I think it would be a lot
of work to combine a good type system with Lisp's advantages without the
typing being intrusive.
--
Do or do not. There is no try.
Yoda
Matthias Buelow <···@incubus.de> writes:
> Joe Marshall <·········@alum.mit.edu> wrote:
>
>>You *could*, and you could probably rework nearly any use of
>>heterogeneous lists into such a form, but why should you *have* to?
>
> To be able to get the benefit of a type-checked program.
All lisp programs are type-checked and have been since day 1, back in 1958.
Remeber, this is about static vs. dynamic type-checking. We all agree
that programs must be type-checked.
> As the above example has shown, there are "intuitive" cases that use
> heterogenous types that can with relative ease be rewritten into a
> polymorphic (in the above, even monomorphic) version (not everything
> could be rewritten that way, of course.)
> It might not always be necessary, or desired, to use compile-time
> type-checking, but I never advocated to use only statically checked
> languages but rather to decide according to the problem domain.
> Both approaches have their use. A statically type-checked scripting
> language would most likely be more effort than it's worth, for example.
> For critical code, I think it's a necessity.
>
> mkb.
--
__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
Joe Marshall wrote:
> How about a list of `test procedures' and their results?
>
> (list (list (lambda () (car '(a b c))) 'a)
> (list (lambda () (cadr '("foo" "bar" "baz"))) "bar")
> (list (lambda () (+ 2 3)) 5))
List of ((unit -> Lisp-value) * Lisp-value)
--
Do or do not. There is no try.
Yoda
Ulrich Hobelmann <···········@web.de> writes:
> Joe Marshall wrote:
>> How about a list of `test procedures' and their results?
>> (list (list (lambda () (car '(a b c))) 'a)
>> (list (lambda () (cadr '("foo" "bar" "baz"))) "bar")
>> (list (lambda () (+ 2 3)) 5))
>
> List of ((unit -> Lisp-value) * Lisp-value)
That falls under the "you project all types into a single tagged
union, which stretches the meaning of the phrase `type check'."
Joe Marshall wrote:
> Matthias Buelow <···@incubus.de> writes:
>
>> Joe Marshall <·········@alum.mit.edu> wrote:
>>
>>>Huh? Most simple static type systems have difficulty with
>>>heterogeneous lists. These are hardly obscure.
>>
>> I never really understood what the problem is here but maybe you can
>> provide an example.
>
> How about a list of `test procedures' and their results?
>
> (list (list (lambda () (car '(a b c))) 'a)
> (list (lambda () (cadr '("foo" "bar" "baz"))) "bar")
> (list (lambda () (+ 2 3)) 5))
There are many ways to implement that, from using a tuple instead of a list
to resorting to dynamic typing.
# (((fun () -> List.hd [`A; `B; `C]), `A),
((fun () -> List.hd (List.tl ["foo"; "bar"; "baz"])), "bar"),
((fun () -> 2+3), 5));;
- : ((unit -> [> `A | `B | `C ]) * [> `A ]) * ((unit -> string) * string) *
((unit -> int) * int)
= ((<fun>, `A), (<fun>, "bar"), (<fun>, 5))
# [(fun () -> List.hd [`A; `B; `C]), `A;
(fun () -> `Str (List.hd (List.tl ["foo"; "bar"; "baz"]))), `Str "bar";
(fun () -> `Int (2+3)), `Int 5];;
- : ((unit -> [> `A | `B | `C | `Int of int | `Str of string ]) *
[> `A | `Int of int | `Str of string ])
list
= [(<fun>, `A); (<fun>, `Str "bar"); (<fun>, `Int 5)]
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Joe Marshall wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> I don't know whether or not static type systems exist that allow the
>> same set of programs as dynamic type checking.
>
> No. (Well, not unless you either allow the static type checker to run
> the program, which stretches the meaning of the word `static', or you
> project all types into a single tagged union, which stretches the
> meaning of the phrase `type check'.)
Do you mean there is no such static type system at the moment or that you
can prove that one can never be created?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Joe Marshall wrote:
>> Jon Harrop <······@jdh30.plus.com> writes:
>>> I don't know whether or not static type systems exist that allow the
>>> same set of programs as dynamic type checking.
>>
>> No. (Well, not unless you either allow the static type checker to run
>> the program, which stretches the meaning of the word `static', or you
>> project all types into a single tagged union, which stretches the
>> meaning of the phrase `type check'.)
>
> Do you mean there is no such static type system at the moment or that you
> can prove that one can never be created?
Exact static type checking is provably undecidable.
Joe Marshall wrote:
> Exact static type checking is provably undecidable.
I can see how that can be, but what exactly does "type" mean in that
sentence?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
> I can see how that can be, but what exactly does "type" mean in that
> sentence?
It means "lisp syntax and typing isn't what you like and you've yet to
come up with an argument that we haven't seen and rejected". I realize
that you think that we're wrong, but you've passed helpful and are well
into rude, even if we ignore your false assumption that we don't know
about other languages. Feel free to tell other people that we've
ignored your valuable advice.
If, as I expect, you persist, please tell us why you're doing us this
big favor. Do you think that we're going to change lisp to suit you?
Do you think that we're going to abandon it? If we wrote "gee, you're
really smart and lisp sucks?" would you leave us alone in our sin?
Jon Harrop <······@jdh30.plus.com> writes:
> Joe Marshall wrote:
>> Exact static type checking is provably undecidable.
>
> I can see how that can be, but what exactly does "type" mean in that
> sentence?
Well, here we get into one of the tricky issues between the `dynamic'
and `static' camps.
Aficionados of dynamic checking (like myself) consider a type to be a
set with a membership predicate and some associated operations. One
would ask ``Is this object an integer?'' and expect a yes or no
answer. If yes, one would therefore expect to be able to add,
subtract, multiply, etc.
Aficionados of static checking consider a type to be a *syntactic*
property of an expression. This may be loosely associated with the
actual *value* computed at runtime, but that isn't necessarily the
case (for instance, side-effects can be expressed as a `type'). Once
you assign types to the expressions in a program, you can apply rules
to reason about the program and prove certain properties about it
without actually running the program.
In the sentence above, I was attempting to use the `static'
definition.
On Thu, 29 Sep 2005 11:34:56 -0400, Joe Marshall wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>
>> Joe Marshall wrote:
>>> Exact static type checking is provably undecidable.
>>
>> I can see how that can be, but what exactly does "type" mean in that
>> sentence?
>
> Well, here we get into one of the tricky issues between the `dynamic'
> and `static' camps.
>
...
>In the sentence above, I was attempting to use the `static'
>definition.
for example:
let ident x = x;;
let f x = x x in f ident;;
is un-typable even with recursive types:(see
http://www.seas.upenn.edu/~sweirich/types/archive/1992/msg00095.html)
however it is obvious that f ident --> ident
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
On Thu, 29 Sep 2005 16:51:11 -0500, Matthew D Swank wrote:
>
> is un-typable even with recursive types:(see
> http://www.seas.upenn.edu/~sweirich/types/archive/1992/msg00095.html)
>
>
That should say f x = x x is only typeable in an undecidable system ( in
the case of the sited paper F-omega )
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Matthew D Swank wrote:
> for example:
>
> let ident x = x;;
> let f x = x x in f ident;;
>
> is only typeable in an undecidable system (see
> http://www.seas.upenn.edu/~sweirich/types/archive/1992/msg00095.html)
>
> however it is obvious that f ident --> ident
That's very interesting. From a completely lay point of view, I'd have
expected software to handle that in much the same way that CASs handle
infinite series.
Are any such functions useful? Okasaki gives examples of useful code
requiring polymorphic recursion but that can be expressed in OCaml.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
On Thu, 29 Sep 2005 23:34:17 +0100, Jon Harrop wrote:
> Are any such functions useful? Okasaki gives examples of useful code
> requiring polymorphic recursion but that can be expressed in OCaml.
Well, there are lots of useful functions in one area with which I have
interest (programming languages).
Most statically typed languages can get around typing problems by using by
offering recursive types (but you lose the ability to prove certain things
about the code*), or by wrapping the pesky un-typable objects (but you
lose some of the "advantage" of static typing)
See also: http://www.cse.msu.edu/~dunham/ycomb.html
Matt
*google curry-howard isomorphism or look up just about any flame war on
lambda-the-ultimate.org on typing.
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Matthew D Swank wrote:
> for example:
>
> let ident x = x;;
> let f x = x x in f ident;;
>
> is un-typable even with recursive types:(see
> http://www.seas.upenn.edu/~sweirich/types/archive/1992/msg00095.html)
>
> however it is obvious that f ident --> ident
I just thought I would actually try this and it seems to work ok:
$ ocaml -rectypes
Objective Caml version 3.08.0
# let ident x = x;;
val ident : 'a -> 'a = <fun>
# let f x = x x in f ident;;
- : 'a -> 'a as 'a = <fun>
So I'm not sure about your "un-typable even with recursive types".
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
On Wed, 05 Oct 2005 01:28:08 +0100, Jon Harrop wrote:
> # let ident x = x;;
> val ident : 'a -> 'a = <fun>
> # let f x = x x in f ident;;
> - : 'a -> 'a as 'a = <fun>
>
> So I'm not sure about your "un-typable even with recursive types".
Fair enough. I this is because OCaml can use universally quantified
types as well. There do exist untypable examples even so
(see the end of Programming Examples Needing Polymorphic Recursion:
http://itrs04.di.unito.it/papers/hk.pdf).
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Matthew D Swank wrote:
> Fair enough. I this is because OCaml can use universally quantified
> types as well. There do exist untypable examples even so
> (see the end of Programming Examples Needing Polymorphic Recursion:
> http://itrs04.di.unito.it/papers/hk.pdf).
OCaml can also type polymorphic recursion, albeit not directly.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Joe Marshall wrote:
> Aficionados of dynamic checking (like myself) consider a type to be a
> set with a membership predicate and some associated operations. One
> would ask ``Is this object an integer?'' and expect a yes or no
> answer. If yes, one would therefore expect to be able to add,
> subtract, multiply, etc.
I guess you could define "type" that way, yes.
> Aficionados of static checking consider a type to be a *syntactic*
> property of an expression. This may be loosely associated with the
> actual *value* computed at runtime, but that isn't necessarily the
> case (for instance, side-effects can be expressed as a `type').
I'd say that *because* checks are made syntactic annotations (or
inferred), they can be optimized away, so the types don't *need* to be
there at runtime. (e.g. an adding function doesn't need to check for
integers because the arguments are statically enforced to be integers.
I guess a (under-the-hood) type-checking Lisp compiler does exactly the
same thing.)
> Once
> you assign types to the expressions in a program, you can apply rules
> to reason about the program and prove certain properties about it
> without actually running the program.
Yes. And it allows to do some checks at compile-time and leave them out
of the compiled code (by statically enforcing properties of values).
Of course if you don't care what properties some value might have (i.e.
you're leaving it open), dynamic typing is exactly the thing to use.
--
Do or do not. There is no try.
Yoda
Ulrich Hobelmann wrote:
> Of course if you don't care what properties some value might have (i.e.
> you're leaving it open), dynamic typing is exactly the thing to use.
For that single value, yes.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Joe Marshall wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> Joe Marshall wrote:
>>> Exact static type checking is provably undecidable.
> ...
> Aficionados of static checking consider a type to be a *syntactic*
> property of an expression. This may be loosely associated with the
> actual *value* computed at runtime, but that isn't necessarily the
> case (for instance, side-effects can be expressed as a `type'). Once
> you assign types to the expressions in a program, you can apply rules
> to reason about the program and prove certain properties about it
> without actually running the program.
Interesting. I had assumed that the ML type of an expression was the set of
possible values.
> In the sentence above, I was attempting to use the `static'
> definition.
Ok. I'll have to dig out the formal proof. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
In comp.lang.lisp Christopher C. Stacy <······@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.
Matthias Buelow wrote:
> In comp.lang.lisp Christopher C. Stacy <······@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 <··@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.
On Tue, 27 Sep 2005 20:27:18 +0200, Pascal Costanza <··@p-cos.net>
wrote:
>Meanwhile the computer that I could have at my disposal is doing
>nothing. That's a waste of computational resources.
Join BOINC. http://boinc.berkeley.edu/
George
--
for email reply remove "/" from address
On 9246 day of my life Pascal Costanza wrote:
>> The classical approach is to sit down at the desk with pencil...
>
> Meanwhile the computer that I could have at my disposal is doing
> nothing. That's a waste of computational resources.
There are lot of wonderful projects like <http://www.mersenne.org> or
<http://www.distributed.net> :)
--
Ivan Boldyrev
| recursion, n:
| See recursion
Ivan Boldyrev wrote:
> On 9246 day of my life Pascal Costanza wrote:
>
>>>The classical approach is to sit down at the desk with pencil...
>>
>>Meanwhile the computer that I could have at my disposal is doing
>>nothing. That's a waste of computational resources.
>
> There are lot of wonderful projects like <http://www.mersenne.org> or
> <http://www.distributed.net> :)
Sorry, I am too egoistic for that. I'd rather listen to some music... ;)
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
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 ++++
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
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 ++++
Matthias Buelow <···@incubus.de> writes:
> In comp.lang.lisp Ron Garret <·········@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.
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 comp.lang.lisp Christopher C. Stacy <······@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 <··············@news.dfncis.de>,
Matthias Buelow <···@incubus.de> wrote:
> In comp.lang.lisp Christopher C. Stacy <······@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
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
In article <·························@ptn-nntp-reader04.plus.net>,
Jon Harrop <······@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
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
In article <·························@ptn-nntp-reader01.plus.net>,
Jon Harrop <······@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
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:
> 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
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 ++++
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 ++++
In comp.lang.lisp Pascal Costanza <··@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.
Matthias Buelow wrote:
> In comp.lang.lisp Pascal Costanza <··@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 <··@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 ++++
Pascal Costanza <··@p-cos.net> writes:
> Matthias Buelow wrote:
>
> > In comp.lang.lisp Pascal Costanza <··@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
In comp.lang.lisp Pascal Costanza <··@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 <··@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 ++++
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."
Matthias Buelow wrote:
> In comp.lang.lisp Ron Garret <·········@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 ++++
Pascal Costanza <··@p-cos.net> writes:
> Matthias Buelow wrote:
>
>> In comp.lang.lisp Ron Garret <·········@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
In article <··············@hanabi.local>,
Matthias Blume <····@my.address.elsewhere> wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
> > Matthias Buelow wrote:
> >
> >> In comp.lang.lisp Ron Garret <·········@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
Ron Garret <·········@flownet.com> writes:
> In article <··············@hanabi.local>,
> Matthias Blume <····@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! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
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 ++++
Pascal Costanza <··@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 * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
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
Jon Harrop <······@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 * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
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 <······@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!
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
Matthias Buelow writes:
> In comp.lang.lisp Ron Garret <·········@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
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?"
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
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 ++++
Ulrich Hobelmann wrote:
> 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.
In a sense a Lisp function cannot crash. What can happen is that an
error or a condition is signalled, but it might be dealt with at a
higher level. A well-functioning (avoiding the term "correct" here :-)
lisp program can very well have a function in it that signals a type
error half of the times it is called, yet the program as a whole behaves
as intended because this error is dealt with by its callers. I think
this is a fundamental philosophical difference between Lisp and static
languages that causes a lot of the confusion in arguments such as these.
Bj�rn
Bj�rn Lindberg wrote:
> In a sense a Lisp function cannot crash. What can happen is that an
> error or a condition is signalled, but it might be dealt with at a
> higher level. A well-functioning (avoiding the term "correct" here :-)
> lisp program can very well have a function in it that signals a type
> error half of the times it is called, yet the program as a whole behaves
> as intended because this error is dealt with by its callers. I think
> this is a fundamental philosophical difference between Lisp and static
> languages that causes a lot of the confusion in arguments such as these.
I don't quite follow you here. In a statically typed language you can choose
to use either a type ossified at compile time (the static type checker will
then enforce correct use of it) or you can use a sum type to defer checking
to run time. The latter is equivalent to dynamic type checking (you can
generate and handle your own run-time type errors).
An obvious practical example of this is when you're writing an interpreter
for a dynamically typed language in a statically typed language.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
>
>
> I don't quite follow you here. In a statically typed language you can choose
> to use either a type ossified at compile time (the static type checker will
> then enforce correct use of it) or you can use a sum type to defer checking
> to run time. The latter is equivalent to dynamic type checking (you can
> generate and handle your own run-time type errors).
>
It means you can write functions which call functions that do not
exist. This means you can write high level functions before low level
ones and either use the debugger or some kind of error handler to
stub out the situation.
CL-USER 1 > (defun caller ()
(no-function 10)) ; no-function does not exist
CALLER
CL-USER 2 > (caller)
Error: Undefined function NO-FUNCTION called with arguments (10).
1 (continue) Try invoking NO-FUNCTION again.
2 Return some values from the call to NO-FUNCTION.
3 Try invoking something other than NO-FUNCTION with the same arguments.
4 Set the symbol-function of NO-FUNCTION to another function.
5 (abort) Return to level 0.
6 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
CL-USER 3 : 1 > :c 2
Enter a form to be evaluated: (+ 2 3)
5
CL-USER 4 >
Wade Humeniuk wrote:
> It means you can write functions which call functions that do not
> exist.
Yes. I actually write programs that way in OCaml. I'm not sure how so I'll
try to watch myself next time I'm doing it. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Wade Humeniuk <··················@telus.net> wrote:
>It means you can write functions which call functions that do not
>exist. This means you can write high level functions before low level
>ones and either use the debugger or some kind of error handler to
>stub out the situation.
The first part has nothing to do with static vs. dynamic typing. A
statically typed language could be defined to make all definitions in a
compilation unit (file, module, ...) "parallel", the compiler could
implement this easily by using several passes.
The second part (debugger) is true. I think that most programmers of
"serious" statically typed languages (*ML, Haskell, probably Ada and the
likes aswell) find the idea of rummaging around in a running program and
redefining things abhorrend. From my personal experience, I had to
spend a lot more time in the Lisp toplevel and pasting new definitions
of functions into it, because of stupid type errors (function arity
mismatches, wrong order of arguments, etc.) than in Standard ML, where
the compiler catches those for me and I only use the toplevel for trying
out little things.
mkb.
Matthias Buelow wrote:
> The second part (debugger) is true. I think that most programmers of
> "serious" statically typed languages (*ML, Haskell, probably Ada and the
> likes aswell) find the idea of rummaging around in a running program and
> redefining things abhorrend. From my personal experience, I had to
> spend a lot more time in the Lisp toplevel and pasting new definitions
> of functions into it, because of stupid type errors (function arity
> mismatches, wrong order of arguments, etc.) than in Standard ML, where
> the compiler catches those for me and I only use the toplevel for trying
> out little things.
I've been writing a lot of GUI code recently. It is dynamic by nature but
I'm implementing it in a statically typed language. So I have a lots of
functions with big pattern matches that generate a run-time error if they
don't understand their input. I'm debugging it in two ways:
1. The conventional dynamic typing way of looking at the program state when
things fail.
2. Converting dynamically typed code into statically typed code so the
compiler proves its correctness to the largest possible extent.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> wrote:
>I've been writing a lot of GUI code recently. It is dynamic by nature but
>I'm implementing it in a statically typed language. So I have a lots of
>functions with big pattern matches that generate a run-time error if they
>don't understand their input. I'm debugging it in two ways:
Hmm, I have no experience with GUI programming in ML or Haskell or so.
However, from my limited experience, I'd think that this is a good
domain for runtime-typed languages. I have some experience with
Xt/Motif (programmed in plain, silly C), and I remember how relaxed
things went in some tcl/tk examples that I've tried, compared to Motif
[although that might've been a C vs. TCL "benchmark" but the dynamic
way of TCL was like night vs. day, compared to Motif. Since then, I
don't understand why people still write GUIs in C or C++ (or Java). Or
even develop new toolkits in those languages (GTK, Qt). It's just a
major PITA. Since then I also understand the power of using the right
notation/language for a particular job.]
mkb.
I wrote:
>Or even develop new toolkits in those languages (GTK, Qt).
Correction: That ought to say "_for_ those languages", of course. It
doesn't really matter what the innards of the toolkit are programmed in
(as long as it is extensible). But the target language for GUI
development surely matters.
mkb.
Matthias Buelow wrote:
> Correction: That ought to say "_for_ those languages", of course. It
> doesn't really matter what the innards of the toolkit are programmed in
> (as long as it is extensible). But the target language for GUI
> development surely matters.
Have you tried writing bindings for Qt to another language?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> wrote:
>Have you tried writing bindings for Qt to another language?
No, I do know however, that bindings for gtk exist for many languages.
Qt might be a bit more difficult, due to its C++ishness.
mkb.
Matthias Buelow wrote:
> Jon Harrop <······@jdh30.plus.com> wrote:
>>Have you tried writing bindings for Qt to another language?
>
> No, I do know however, that bindings for gtk exist for many languages.
> Qt might be a bit more difficult, due to its C++ishness.
Not even C++ishness - Qt uses a language that is compiled into C++. Looks
pretty hideous to me. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Bj�rn Lindberg wrote:
> In a sense a Lisp function cannot crash. What can happen is that an
> error or a condition is signalled, but it might be dealt with at a
> higher level. A well-functioning (avoiding the term "correct" here :-)
> lisp program can very well have a function in it that signals a type
> error half of the times it is called, yet the program as a whole behaves
> as intended because this error is dealt with by its callers. I think
> this is a fundamental philosophical difference between Lisp and static
> languages that causes a lot of the confusion in arguments such as these.
True. In a static language you would define the type Lisp-value as a
union of lots of other types.
An error in Lisp would correspond to a not-matched error in the static
language, i.e. functions in the static language would only do
pattern-matching on part of Lisp-value, leaving the other cases to
signal a runtime error.
As I said, you can use narrow types and have strong typing with maybe
lots of declarations, or you can use one wide type and leave more to
runtime.
--
Do or do not. There is no try.
Yoda
Ulrich Hobelmann wrote:
> Bj�rn Lindberg wrote:
>
>> In a sense a Lisp function cannot crash. What can happen is that an
>> error or a condition is signalled, but it might be dealt with at a
>> higher level. A well-functioning (avoiding the term "correct" here :-)
>> lisp program can very well have a function in it that signals a type
>> error half of the times it is called, yet the program as a whole
>> behaves as intended because this error is dealt with by its callers. I
>> think this is a fundamental philosophical difference between Lisp and
>> static languages that causes a lot of the confusion in arguments such
>> as these.
>
>
> True. In a static language you would define the type Lisp-value as a
> union of lots of other types.
>
> An error in Lisp would correspond to a not-matched error in the static
> language, i.e. functions in the static language would only do
> pattern-matching on part of Lisp-value, leaving the other cases to
> signal a runtime error.
Yes, but as I said that runtime error might be handled at a higher
level. So the same piece of code might be "in error" or not depending on
the dynamic context where it is executed. I wouldn't want a static
analysis tool to prevent me from using this code because it couldn't
figure out the dynamic context it would be run in.
> As I said, you can use narrow types and have strong typing with maybe
> lots of declarations, or you can use one wide type and leave more to
> runtime.
Right, and I want to always leave it to runtime. Moreover, I want a
language that is designed around and supports that. This is the
philosophical difference.
Bj�rn
Bj�rn Lindberg wrote:
>> An error in Lisp would correspond to a not-matched error in the static
>> language, i.e. functions in the static language would only do
>> pattern-matching on part of Lisp-value, leaving the other cases to
>> signal a runtime error.
>
> Yes, but as I said that runtime error might be handled at a higher
> level. So the same piece of code might be "in error" or not depending on
> the dynamic context where it is executed. I wouldn't want a static
> analysis tool to prevent me from using this code because it couldn't
> figure out the dynamic context it would be run in.
SML allows you to run it (but gives a warning that the defined
pattern-match is only partial). I think it throws an exception at
runtime, so you could probably catch that dynamically.
>> As I said, you can use narrow types and have strong typing with maybe
>> lots of declarations, or you can use one wide type and leave more to
>> runtime.
>
> Right, and I want to always leave it to runtime. Moreover, I want a
> language that is designed around and supports that. This is the
> philosophical difference.
Yes.
--
Do or do not. There is no try.
Yoda
Ulrich Hobelmann wrote:
> Bj�rn Lindberg wrote:
>>> An error in Lisp would correspond to a not-matched error in the static
>>> language, i.e. functions in the static language would only do
>>> pattern-matching on part of Lisp-value, leaving the other cases to
>>> signal a runtime error.
>>
>> Yes, but as I said that runtime error might be handled at a higher
>> level. So the same piece of code might be "in error" or not depending on
>> the dynamic context where it is executed. I wouldn't want a static
>> analysis tool to prevent me from using this code because it couldn't
>> figure out the dynamic context it would be run in.
>
> SML allows you to run it (but gives a warning that the defined
> pattern-match is only partial). I think it throws an exception at
> runtime, so you could probably catch that dynamically.
Yes, the same in OCaml. There is no difference between static and dynamic
typing here, of course.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
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
Ron Garret <·········@flownet.com> writes:
> In article <·······················@z14g2000cwz.googlegroups.com>,
> "Kris Cipa" <············@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
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)
Ulrich 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
Luis Oliveira <·············@deadspam.com> writes:
> Ulrich 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!
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
On 2005-09-25, Jon Harrop <······@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
Julian Squires wrote:
> On 2005-09-25, Jon Harrop <······@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
On 2005-09-25, Jon Harrop <······@jdh30.plus.com> wrote:
> Julian Squires wrote:
>> On 2005-09-25, Jon Harrop <······@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 <······@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
In article <·························@ptn-nntp-reader04.plus.net>,
Jon Harrop <······@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:
> In article <·························@ptn-nntp-reader04.plus.net>,
> Jon Harrop <······@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® .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 <·························@ptn-nntp-reader04.plus.net>,
> Jon Harrop <······@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
In article <·························@ptn-nntp-reader01.plus.net>,
Jon Harrop <······@jdh30.plus.com> wrote:
> Ron Garret wrote:
> > In article <·························@ptn-nntp-reader04.plus.net>,
> > Jon Harrop <······@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
Ron Garret wrote:
> In article <·························@ptn-nntp-reader01.plus.net>,
> Jon Harrop <······@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
From: Richard Fateman
Subject: Re: What's so great about lisp? --> Jon, pack up your troll hat
Date:
Message-ID: <43381BE1.4070007@cs.berkeley.edu>
Jon Harrop wrote:
> Ron Garret wrote:
>
>>In article <·························@ptn-nntp-reader01.plus.net>,
>> Jon Harrop <······@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.
Ron Garret <·········@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.
In article <··············@news.dfncis.de>,
Matthias Buelow <···@incubus.de> wrote:
> Ron Garret <·········@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
Matthias Buelow <···@incubus.de> writes:
> Ron Garret <·········@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 * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Matthias Buelow <···@incubus.de> writes:
> 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?
No. I had to drive well out of my way to find Lisp. Then I had to
take the trouble to learn it with all sorts of things distracting me.
And with all that, Lisp is so different from the languages I've been
using since I was 12 that my entire way of thinking about programming
has had to change. For me, it has been a long and scenic road. Now
I'm at a point where I'm enjoying the trip.
--
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!
David Steuber <·····@david-steuber.com> wrote:
>No. I had to drive well out of my way to find Lisp. Then I had to
>take the trouble to learn it with all sorts of things distracting me.
>And with all that, Lisp is so different from the languages I've been
>using since I was 12 that my entire way of thinking about programming
>has had to change. For me, it has been a long and scenic road. Now
>I'm at a point where I'm enjoying the trip.
I've made that trip already. The landscape is nice initially but
gets boring after a while. ;)
mkb.
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 ++++
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
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:
>
> 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
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
From: Christopher C. Stacy
Subject: Re: What's so great about lisp? / Languages implemented in Lisp
Date:
Message-ID: <ud5mwmus1.fsf@news.dtpq.com>
Richard 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.
Jon Harrop <······@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...)
Christopher C. Stacy wrote:
> Jon Harrop <······@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
On 2005-09-26, Jon Harrop <······@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
Julian Squires wrote:
> On 2005-09-26, Jon Harrop <······@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
Julian Squires <······@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.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Julian Squires <······@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?
* Lars Brinkhoff [2005-09-27 12:33]:
> ····@rpw3.org (Rob Warnock) writes:
> > Julian Squires <······@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 * ····@hellug.gr
Alexandros Diamantidis <····@hellug.gr> wrote:
+---------------
| * Lars Brinkhoff [2005-09-27 12:33]:
| > ····@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.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Giorgos Keramidas
Subject: Re: What's so great about lisp?
Date:
Message-ID: <86y85fifpz.fsf@flame.pc>
····@rpw3.org (Rob Warnock) writes:
> Alexandros Diamantidis <····@hellug.gr> wrote:
> +---------------
> | * Lars Brinkhoff [2005-09-27 12:33]:
> | > ····@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? ;-}
HEH! It looks like somebody is using strcpy() when he really means
memcpy() somewhere :)
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: What's so great about lisp?
Date:
Message-ID: <871x39w0k4.fsf@qrnik.zagroda>
Ron Garret <·········@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).
Counterexamples to the last point:
- threads
- weak references and finalizers
- interfacing with libraries implemented in C
They are only usable if they are provided by the language implementation,
they can't be easily added later. They are also not in the Lisp standard,
and their availability in various Lisp implementations vary.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: What's so great about lisp?
Date:
Message-ID: <873bnpoyta.fsf@qrnik.zagroda>
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Counterexamples to the last point:
> - threads
> - weak references and finalizers
> - interfacing with libraries implemented in C
More:
- asynchronous interruption of a computation, including temporary
blocking of asynchronous signals by that computation to indicate
safe points for interruption (this feature depends on threads,
but basic threading interfaces themselves often don't include it)
- recovering from memory overflow
- tail call optimization (some Lisp implementation only handle tail
recursion without growing the stack)
- execution of untrusted code in a sandbox, guaranteeing limited
access to the OS and no undefined behavior even for malicious code
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
>
>> Counterexamples to the last point:
>> - threads
>> - weak references and finalizers
>> - interfacing with libraries implemented in C
>
> More:
> - asynchronous interruption of a computation, including temporary
> blocking of asynchronous signals by that computation to indicate
> safe points for interruption (this feature depends on threads,
> but basic threading interfaces themselves often don't include it)
> - recovering from memory overflow
> - tail call optimization (some Lisp implementation only handle tail
> recursion without growing the stack)
> - execution of untrusted code in a sandbox, guaranteeing limited
> access to the OS and no undefined behavior even for malicious code
Actually I think this last one is doable in user-land: since you're
going to be providing a restricted subset of the full language (either
by omitting certain features or by providing the features but limiting
the capabilities (e.g. you can still open files but only under a
certain directory) you just go ahead and implement a Safe Lisp ->
Common Lisp compiler that does whatever static checking you want at
compile time and inserts whatever run-time checking code you want into
the generated Common Lisp.
And in fact, this is, I expect, the only sane way to do things--start
with a completely safe (but not very useful language) and then
carefully add features to build up the functionality without
compromising safety, for whatever definition of safety you care about.
To get folks started here's a first version of the Safe Lisp compiler:
(defun compile-safe-lisp (form)
(if form
(error "Program too long.")
(compile nil '(lambda () ()))))
Of course you may want to write your own reader, to make sure someone
doesn't try to knock over the host Lisp by feeding it a malicious
program text (say "(" followed by several gigabytes of characters not
containing a ")".)
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: What's so great about lisp?
Date:
Message-ID: <874q84q586.fsf@qrnik.zagroda>
Peter Seibel <·····@gigamonkeys.com> writes:
>> - execution of untrusted code in a sandbox, guaranteeing limited
>> access to the OS and no undefined behavior even for malicious code
>
> Actually I think this last one is doable in user-land:
Of course all features I mentioned are implementable by writing
an interpreter or compiler.
I don't know how exactly running applets in WWW browsers work, but
I'm pretty sure that their translator is a regular Java compiler,
and restrictions are then applied at runtime.
When most features of the language are allowed, this is more robust
than applying restrictions on the source level, because it doesn't
need to track various "reflective" ways of accessing features to be
restricted.
OTOH applying restrictions at the source level is simpler when the
allowed language is small and every allowed language feature is
explicitly introduced.
Disclaimer: this is my guesswork, I haven't worked with sandboxes
in practice.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>>> - execution of untrusted code in a sandbox, guaranteeing limited
>>> access to the OS and no undefined behavior even for malicious code
>>
>> Actually I think this last one is doable in user-land:
>
> Of course all features I mentioned are implementable by writing
> an interpreter or compiler.
Yes. But this is one that, I'd argue, probably *should* be implemented
as a separate compiler. And Common Lisp makes that particularly easy
to do since you can just compile into Common Lisp as your target
language.
> I don't know how exactly running applets in WWW browsers work, but
> I'm pretty sure that their translator is a regular Java compiler,
> and restrictions are then applied at runtime.
That's basically true. However that's possible partly because Java
itself *was* designed from the ground up to be sandboxed--there are
restrictions on Java bytecodes to prevent certain kinds of attacks and
the VM verifies those restrictions when it loads a .class file.
> When most features of the language are allowed, this is more robust
> than applying restrictions on the source level, because it doesn't
> need to track various "reflective" ways of accessing features to be
> restricted.
Actually I'd argue it's the other way around--if you want to use only
runtime checks, every piece of code that could potentially do
something that you want to disallow has to be specifically written to
check whether it's allowed to do so. If anyone writing code for the
JDK slips up and adds a code-path that omits the proper security
checks, that's a security hole.
> OTOH applying restrictions at the source level is simpler when the
> allowed language is small and every allowed language feature is
> explicitly introduced.
Well, I think locking down a big, general purpose language is a fool's
errand so the smart way to build a safe language is to build it up
from nothing with every allowed language feature explicitly
introduced. This is much like the principle behind making a secure
computer--you don't start with all the possible daemons running and
then try and turn off the ones that you think might introduce a
security hole--you start with no daemons and then turn on only those
you need to do what you've got to do, checking each of them carefully
to make sure they don't allow any unsanctioned activities.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: What's so great about lisp?
Date:
Message-ID: <87r7b8ls2t.fsf@qrnik.zagroda>
Peter Seibel <·····@gigamonkeys.com> writes:
> That's basically true. However that's possible partly because Java
> itself *was* designed from the ground up to be sandboxed--there are
> restrictions on Java bytecodes to prevent certain kinds of attacks
> and the VM verifies those restrictions when it loads a .class file.
That's why I gave it as an example of a feature which cannot be easily
implemented as a library, even in Common Lisp.
> Actually I'd argue it's the other way around--if you want to use
> only runtime checks, every piece of code that could potentially do
> something that you want to disallow has to be specifically written
> to check whether it's allowed to do so. If anyone writing code for
> the JDK slips up and adds a code-path that omits the proper security
> checks, that's a security hole.
I agree that it's more robust to explicitly add some allowed features
starting from an empty language than to explicitly remove some
disallowed ones from the full one. But this requires a lot of work
once the set of allowed features is sufficiently large compared to
the set of disallowed ones.
If we already decided to disallow explicitly instead of allowing
explicitly, then it's better done on the low level in the runtime than
through examining the source.
Under the same decision a yet more robust sandbox would be done with
OS permissions. Java applet restrictions are too fine-grained for
implementing them on the OS level though.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
In comp.lang.lisp Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
>- execution of untrusted code in a sandbox, guaranteeing limited
> access to the OS and no undefined behavior even for malicious code
This is important even in mundane cases. This thought occurred to me a
couple months ago, when the topic was Lisp for games. Normally, one
would think that Lisp would (implementation- and performance issues
ignored for now) be excellent for all games that require a lot of
high-level scripting, like most games these days do (also first-person
shooters like Quake, rf. QuakeC) because you could export the same Lisp
to the user with all the benefits (compiler, etc.) Often the scripting
engine in which the game logics is written in, is exported, so that a
3rd-party (or the consumer) can modify aspects of the game (including
writing complete modifications, that turn the game into a rather
different one, like it is popular with Quake.) However.. how do you
protect the game from malicious programmers, if you export the Lisp to
the user? You want to make sure that certain parts of the game are
guaranteed off-limits to the scripter, to prevent the creation of
cheats, which would instantly make your game unusable for online gaming.
Common Lisp's packages would seem useful but there doesn't seem to be
any real protection, you can rummage around in those packages even from
the outside. Same way with CLOS, which doesn't employ visibility rules
and doesn't protect the innards of classes from modification from the
outside, unlike with C++, or Java, etc. What would be a good approach
to solve this problem, apart from simply writing an interpreter or
compiler for an ad-hoc language, like it would be done with any other
language?
mkb.
Matthias Buelow <···@incubus.de> writes:
> What would be a good approach to solve this problem, apart from simply
> writing an interpreter or compiler for an ad-hoc language, like it would be
> done with any other language?
I think writing an interpreter is really the only solution. A proper sandbox
based solution can often be circumvented by altering the execution
environment.
Now, the ad-hoc language could in fact be subset of the Lips/Scheme itself,
and no one should need to be writing an evaluator from scratch, but
conceptually your app should invoke a specific evaluator that enforces the
restrictions desired.
It should be possible to express evaluators whose implementations are only a
few lines of code (essentially stating the allowable symbols and what
functions they map to).
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Matthias Buelow wrote:
> In comp.lang.lisp Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
>
>>- execution of untrusted code in a sandbox, guaranteeing limited
>> access to the OS and no undefined behavior even for malicious code
>
> This is important even in mundane cases. This thought occurred to me a
> couple months ago, when the topic was Lisp for games. Normally, one
> would think that Lisp would (implementation- and performance issues
> ignored for now) be excellent for all games that require a lot of
> high-level scripting, like most games these days do (also first-person
> shooters like Quake, rf. QuakeC) because you could export the same Lisp
> to the user with all the benefits (compiler, etc.) Often the scripting
> engine in which the game logics is written in, is exported, so that a
> 3rd-party (or the consumer) can modify aspects of the game (including
> writing complete modifications, that turn the game into a rather
> different one, like it is popular with Quake.) However.. how do you
> protect the game from malicious programmers, if you export the Lisp to
> the user? You want to make sure that certain parts of the game are
> guaranteed off-limits to the scripter, to prevent the creation of
> cheats, which would instantly make your game unusable for online gaming.
> Common Lisp's packages would seem useful but there doesn't seem to be
> any real protection, you can rummage around in those packages even from
> the outside. Same way with CLOS, which doesn't employ visibility rules
> and doesn't protect the innards of classes from modification from the
> outside, unlike with C++, or Java, etc. What would be a good approach
> to solve this problem, apart from simply writing an interpreter or
> compiler for an ad-hoc language, like it would be done with any other
> language?
You continually make languages like C++ and Java appear to have features
that they don't really have. In C++ you can cast away any protection the
languages purports to provide, and in Java it is also possible to bypass
the access modifiers. (And the good reason for this is there is actually
a class of programs that needs to bypass such protection, foremostly
debuggers.)
Admittedly, Java makes it harder by default to circumvent access
protection, but if you fuck up the access control configuration then
you're also screwed.
In Common Lisp, you could use uninterned symbols as slot names, or use
the Metaobject Protocol to write your own access protection for regular
slot access. However, this is also not complete.
The only way I see is to check the source code of the scripts, either by
providing an interpreter that does this on the fly, or by writing a
module that checks the source code before it is compiled. I don't think
there is an "easy" way to provide good protection.
(The access control configuration in Java is basically "just" a
domain-specific language for implementing such a checking stage.)
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
On Thu, 29 Sep 2005 00:57:07 +0200, Pascal Costanza wrote:
> You continually make languages like C++ and Java appear to have features
> that they don't really have. In C++ you can cast away any protection the
> languages purports to provide, and in Java it is also possible to bypass
> the access modifiers. (And the good reason for this is there is actually
> a class of programs that needs to bypass such protection, foremostly
> debuggers.)
Hmmm...but shouldn't security be the province of the OS/hardware* instead
of the language?
*Like for example TPM, and other access technologies.
Pascal Costanza <··@p-cos.net> wrote:
>You continually make languages like C++ and Java appear to have features
>that they don't really have. In C++ you can cast away any protection the
>languages purports to provide, and in Java it is also possible to bypass
Ok, I was a bit ambiguous here. I didn't want to say that C++, for
example, provides such a (hypothetical sandbox scripting) safe
environment by itself, in the way a Lisp runtime theoretically could, if
only because you cannot typically compile C++ code (easily) and load it
into the runtime. I was more talking about the (lack of) access
modifiers in general, in CLOS, which makes it even harder to isolate
certain functionality from other parts of a program.
>the access modifiers. (And the good reason for this is there is actually
>a class of programs that needs to bypass such protection, foremostly
>debuggers.)
Admittedly, on Unix (don't know how it is on Windows) you could probably
hack into /dev/mem at the appropriate address and by carefully runtime-
patching disable protective mechanisms. Or undergo some effort and
reverse-engineer and patch the anti-cheat tools. However, this is
wholly more effort (and probably beyond the means of the typical
teenager old who likes to cheat on online games) than being able to just
load a program and modify values (including functions) the "normal" way,
that is, in Lisp, through its evaluator.
>The only way I see is to check the source code of the scripts, either by
>providing an interpreter that does this on the fly, or by writing a
>module that checks the source code before it is compiled. I don't think
>there is an "easy" way to provide good protection.
Hmm.
mkb.
Matthias Buelow wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>
>>You continually make languages like C++ and Java appear to have features
>>that they don't really have. In C++ you can cast away any protection the
>>languages purports to provide, and in Java it is also possible to bypass
>
> Ok, I was a bit ambiguous here. I didn't want to say that C++, for
> example, provides such a (hypothetical sandbox scripting) safe
> environment by itself, in the way a Lisp runtime theoretically could, if
> only because you cannot typically compile C++ code (easily) and load it
> into the runtime.
It seems to me that you can. At least that's what a C programmer told me
in the case of C.
> I was more talking about the (lack of) access
> modifiers in general, in CLOS, which makes it even harder to isolate
> certain functionality from other parts of a program.
Use the right tools: The best way to protect access from the outside is
to use lexical closures - I am not aware of any way to access the
bindings closed over by a closure. (Although I recall reading about at
least one Common Lisp implementation that provides this as well, and
again, there are cases when you want this - at least in the case of
debuggers.)
>>the access modifiers. (And the good reason for this is there is actually
>>a class of programs that needs to bypass such protection, foremostly
>>debuggers.)
>
> Admittedly, on Unix (don't know how it is on Windows) you could probably
> hack into /dev/mem at the appropriate address and by carefully runtime-
> patching disable protective mechanisms. Or undergo some effort and
> reverse-engineer and patch the anti-cheat tools. However, this is
> wholly more effort (and probably beyond the means of the typical
> teenager old who likes to cheat on online games) than being able to just
> load a program and modify values (including functions) the "normal" way,
> that is, in Lisp, through its evaluator.
This is important: It's always only a relative measure. There is nothing
like complete security, unless you switch off your machine.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
On Thu, 29 Sep 2005 07:57:10 +0200, Pascal Costanza <··@p-cos.net>
wrote:
>Matthias Buelow wrote:
>> Pascal Costanza <··@p-cos.net> wrote:
>>
>>>You continually make languages like C++ and Java appear to have features
>>>that they don't really have. In C++ you can cast away any protection the
>>>languages purports to provide, and in Java it is also possible to bypass
>>
>> Ok, I was a bit ambiguous here. I didn't want to say that C++, for
>> example, provides such a (hypothetical sandbox scripting) safe
>> environment by itself, in the way a Lisp runtime theoretically could, if
>> only because you cannot typically compile C++ code (easily) and load it
>> into the runtime.
>
>It seems to me that you can. At least that's what a C programmer told me
>in the case of C.
C doesn't provide any standard way to _link_ code or data at runtime.
There are ad hoc methods for doing it, but they are all compiler
specific.
Basically you need to manually recreate everything the OS would do if
it were loading a DLL for the application. You need to read the
executable, decode the relocation information (if any), load the
code/data bytes into a buffer, use the relocation info to hot patch
the code (if necessary) to work at the current load address, and then
build a table of pointers to access the functions and data.
But there are still some gotchas. C has no RTTI or other built-in
reflective features. To access data or call functions correctly, you
need to know the data types and function signatures. That information
either has to be built into the main application at compile time or it
must encoded in the load module and figured out at runtime by the
application (like a debugger).
I have heard (but not verified) that there is a library to do this
available for 32-bit Linux on x86 CPUs.
There are some easier alternatives though.
There are a number of embeddable C interpreters which, obviously will
handle linkage of interpreted code at runtime. However, I have never
used any of them so I can't say how or to what degree they can
interact with the hosting application.
There is also at least one embeddable native x86 compiler (tinycc)
which compiles directly to RAM. Similar deal as above, you compile
extension code into a buffer and call it through function pointers.
George
--
for email reply remove "/" from address
George Neuner <·········@comcast.net> writes:
> On Thu, 29 Sep 2005 07:57:10 +0200, Pascal Costanza <··@p-cos.net>
> wrote:
>
> >Matthias Buelow wrote:
> >> Pascal Costanza <··@p-cos.net> wrote:
> >>
> >> /.../ if
> >> only because you cannot typically compile C++ code (easily) and load it
> >> into the runtime.
> >
> >It seems to me that you can. At least that's what a C programmer told me
> >in the case of C.
>
> C doesn't provide any standard way to _link_ code or data at runtime.
> There are ad hoc methods for doing it, but they are all compiler
> specific.
Well, I'd say *system* specific. For instance, you have dlopen() and
friend on various Unices, which provide a bare-bones interface to the
dynamic linker. Other OSes might have similar functions. You can thus
conceivably invoke gcc, generate an appropriate object file and
dynamically link it into your system. (I definitely agree that there
is still quite some way to go to get to the level of Lisp, of
course. Claiming that it is "easily" done strains the argument.)
Some C-like languages and libraries also provide support for direct
dynamic code generation; this was quite popular in academia a few
years ago (tcc, vcode, DyC, ...). I haven't looked at it much myself,
but "Gnu Lightning" can be downloaded:
http://www.gnu.org/software/lightning/lightning.html
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
On Mon, 03 Oct 2005 16:43:44 GMT, Thomas Lindgren
<···········@*****.***> wrote:
>George Neuner <·········@comcast.net> writes:
>
>> C doesn't provide any standard way to _link_ code or data at runtime.
>> There are ad hoc methods for doing it, but they are all compiler
>> specific.
>
>Well, I'd say *system* specific. For instance, you have dlopen() and
>friend on various Unices, which provide a bare-bones interface to the
>dynamic linker. Other OSes might have similar functions. You can thus
>conceivably invoke gcc, generate an appropriate object file and
>dynamically link it into your system.
I was referring to dynamic linking without OS help. I refrained from
saying "system" because specialized functions like dlopen(),
LoadLibrary() and their ilk really are not necessary. Using them
saves some effort because you get code rebasing for free, but rebasing
can be done manually provided you can interpret the executable format.
That's why I said "compiler specific". For many systems, everything
can be done using only POSIX system calls.
The one thing that really is system specific is convincing the CPU to
execute object code from a data buffer ... some systems just won't
allow data to be executed. Such systems require changing the
protection access rights on the data buffer locations before the
contents can be regarded as code. And maybe also the reverse if you
need to treat code as data.
>Some C-like languages and libraries also provide support for direct
>dynamic code generation; this was quite popular in academia a few
>years ago (tcc, vcode, DyC, ...). I haven't looked at it much myself,
>but "Gnu Lightning" can be downloaded:
>
>http://www.gnu.org/software/lightning/lightning.html
In-memory code generators have (re)gained popularity recently riding
the awareness of JIT compilation. There are apparently quite a few
available. I haven't looked at them in quite a while but I remember
the few I tried several years ago as being buggy and very hard to use.
For the sake of anyone trying them now, I hope the situation has
improved.
George
--
for email reply remove "/" from address
In <··············@news.dfncis.de> Matthias Buelow <···@incubus.de> writes:
>Common Lisp's packages would seem useful but there doesn't seem to be
>any real protection, you can rummage around in those packages even from
I don't know about Common Lisp specifically, but in any language where
you can't forge a reference there is this possibility of
reachability-based security. Say, run the code in a namespace where all
"dangerous" names have been purged or shadowed. What if the program
opens some package for more dangerous services? Well, shadow the
package-opening feature. What if the code constructs a symbol from a
string and tries to get its value? Well, arrange symbols to be resolved
in the safe namespace.
Maybe Common Lisp makes this somehow hard, but it's definitely not a
fundamental feature of Lisp in general.
Panu
--
personal contact: ······@iki.fi, +35841 5323835, +3589 85619369
work contact: ················@helsinki.fi, +35850 3678003
kotisivu (henkkoht): http://www.iki.fi/atehwa/
homepage (technical): http://sange.fi/~atehwa/
From: James Graves
Subject: Security within Lisp (was Re: What's so great about lisp?)
Date:
Message-ID: <dhog6m$l28$1@new7.xnet.com>
Panu Kalliokoski <······@sange.fi> wrote:
>I don't know about Common Lisp specifically, but in any language where
>you can't forge a reference there is this possibility of
>reachability-based security. Say, run the code in a namespace where all
>"dangerous" names have been purged or shadowed. What if the program
>opens some package for more dangerous services? Well, shadow the
>package-opening feature. What if the code constructs a symbol from a
>string and tries to get its value? Well, arrange symbols to be resolved
>in the safe namespace.
>
>Maybe Common Lisp makes this somehow hard, but it's definitely not a
>fundamental feature of Lisp in general.
There's been work in this direction already. One of the most important
papers on this was written by Jonathan Rees:
http://mumble.net/~jar/pubs/secureos/
I'm also just starting out on some work to create a version of Scheme
with full object-level confinement. You can search for recent posts in
e-lang:
http://www.eros-os.org/pipermail/e-lang/
the Scheme 48 mailing list:
gmane.lisp.scheme.scheme48 at http://www.gmane.org
and the caplisp mailing list:
http://lists.sourceforge.net/lists/listinfo/caplisp-devel
Cheers,
James Graves
In article <··············@qrnik.zagroda>,
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> Ron Garret <·········@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).
>
> Counterexamples to the last point:
> - threads
> - weak references and finalizers
> - interfacing with libraries implemented in C
>
> They are only usable if they are provided by the language implementation,
> they can't be easily added later. They are also not in the Lisp standard,
> and their availability in various Lisp implementations vary.
I concede that point, although I note that very few languages actually
have these features.
rg
"Kris Cipa" <············@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
I know one should not answer things like this, but maybe just a little
bit won't hurt :)
In <·······················@z14g2000cwz.googlegroups.com> "Kris Cipa" <············@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: ······@iki.fi, +35841 5323835, +3589 85619369
work contact: ················@helsinki.fi, +35850 3678003
kotisivu (henkkoht): http://www.iki.fi/atehwa/
homepage (technical): http://sange.fi/~atehwa/
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
In <·····················@vleeuwen.org> Kristof Bastiaensen <·······@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: ······@iki.fi, +35841 5323835, +3589 85619369
work contact: ················@helsinki.fi, +35850 3678003
kotisivu (henkkoht): http://www.iki.fi/atehwa/
homepage (technical): http://sange.fi/~atehwa/
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 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" <············@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
"Kris Cipa" <············@yahoo.co.nz> wrote in message
····························@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
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.
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.
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:
> 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
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
Stefan Ram wrote:
> ···@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.
<············@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. ]
From: Robert Uhl
Subject: Re: function notation and linguistics
Date:
Message-ID: <m3ll1g7t97.fsf@4dv.net>
Roberto Waltman <······@rwaltman.net> writes:
>
>>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? ;)
Physics used to be called 'natural philosophy...'
--
Robert Uhl <http://public.xdi.org/=ruhl>
Marriage, n: The state or condition of a community consisting of a master,
a mistress, and two slaves, making, in all, two. --Ambrose Bierce
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
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 ++++
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
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 ++++
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
Jon Harrop <······@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!
Zach Beane <····@xach.com> writes:
> David Steuber <·····@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!
On 2005-09-27 01:47:50 -0400, David Steuber <·····@david-steuber.com> said:
> Admittedly most of the CLOS features, including all the really nice
> ones like multiple dispatch are missing.
You can even get multimethods for Perl too. Perl is like lisp in that
it is sufficiently flexible that one can add expressive constructs not
originally envisaged by the language's inventor on top of the base
language:
<http://search.cpan.org/src/DCONWAY/Class-Multimethods-1.70/tutorial.html>
but I agree with you that uniformity of syntax allowing powerful macros
is still the killer feature of lisp.
regards
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 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.
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
>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
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
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
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
Jon Harrop wrote:
> 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. :-)
Actually my first version of your ray tracer used something similar (I
think I used some symbol other than | though). I changed it because I
thought v+, v-,etc was clearer.
Rob Thorpe wrote:
> Jon Harrop wrote:
>> Ironically, other versions of my ray tracer used ', +|, *|, -| and
>> lambda. :-)
>
> Actually my first version of your ray tracer used something similar (I
> think I used some symbol other than | though). I changed it because I
> thought v+, v-,etc was clearer.
So its your idea that I've stolen. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Rob Thorpe wrote:
> > Jon Harrop wrote:
> >> Ironically, other versions of my ray tracer used ', +|, *|, -| and
> >> lambda. :-)
> >
> > Actually my first version of your ray tracer used something similar (I
> > think I used some symbol other than | though). I changed it because I
> > thought v+, v-,etc was clearer.
>
> So its your idea that I've stolen. :-)
Of-course it is, and the fact that you thought of it before me in the
OCaml version proves it.
Since the other CL versions used v+ etc before mine I started that
trend too.
Rob Thorpe wrote:
> Since the other CL versions used v+ etc before mine I started that
> trend too.
Oh, you mean Thorpe operators? ;-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
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
Alan Crowe wrote:
> 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|.
>
> 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.
I don't claim that it's original. Although I thought of it
independently (or recalled it from the collective unconscious) it has
appeared in print at least a decade ago in Christian Queinnec "Lisp In
Small Pieces" (1996) page 5, footnote 3, which is a translation of "Les
Languages Lisp" (1994).
He shows an example of composition, saying that the |->| ('to') order
is difficult to understand and less straightforward than the |<-|
('from') order, but then goes on to say "In contrast, x->y is much
easier to read than y<-x."
I don't know what he means by that. Maybe "from" is hard to pronounce
in French.
-- Programmer in Chief
Programmer in Chief wrote:
> He shows an example of composition, saying that the |->| ('to') order
> is difficult to understand and less straightforward than the |<-|
> ('from') order, but then goes on to say "In contrast, x->y is much
> easier to read than y<-x."
>
> I don't know what he means by that.
Probably because you read from left to right.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
"Programmer in Chief" <·······@free-comp-shop.com> writes:
> He shows an example of composition, saying that the |->| ('to') order
> is difficult to understand and less straightforward than the |<-|
> ('from') order, but then goes on to say "In contrast, x->y is much
> easier to read than y<-x."
>
> I don't know what he means by that. Maybe "from" is hard to pronounce
> in French.
Indeed, we can say: de x a y (->)
but: x de y (<-) is awkward, ambiguous and
not easily understandable;
To express <- we'd need a more verbose expression, like:
obtenir x � partir de y
arriver � x venant de y
etc.
Sentences like: "Nashville's unemployment rate was 4.2 percent in
August, down a tick from 4.3 percent in July and a year ago." are
difficult to understand for us, and need a full conscious syntactic
and semantic analysis.
Perhaps that's why I like 680x0 and dislike ix86 assemblers.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
["Followup-To:" header set to comp.lang.lisp.]
On 2005-09-24, Kris Cipa <············@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 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
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
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
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?"
Following up to comp.lang.lisp only.
"Kris Cipa" <············@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 Sat, 24 Sep 2005 15:33:50 +0200, Paolo 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.
A.L. <········@kapturek62.com> writes:
> On Sat, 24 Sep 2005 15:33:50 +0200, Paolo 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/
From: Surendra Singhi
Subject: Re: What's so great about lisp?
Date:
Message-ID: <64spej91.fsf@netscape.net>
Matthias <··@spam.please> writes:
> A.L. <········@kapturek62.com> writes:
>
>> On Sat, 24 Sep 2005 15:33:50 +0200, Paolo 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
A.L. <········@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
Paolo Amoroso wrote:
> A.L. <········@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
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."
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)
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?
"Kris Cipa" <············@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.
In article <························@f14g2000cwb.googlegroups.com>,
Kris Cipa <············@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
>
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)
"Kris Cipa" <············@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
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 <·····@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! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Stefan Ram wrote:
> 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
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
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
In comp.lang.lisp Ray Dillinger <····@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.
On Sat, 24 Sep 2005 00:20:28 GMT, Ray Dillinger <····@sonic.net>
wrote:
>drewc wrote:
>> Stefan Ram wrote:
>>
>>> 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.
I think the issue is purely one of economics.
1 - the compulsory licensing fees for duplication favor an artist
putting more songs on each album. The average single artist CD has
12..15 songs - the equivalent of the much less common EP releases from
the 70's. Once artists discovered CDs held more, they quickly began
to fill them up.
2 - the average length of songs increased between 1965 and 1980 (CDs
hit the market in 1982), from just over 3 minutes to just under 4.
This meant you could put fewer songs on an album - which conflicted
with #1.
3- there was the realization that the average person was going deaf at
progressively faster rates. Not only were more people working in
noisy environments, but more people had cars, radios and televisions.
The world in general was becoming both louder and more continually
noisy. I have read that the cumulative effect of continual noise can
cause hearing loss somewhat regardless of volume if the ears have
little or no down time to recover. You don't have to record sounds
people can't hear.
The technology available set the limits of what could be done, but my
guess is that in creating the CD format, there was an analysis of what
could reasonably be gotten away with, balancing minimum acceptable
reproduction fidelity with maximum number of songs per album. The
result is what we have now.
The introduction of portable stereos has accelerated dramatic hearing
loss in the population. I think that's part of the reason for the
popularity of MP3s and other lossy encodings ... the population is
aging and/or otherwise going deaf and with each passing year fewer
people can hear what's missing.
>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.
I have read that, for music, it is necessary to reproduce the full
range from the 2nd overtone to the 5th harmonic of the original signal
to satisfy a good set of ears.
The 44.1kHz sample rate of CDs is sufficient by Nyquist to reproduce
the 5th harmonic of middle C, but only the 4th of vocal high C or the
2nd of high C on the piano. IICC, reproducing the 5th harmonic of
high C on the piano would require a minimum sampling rate of 268kHz or
a little over 6x the current sample rate. I don't know the frequency
ranges of some of the more exotic instruments so your guess of 20x
might be right on.
If there really is anything to this 5th harmonic stuff, then CDs fall
woefully short of faithfully reproducing high tones. I knew they did
not match vinyl from experience, but doing the math really drives it
home. The affected range includes even soprano vocals which is
personally disappointing because I have a certain liking for gaelic
banshees. CDs also clip the low end so it's doubtful that the 2nd
overtones are being reproduced faithfully either.
>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've had good results with high limit VBR encoding. I can usually get
a reasonably sized file that, to my ears, is indistinguishable from
the CD. There are only a few tracks in my CD collection that won't
surrender to 320kbps. YMMV ... we won't discuss my hearing
deficiencies or questionable taste in music 8-)
But I have never successfully reproduced a vinyl track with any
settings on any MP3 encoder. No matter what I do I can always hear
the difference.
George
--
for email reply remove "/" from address
George Neuner wrote:
> On Sat, 24 Sep 2005 00:20:28 GMT, Ray Dillinger <····@sonic.net>
>>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.
>
>
> I have read that, for music, it is necessary to reproduce the full
> range from the 2nd overtone to the 5th harmonic of the original signal
> to satisfy a good set of ears.
I think I agree. In fact, I'd have said the sixth harmonic.
>>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've had good results with high limit VBR encoding. I can usually get
> a reasonably sized file that, to my ears, is indistinguishable from
> the CD. There are only a few tracks in my CD collection that won't
> surrender to 320kbps. YMMV ... we won't discuss my hearing
> deficiencies or questionable taste in music 8-)
Some of the stuff I really like has lots of layering, lots
of soprano solo vocals, and quasi-acoustic effects like
being careful where the mikes are placed so that the
"sound image" recreates the acoustic shape of the hall,
or so that overtones from the piano strings are heard
(barely) when the piano is in the direct path of the sax
solo. CD's mangle it. An analog reel-to-reel rig does
okay with my high-end speakers, but I've played my faves
enough times that now I can hear the tapes decaying....
and I can't replace them anymore.
> But I have never successfully reproduced a vinyl track with any
> settings on any MP3 encoder. No matter what I do I can always hear
> the difference.
It's probably your sound card. I don't think most hardware
sample rate limits are now high enough to produce audio
substantially better than CD's.
In a pathetic attempt to drag this back on topic, it would be
interesting to try to use software to synthesize sound files
with full-bodied instrumentation (second overtone to fifth
harmonic seems like a good target) and quasi-acoustic
effects based on physical modeling of the real-time spatial
relationships within the (virtual) concert hall. But what
the hell codec would you use for raw sound at a 200 megabyte
per minute bitrate, and is there a sound card made that's
capable of properly playing it? And when you make your
10-megabyte-per-minute compressed audio MP3-or-similar tracks,
is there anything that can play them?
Bear
Ray Dillinger <····@sonic.net> writes:
> George Neuner wrote:
> > On Sat, 24 Sep 2005 00:20:28 GMT, Ray Dillinger <····@sonic.net>
>
> >>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.
> > I have read that, for music, it is necessary to reproduce the full
> > range from the 2nd overtone to the 5th harmonic of the original signal
> > to satisfy a good set of ears.
>
> I think I agree. In fact, I'd have said the sixth harmonic.
>
> >>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've had good results with high limit VBR encoding. I can usually
> > get
> > a reasonably sized file that, to my ears, is indistinguishable from
> > the CD. There are only a few tracks in my CD collection that won't
> > surrender to 320kbps. YMMV ... we won't discuss my hearing
> > deficiencies or questionable taste in music 8-)
>
> Some of the stuff I really like has lots of layering, lots
> of soprano solo vocals, and quasi-acoustic effects like
> being careful where the mikes are placed so that the
> "sound image" recreates the acoustic shape of the hall,
> or so that overtones from the piano strings are heard
> (barely) when the piano is in the direct path of the sax
> solo. CD's mangle it. An analog reel-to-reel rig does
> okay with my high-end speakers, but I've played my faves
> enough times that now I can hear the tapes decaying....
> and I can't replace them anymore.
>
> > But I have never successfully reproduced a vinyl track with any
> > settings on any MP3 encoder. No matter what I do I can always hear
> > the difference.
>
> It's probably your sound card. I don't think most hardware
> sample rate limits are now high enough to produce audio
> substantially better than CD's.
>
> In a pathetic attempt to drag this back on topic, it would be
> interesting to try to use software to synthesize sound files
> with full-bodied instrumentation (second overtone to fifth
> harmonic seems like a good target) and quasi-acoustic
> effects based on physical modeling of the real-time spatial
> relationships within the (virtual) concert hall. But what
> the hell codec would you use for raw sound at a 200 megabyte
> per minute bitrate, and is there a sound card made that's
> capable of properly playing it? And when you make your
> 10-megabyte-per-minute compressed audio MP3-or-similar tracks,
> is there anything that can play them?
>
Your point about the soundcard is very valid. Top end soundcards
designed for recording etc, have a much higher sample rate and I
believe that you can also get ones that can sample at 32 bit instead
of 16 bit (which can be important if you plan to do post-production
processing). The software used for post-production processing is also
important as some use 16 bit sample sizes "internally" within the
software and rounding error can quickly impact on the quality.
Its also interesting to note that DAT recorders use a frequency of 48k
rather than the 44.1k of CDs. The other point to keep in mind when
comparing vynal and cd is that nearly all decent quality turntables
actually have some filtering built in to compensate for the effects of
the mechanics associated with a needle and physical mechanics
associated with the playback of records - not sure exactly what impact
that may have when making a comparison between a record and cd.
I think one of the reasons mp3 is so popular is that these days, many
people are just using mid-level systems which wouldn't be able to
faithfully reproduce the frequencies even if they were there - these
days, it seems surround sound, sub-woofers and 5:1 doulby is far more
important to most people than true hi-fi reproduction. Last week there
was an intersting article (on slashdot I think) which talked about how
the recording industry in the US wants legislation passed to
artificially limit the fidelity of digital FM receivers when they are
rolled out - it seems they are concerned that if the quality of the
digital fm signal is too good, it will impact on record sales.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
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
Following up to comp.lang.lisp only.
"Kris Cipa" <············@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" <············@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!"
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/
On 23 Sep 2005 03:40:26 -0700, "Kris Cipa"
<············@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
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. :>
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
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
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
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 <············@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
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
From: Troels Henriksen
Subject: Re: What's so great about lisp?
Date:
Message-ID: <87psquz39c.fsf@sigkill.dk>
"Kris Cipa" <············@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
On 2005-09-27, Troels Henriksen <·····@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? ;-)
Troels Henriksen napisał(a):
> "Kris Cipa" <············@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...
Temperature range in Poland is from -25 to +30 celcius. There is no
polar bears, except ZOOs.
--
Best regards,
Rafal Strzalinski (nabla)
On Sun, 25 Sep 2005 16:53:01 GMT, Kenny Tilton <·······@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--
Charles Hoffman <··············@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!
Kris Cipa schrieb:
> What's so great about lisp?
...
> I'd like to know, what's the secret?
Well. Thank you.
This theread is one of those highlights inside of c.l.l. (449 postings)
I thought I read it in 10 mins, but it tooks still more and brings me
around to many corners on the Lisp Planet. Great. Another sleepless
night has turned to light for me.
But why is lisp so great?
...because I can think about the 30 years old fibonacci routine and do
some optimation. Thats it.
stefan
lin8080 <·······@freenet.de> writes:
> But why is lisp so great?
> ...because I can think about the 30 years old fibonacci routine and do
> some optimation. Thats it.
Fibonacci was my first Fortran exercise.
In all the years since assembler has been virtually abandoned for
higher level programming languages, which languages will give you the
10,000th Fibonacci number without making you jump through any hoops?
Which popular languages still say that 1 / 3 == 0?
Greatness is in the details and the synergy.
--
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!
David Steuber wrote:
> lin8080 <·······@freenet.de> writes:
>> But why is lisp so great?
>> ...because I can think about the 30 years old fibonacci routine and do
>> some optimation. Thats it.
>
> Fibonacci was my first Fortran exercise.
>
> In all the years since assembler has been virtually abandoned for
> higher level programming languages, which languages will give you the
> 10,000th Fibonacci number without making you jump through any hoops?
Not that many people want to compute the 10,000th Fibonacci number, but a
lazy, memoizing language would save you a hoop.
> Which popular languages still say that 1 / 3 == 0?
Which popular languages still say that 1.3 - 1.0 = 0.3:
* (= (- 1.3 1.0) 0.3)
NIL
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
> Which popular languages still say that 1.3 - 1.0 = 0.3:
>
> * (= (- 1.3 1.0) 0.3)
Wouldn't that be all the languages that correctly implement the IEEE
floating point standards?
This works
(= (- 4/3 1) 1/3)
T
Brad
"bradb" <··············@gmail.com> writes:
> > Which popular languages still say that 1.3 - 1.0 = 0.3:
> >
> > * (= (- 1.3 1.0) 0.3)
>
> Wouldn't that be all the languages that correctly implement the IEEE
> floating point standards?
>
> This works
> (= (- 4/3 1) 1/3)
> T
$ openmcl
Welcome to OpenMCL Version 1.0-rc1-050924 (DarwinPPC32)!
? (= (- 1.3 1.0) 0.3)
NIL
? (- 1.3 1.0)
0.29999995
? 0.3
0.3
? (= (- 13/10 1) 3/10)
T
See my headers for all the Fibonacci numbers.
--
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!
bradb wrote:
>> Which popular languages still say that 1.3 - 1.0 = 0.3:
>>
>> * (= (- 1.3 1.0) 0.3)
>
> Wouldn't that be all the languages that correctly implement the IEEE
> floating point standards?
If you assume that 1.3 means an IEEE floating point number closest to 1.3,
then yes. In mathematics, that is not what 1.3 means, of course.
> This works
> (= (- 4/3 1) 1/3)
> T
Yes. Lisp forces you to "jump through the hoop" of converting the numbers
into some representation that happens to be exact in Lisp. For this
example, Mathematica does not require the same hoop jumping because it
tracks numerical errors in floating point arithmetic:
In[1]:= 1.3 - 1.0 == 0.3
Out[1]= True
In the context of numerics, Lisp is better than some languages and worse
than others.
For example, how do you compute 120!. In Lisp you can simply do:
* (defun fact (n) (if (< n 2) n (* n (fact (1- n)))))
FACT
* (fact 120)
6689502913449127057588118054090372586752746333138029810295671352301633
5572449629893668741652719849813081576378932140905525344085894081218598
98481114389650005964960521256960000000000000000000000000000
SML requires slightly more code. Specifically, a type annotation to give an
arbitrary-precision result:
- fun fact n : IntInf.int = if n<2 then n else n*fact(n-1);;
OCaml requires even more code because there is no ad-hoc polymorphism for
arbitrary-precision integers:
# open Num;;
# let rec fact n = if n<2 then num_of_int n else num_of_int n */ fact(n-1);;
val fact : int -> Num.num = <fun>
# string_of_num (fact 120);;
- : string =
"6689502913449127057588118054090372586752746333138029810295671352301633
55724496298936687416527198498130815763789321409055253440858940812185989
8481114389650005964960521256960000000000000000000000000000"
So Lisp "beats" SML and OCaml on that example, but not Mathematica:
In[1]:= 120!
Out[1]= 668950291344912705758811805409037258675274633313802981029567135
23016335572449629893668741652719849813081576378932140905525344085894081
21859898481114389650005964960521256960000000000000000000000000000
Now compute the first 100 digits of pi. In Mathematica you just do:
In[1]:= N[Pi, 100]
Out[1]= 3.1415926535897932384626433832795028841971693993751058209749445
92307816406286208998628034825342117068
You'll have trouble beating that in Lisp.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
On Fri, 14 Oct 2005 06:08:00 +0100, Jon Harrop wrote:
> Yes. Lisp forces you to "jump through the hoop" of converting the
> numbers into some representation that happens to be exact in Lisp. For
> this example, Mathematica does not require the same hoop jumping because
> it tracks numerical errors in floating point arithmetic:
Isn't Mathematica written in Lisp?
BR wrote:
> Isn't Mathematica written in Lisp?
No. Lisp would be way too slow, apparently:
http://groups.google.com/group/comp.lang.lisp/msg/f3b93140c2f2e922
On Fri, 14 Oct 2005 01:48:27 -0400, Cameron MacKinnon wrote:
> BR wrote:
>
>> Isn't Mathematica written in Lisp?
>
> No. Lisp would be way too slow, apparently:
>
> http://groups.google.com/group/comp.lang.lisp/msg/f3b93140c2f2e922
Interesting. Especially for those who like computing history.
Although I am very new to Lisp, it seems that it would be possible to
create a set of macros & reader macros that would bring the Lisp syntax
into a more compact form that still gave mathematically correct
answers. Of course, if Mathematica is the right tool for the job you'd
be a little silly to choose Lisp :)
bradb wrote:
> Although I am very new to Lisp, it seems that it would be possible to
> create a set of macros & reader macros that would bring the Lisp syntax
> into a more compact form that still gave mathematically correct
> answers. Of course, if Mathematica is the right tool for the job you'd
> be a little silly to choose Lisp :)
This is mixing levels of abstraction.
"Mathematically correct" requires mathematical knowledge of the
specific problem at hand. The "correct" behavior of 1.3 - 1.0 == 0.3
depends on who is doing the definition.
Common Lisp *defines* such numbers, when presented to #'READ as
floating-point numbers, of the default float read format, of the
representation provided by the implementation, and provides various
standard functions to tease out the details of what that implementation
is. Depending on the representation base and float-epsilon value, and
the rounding used by the implementation, it might or might not be
possible for the implementation to maintain the equality.
If you want an "exact" representation where, for example, 1.3 is
defined as precisely 1 + 3 * 10^-1 + NOTHING ELSE, or an interval, or
whatever, and addition and subtraction (and multiplication, and
division, and ...???) of these objects is supported, then you should
choose an appropriate representation. Lisp floating-point numbers might
not suffice.
Mathematica makes other *choices* of representation, with different
tradeoffs, and rather little solid written specification.
Generally speaking, computer numerics are designed for programs which
do perhaps millions or billions of calculations without showing the
intermediate results to a human. Choosing a representation which gives
soothing results for a human typing in base 10 at the REPL is a
different goal entirely.
This topic has been discussed to near-death many times in many places.
···············@hotmail.com" <············@gmail.com> writes:
> bradb wrote:
>> Although I am very new to Lisp, it seems that it would be possible to
>> create a set of macros & reader macros that would bring the Lisp syntax
>> into a more compact form that still gave mathematically correct
>> answers. Of course, if Mathematica is the right tool for the job you'd
>> be a little silly to choose Lisp :)
>
> This is mixing levels of abstraction.
>
> "Mathematically correct" requires mathematical knowledge of the
> specific problem at hand. The "correct" behavior of 1.3 - 1.0 == 0.3
> depends on who is doing the definition.
Mathematically: 1.1428571428(571428) - 0.1428571428(571428) = 1.0
or in base 7: 1.1 - 0.1 = 1.0
You cannot write these base 7 numbers with a finite number of digits
in base 10, without introducing another notation.
Well, good news! Lisp has an equivalent notation: it's called rationals!
8/7 - 1/7 = 1/1
So don't be silly, if you mean mathematical: 1.3 - 1.0 = 0.3,
write it in lisp as: (= (- 13/10 1) 3/10)
--
"You question the worthiness of my code? I should kill you where you
stand!"
Pascal Bourguignon wrote:
> Mathematically: 1.1428571428(571428) - 0.1428571428(571428) = 1.0
> or in base 7: 1.1 - 0.1 = 1.0
> You cannot write these base 7 numbers with a finite number of digits
> in base 10, without introducing another notation.
> Well, good news! Lisp has an equivalent notation: it's called rationals!
> 8/7 - 1/7 = 1/1
Rationals are not an equivalent "notation" to arbitrary-precision
floating-point interval arithmetic in general. Hence Mathematica provides
both.
> So don't be silly, if you mean mathematical: 1.3 - 1.0 = 0.3,
> write it in lisp as: (= (- 13/10 1) 3/10)
Rationals != Reals
For example, look at some irrational numbers:
* (= (sqrt 3) (/ 3 (sqrt 3)))
NIL
In[1]:= N[Sqrt[3]] == N[3/Sqrt[3]]
Out[1]= True
Note: my use of the "N" function forces Mathematica to treat this
numerically and not symbolically.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
>
> In[1]:= N[Sqrt[3]] == N[3/Sqrt[3]]
> Out[1]= True
>
> Note: my use of the "N" function forces Mathematica to treat this
> numerically and not symbolically.
Not necessarily. Doesn't it evaluate the arguments *before* applying
the N operation? In which case, Sqrt[3] and 3/Sqrt[3] both evaluate to
Sqrt[3], which N evaluates to an identical value each time.
I played around with some definitions to test this, and found,
f[Sqrt[3]] := foosqrt3;
f[N[Sqrt[3]] := foosqrtN3;
N[f[Sqrt[3]]] --> foosqrt3
N[f[3/Sqrt[3]] --> foosqrt3
i.e. it is likely doing a symbolic simplification before it does a
numeric approximation. In fact, I could not figure out the necessary
trick to get f[3/Sqrt[3]] to be at all distinguishable from f[Sqrt[3]].
NOT THAT I CARE, so don't feel a need to prove your Mathematica
cleverness.
··············@hotmail.com wrote:
> ...
> i.e. it is likely doing a symbolic simplification before it does a
> numeric approximation.
Oops, yes. I should have written N[3]/N[Sqrt[3]]. The answer is still the
same:
In[1]:= N[Sqrt[3]] == N[3] / N[Sqrt[3]]
Out[1]= True
The floating point representations are slightly different:
In[2]:= FullForm[N[Sqrt[3]]]
Out[2]//FullForm= 1.7320508075688772`
In[3]:= FullForm[N[3] / N[Sqrt[3]]]
Out[3]//FullForm= 1.7320508075688776`
> In fact, I could not figure out the necessary
> trick to get f[3/Sqrt[3]] to be at all distinguishable from f[Sqrt[3]].
You could use structural comparison instead of equality:
In[13]:= N[Sqrt[3]] === N[3] / N[Sqrt[3]]
Out[13]= False
> NOT THAT I CARE, so don't feel a need to prove your Mathematica
> cleverness.
Sure. My point is just that Lisp has one of many "numerical towers".
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Rationals are not an equivalent "notation" to arbitrary-precision
> floating-point interval arithmetic in general. Hence Mathematica provides
> both.
Well, the set of the rational (types) in general, and in lisp in
particular, is bigger than the set of the floating points (types).
But otherwise, rationals and floating-points types are strictly equivalent.
> Rationals != Reals
Floating-point != Reals.
You forgot this when bringing the subject here.
> In[1]:= N[Sqrt[3]] == N[3/Sqrt[3]]
> Out[1]= True
>
> Note: my use of the "N" function forces Mathematica to treat this
> numerically and not symbolically.
So what? Lisp = List & Inteligent Symbolic Processing
Mathematica = Mathematics.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
Pascal Bourguignon wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> Rationals are not an equivalent "notation" to arbitrary-precision
>> floating-point interval arithmetic in general. Hence Mathematica provides
>> both.
>
> Well, the set of the rational (types) in general, and in lisp in
> particular, is bigger than the set of the floating points (types).
If you mean "values" instead of "types", then yes.
> But otherwise, rationals and floating-points types are strictly
> equivalent.
No. FP adds NaN, infinity, -infinity and -0.
>> Rationals != Reals
> Floating-point != Reals.
Yes.
> You forgot this when bringing the subject here.
No. I specifically said "arbitrary-precision floating-point interval
arithmetic" in the post that you just quoted. I was not talking about
ordinary floating point arithmetic.
>> In[1]:= N[Sqrt[3]] == N[3/Sqrt[3]]
>> Out[1]= True
>
> So what?
Irrational numbers are an obvious counter example.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Joe Marshall wrote:
>> Rationals != Reals
>> Floating-point != Reals.
>
> Computable numbers != Reals
Intervals are not numbers.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
On 9263 day of my life Jon Harrop wrote:
>> So don't be silly, if you mean mathematical: 1.3 - 1.0 = 0.3,
>> write it in lisp as: (= (- 13/10 1) 3/10)
>
> Rationals != Reals
IEEE floating points numbers are not 'reals' either :)
--
Ivan Boldyrev
Violets are red, Roses are blue. //
I'm schizophrenic, And so am I.
Ivan Boldyrev wrote:
> On 9263 day of my life Jon Harrop wrote:
>>> So don't be silly, if you mean mathematical: 1.3 - 1.0 = 0.3,
>>> write it in lisp as: (= (- 13/10 1) 3/10)
>>
>> Rationals != Reals
>
> IEEE floating points numbers are not 'reals' either :)
Yes, absolutely.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
From: Duane Rettig
Subject: Re: What's so great about lisp?
Date:
Message-ID: <4y84w9e4l.fsf@franz.com>
"bradb" <··············@gmail.com> writes:
> Although I am very new to Lisp, it seems that it would be possible to
> create a set of macros & reader macros that would bring the Lisp syntax
> into a more compact form that still gave mathematically correct
> answers.
I didn't want to get into this, and David Steuber alluded to the
answer in a previous article, though he didn't show _why_ Lisp is
doing the correct thing. But your continued misunderstanding
of what constitutes "Correctness" leads me to try to set you
straight.
If we take Jon Harrop's original example: (= (- 1.3 1.0) 0.3)
and look at some actual bits, assuming IEEE-754 on Allegro CL:
CL-USER(1): 1.3
1.3
CL-USER(2): :i *
A NEW single-float = 1.3 [#x3fa66666] @ #x10655482
CL-USER(3): 1.0
1.0
CL-USER(4): :i *
A NEW single-float = 1.0 [#x3f800000] @ #x1065763a
CL-USER(5): (- *** *)
0.29999995
CL-USER(6): :i *
A NEW single-float = 0.29999995 [#x3e999998] @ #x10657bba
CL-USER(7):
Note at prompt #2 the inspection of 1.3 shows what looks to be
a repeating fraction. What is the next hex digit out from the
last one? One would think that it should be 6. But no, it is
0, because we are dealing with a single-float, i.e. what IEEE-754
provides as a 32-bit float. There are provisions for guard bits,
etc, during calculations, but there are really no more bits in
the single-float representation beyond the 32nd bit - the point
is that it is impossible to represent all decimal values
correctly in a binary machine.
Now, you may look at the bits in the above answer and say "well,
obviously that last 8 should have been a 9". But should it?
Let's examine .3 :
CL-USER(7): .3
0.3
CL-USER(8): :i *
A NEW single-float = 0.3 [#x3e99999a] @ #x1065c8ba
CL-USER(9):
This bit pattern is yet one value higher than one would expect,
because it has been rounded to the next bit. So even the bit
pattern represented by #x3e999999 would have been a wrong answer.
This same pattern should be seen in all languages that conform
to IEEE-754. There may be some subtle differences, based on
rounding modes, and of course if you use 64-bit floats rather than
32-bits, you get higher precision. But the fundamental issue
remains that not all mathematical real values can be represented
correctly in fast digital floating point hardware, and even among
the rationals, representing a number in a fundamentally different
radix than is represented in the machine leads to rounding errors
in general.
> Of course, if Mathematica is the right tool for the job you'd
> be a little silly to choose Lisp :)
If Mathematica uses BCD to do its base-10 calculations, and base-10
correctness is what you want to optimize for, then by all means,
that is the correct language to use, and it would be silly to be
choosing _any_ other regular programming language that only uses
a binary floating point representation like IEEE-754.
As for mathematical correctness, Mathematica may be able to
represent 1/3 in decimal notation _correctly_, using algorithmic
or rational numerology. However, such representation is _not_
possible in IEEE-754 arithmetic, because it is a repeating fraction
in decimal notation, and IEEE-754 (and the hardware that implements
it) does not have the capability to represent such a value exactly.
It never was a Mathematica-vs-Lisp thing; it is an exact-decimal-vs-
Floating-point thing. And note that Common Lisp does represent
all rationals correctly, it just doesn't use floating point hardware
to do it.
--
Duane Rettig ·····@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
I didn't mean to give the impression that I thought
"(eq (- 1.3 1.0) 0.3) -> nil" was incorrect. As you say, according to
IEEE (which is what we are implicitly using) 1.3 - 1 is not equal to
0.3, because some numbers simply cannot be represented using IEEE-754.
Unfortuantly, I didn't make my position clear :) What was the question
again?? :)
From: Duane Rettig
Subject: Re: What's so great about lisp?
Date:
Message-ID: <4u0fjantc.fsf@franz.com>
"bradb" <··············@gmail.com> writes:
> I didn't mean to give the impression that I thought
> "(eq (- 1.3 1.0) 0.3) -> nil" was incorrect.
Minor nit, but one for which the lisp won't be very forgiving -
don't use EQ here, otherwise you're likely to _always_ get nil,
for whatever combination of single-floats you replace into the
expression (there is an esoteric exception, but it's not relevant
here).
As you say, according to
> IEEE (which is what we are implicitly using) 1.3 - 1 is not equal to
> 0.3, because some numbers simply cannot be represented using IEEE-754.
Right.
> Unfortuantly, I didn't make my position clear :) What was the question
> again?? :)
You're forgiven :-)
But the question really is not one of correctness, but of
application. And Lisp is almost always as suited for the job
as any othe language. For example, when you are using
floating point to perform actual measurements, you may
not _want_ all of that accuracy, because it becomes noise
washed out and made superfluous by the (limited) accuracy
of your measrements. So if I instead specified 1.300 and
1.000 and asked for the answer to the "correct" (in
scientific/measurement terms) accuracy, guess what - Common
Lisp does this just fine:
CL-USER(2): (format t "~,4f" (- 1.300 1.000))
0.3000
NIL
CL-USER(3):
--
Duane Rettig ·····@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
Duane Rettig wrote:
> "bradb" <··············@gmail.com> writes:
>
>>Although I am very new to Lisp, it seems that it would be possible to
>>create a set of macros & reader macros that would bring the Lisp syntax
>>into a more compact form that still gave mathematically correct
>>answers.
>
> I didn't want to get into this,
Me neither, believe it or not.
> If we take Jon Harrop's original example: (= (- 1.3 1.0) 0.3)
> and look at some actual bits, assuming IEEE-754 on Allegro CL:
That's a key assumption, since the CL spec doesn't mandate IEEE-754
(Simple proof for the sceptics: What's the FLOAT-RADIX function for?)
> This same pattern should be seen in all languages that conform
> to IEEE-754. There may be some subtle differences, based on
> rounding modes, and of course if you use 64-bit floats rather than
> 32-bits, you get higher precision.
And of course, if your hardware FPU uses 80 bit floats internally, you
may get slightly different results. Perhaps a CL program would produce
different results on a vendor's Intel port than on that same vendor's
SPARC port.
So in answer to Brad's post, there's not much in ANSI CL preventing an
implementation from using radix-10 floats (forgoing the speed advantages
of current commodity radix-2 hardware) and producing more 'correct'
finite precision answers.
That's my last post on this issue in this thread.
>>>>> "bradb" == bradb <··············@gmail.com> writes:
bradb> Although I am very new to Lisp, it seems that it would be possible to
bradb> create a set of macros & reader macros that would bring the Lisp syntax
bradb> into a more compact form that still gave mathematically correct
There's the infix package available from the CMU AI archives.
bradb> answers. Of course, if Mathematica is the right tool for the job you'd
bradb> be a little silly to choose Lisp :)
Well, if Mathematica were the right tool, then perhaps Macsyma or maxima
would also be the right tool, so it would make sense to choose Lisp.
Ray
bradb wrote:
> Although I am very new to Lisp, it seems that it would be possible to
> create a set of macros & reader macros that would bring the Lisp syntax
> into a more compact form that still gave mathematically correct
> answers.
Yes. Or you could write a preprocessor in order to use C++, or you could
call functions instead of changing the syntax, or you could use macros in
other languages such as Scheme or OCaml.
> Of course, if Mathematica is the right tool for the job you'd be a little
> silly to choose Lisp :)
Yes.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
On Fri, 14 Oct 2005 06:08:00 +0100, Jon Harrop wrote:
> Now compute the first 100 digits of pi. In Mathematica you just do:
>
> In[1]:= N[Pi, 100]
> Out[1]= 3.1415926535897932384626433832795028841971693993751058209749445
> 92307816406286208998628034825342117068
>
> You'll have trouble beating that in Lisp.
Base 10 is approximately 3.3 bits per digit.
$ clisp
[1]> (setf (ext:long-float-digits) 330)
330
[2]> pi
3.1415926535897932384626433832795028841971693993751058209749445
92307816406286208998628034825342117067982148L0
This is CLISP-specific functionality with a standard foundation: ANSI
Common Lisp specifies four kinds of floats. CLISP just makes the precision
of its long floats user-selectable.
Regards,
Adam
>Yes. Lisp forces you to "jump through the hoop" of converting the numbers
>into some representation that happens to be exact in Lisp. For this
>example, Mathematica does not require the same hoop jumping because it
>tracks numerical errors in floating point arithmetic:
My ideal user friendly Lisp in this regard would be Lisp that
automatically convert floating point literal to rational.
1.3 literal can be converted to (/ 13 10).
In case one really wants IEEE float, one can always use declaration.
There's probably no surprise wrt to the behavior of the program, most
people would expect rational like behavior than the IEEE bahavior
anyway.
> (defun fact (n) (if (< n 2) n (* n (fact (1- n)))))
>...
>So Lisp "beats" SML and OCaml on that example, but not Mathematica:
>
>In[1]:= 120!
What's the point of this example? To show that Mathematica has built-in
fact function and Lisp don't?
Does Mathematica have built-in condition system like Common Lisp?
Should we try to compare number of line of code and effort you have to
spend to implement that in Mathematica?
I am sure Mathematica will have trouble beating Common Lisp on that.
Line of code in Lisp for condition system will be 0. As is
Mathematica's Line of code for fact function.
Now would you choose the language that you have implement fact function
yourself or the language that you have to implement Condition System
yourself? :-)
Pisin Bootvong wrote:
>>Yes. Lisp forces you to "jump through the hoop" of converting the numbers
>>into some representation that happens to be exact in Lisp. For this
>>example, Mathematica does not require the same hoop jumping because it
>>tracks numerical errors in floating point arithmetic:
>
> My ideal user friendly Lisp in this regard would be Lisp that
> automatically convert floating point literal to rational.
The problem is that rationals have very different properties.
> 1.3 literal can be converted to (/ 13 10).
The representation used by Mathematica tracks numerical error, so it is not
equivalent to 13/10.
> In case one really wants IEEE float, one can always use declaration.
Also, it is not IEEE float.
> There's probably no surprise wrt to the behavior of the program, most
> people would expect rational like behavior than the IEEE bahavior
> anyway.
I think most people would expect mathematical behaviour, which isn't
possible on a computer.
>> (defun fact (n) (if (< n 2) n (* n (fact (1- n)))))
>>...
>>So Lisp "beats" SML and OCaml on that example, but not Mathematica:
>>
>>In[1]:= 120!
>
> What's the point of this example? To show that Mathematica has built-in
> fact function and Lisp don't?
In this case, yes. Mathematica implements a wide variety of functions (e.g.
Gamma) that Lisp does not. So I would not hold up Lisp's numerical tower as
an example of something that makes the language great. It simply puts Lisp
in the middle, between C++ and CASs for example.
> Does Mathematica have built-in condition system like Common Lisp?
It has pattern matching with optionally guarded patterns. I think that
serves the same purpose.
> Should we try to compare number of line of code and effort you have to
> spend to implement that in Mathematica?
Can you give an example of a simple problem and implementation using Lisp's
condition system?
Also, there is also a problem here - Mathematica code is usually typeset, so
it doesn't make sense to compare by LOC. Still, it'll be interesting to
have a look.
> I am sure Mathematica will have trouble beating Common Lisp on that.
I doubt it. :-)
> Line of code in Lisp for condition system will be 0. As is
> Mathematica's Line of code for fact function.
Yep.
> Now would you choose the language that you have implement fact function
> yourself or the language that you have to implement Condition System
> yourself? :-)
That depends upon the application. Right now, Lisp is looking most promising
for writing fast interpreters. Obviously, Mathematica isn't going to
compete there. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
> > 1.3 literal can be converted to (/ 13 10).
>
> The representation used by Mathematica tracks numerical error, so it is not
> equivalent to 13/10.
Do you mean representation used by Mathematica is floating point with
error interval (+/- x)? 13/10 it's an exact number so there is no need
to track numerical error.
>
> > In case one really wants IEEE float, one can always use declaration.
>
> Also, it is not IEEE float.
>
I was not saying Mathematica number was IEEE. I was saying that if one
REALLY want to use IEEE float (some specification might required number
to be done with IEEE behavior), then there is a way to fallback to it.
Pisin Bootvong wrote:
>> > 1.3 literal can be converted to (/ 13 10).
>>
>> The representation used by Mathematica tracks numerical error, so it is
>> not equivalent to 13/10.
>
> Do you mean representation used by Mathematica is floating point with
> error interval (+/- x)?
Exactly.
> 13/10 it's an exact number so there is no need to track numerical error.
In this case, yes. In general, the number may be irrational, so a rational
representation will have to be approximate.
>> > In case one really wants IEEE float, one can always use declaration.
>>
>> Also, it is not IEEE float.
>
> I was not saying Mathematica number was IEEE. I was saying that if one
> REALLY want to use IEEE float (some specification might required number
> to be done with IEEE behavior), then there is a way to fallback to it.
Does that actually work in practice? I was under the impression that most
CPUs aren't fussy enough about FP behaviour.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Does that actually work in practice? I was under the impression that most
> CPUs aren't fussy enough about FP behaviour.
CPUs are usually very good about floating-point behavior, but the OS
and the programming language both have to co-operate to take advantage
of it.
Joe Marshall wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> Does that actually work in practice? I was under the impression that most
>> CPUs aren't fussy enough about FP behaviour.
>
> CPUs are usually very good about floating-point behavior, but the OS
> and the programming language both have to co-operate to take advantage
> of it.
Which Lisp implementations are good at adhering to IEEE FP on x86 and AMD64?
This ultimate pedantry is vital when dealing with some geometric algorithms
that I use and I have yet to find a language that is obedient in this
respect.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
>>>>> "Jon" == Jon Harrop <······@jdh30.plus.com> writes:
Jon> Joe Marshall wrote:
>> Jon Harrop <······@jdh30.plus.com> writes:
>>> Does that actually work in practice? I was under the impression that most
>>> CPUs aren't fussy enough about FP behaviour.
>>
>> CPUs are usually very good about floating-point behavior, but the OS
>> and the programming language both have to co-operate to take advantage
>> of it.
Jon> Which Lisp implementations are good at adhering to IEEE FP on x86 and AMD64?
I believe cmucl and sbcl are good at adhering to IEEE FP on x86.
There are oddities but many of them are do to the fact that the x86
really only has 80-bit floats, so if you're using just single-float
numbers, you might not get what you expect because rounding happens in
an unexpected way.
This could be construed as a bug in cmucl/sbcl, but could equally be
construed as a bug in the x86 FPU. Most of these issues don't happen
with cmucl/sbcl on sparc or ppc or other chips with single and double
precision floats.
Ray
From: Duane Rettig
Subject: Re: What's so great about lisp?
Date:
Message-ID: <4wtkbu4eu.fsf@franz.com>
Raymond Toy <···········@ericsson.com> writes:
>>>>>> "Jon" == Jon Harrop <······@jdh30.plus.com> writes:
>
> Jon> Joe Marshall wrote:
> >> Jon Harrop <······@jdh30.plus.com> writes:
> >>> Does that actually work in practice? I was under the impression that most
> >>> CPUs aren't fussy enough about FP behaviour.
> >>
> >> CPUs are usually very good about floating-point behavior, but the OS
> >> and the programming language both have to co-operate to take advantage
> >> of it.
>
> Jon> Which Lisp implementations are good at adhering to IEEE FP on x86 and AMD64?
>
> I believe cmucl and sbcl are good at adhering to IEEE FP on x86.
> There are oddities but many of them are do to the fact that the x86
> really only has 80-bit floats, so if you're using just single-float
> numbers, you might not get what you expect because rounding happens in
> an unexpected way.
No, rounding only happens in an unexpected way on "x87" hardware
if you don't ensure that the precision is set. The precision can be
set by performing an fldcw instruction - this loads a 16-bit value
into the x87 fcw (float control word). The precision control is
bits 9 and 8 of this word, and its values are as follows:
bits 9 8 meaning
0 0 single precision
0 1 <reserved>
1 0 double precision
1 1 double-extended precision (default).
> This could be construed as a bug in cmucl/sbcl, but could equally be
> construed as a bug in the x86 FPU. Most of these issues don't happen
> with cmucl/sbcl on sparc or ppc or other chips with single and double
> precision floats.
No, if CMUCL/SBCL don't take advantage of this feature to set the precision
to 32 or 64-bits for the single-floats and double-floats, respectively,
then the only way they could be construed not to have a bug is to define
all of their CL float values as 80-bit values. Otherwise, there will
be calculations for which the result is incorrect. Since by my observation
both CMUCL and SBCL take on the 32/64 float dichotomy (at least for
single and double floats) it would definitely be a bug in these lisps.
--
Duane Rettig ·····@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
>>>>> "Duane" == Duane Rettig <·····@franz.com> writes:
Duane> Raymond Toy <···········@ericsson.com> writes:
>>>>>>> "Jon" == Jon Harrop <······@jdh30.plus.com> writes:
>>
Jon> Joe Marshall wrote:
>> >> Jon Harrop <······@jdh30.plus.com> writes:
>> >>> Does that actually work in practice? I was under the impression that most
>> >>> CPUs aren't fussy enough about FP behaviour.
>> >>
>> >> CPUs are usually very good about floating-point behavior, but the OS
>> >> and the programming language both have to co-operate to take advantage
>> >> of it.
>>
Jon> Which Lisp implementations are good at adhering to IEEE FP on x86 and AMD64?
>>
>> I believe cmucl and sbcl are good at adhering to IEEE FP on x86.
>> There are oddities but many of them are do to the fact that the x86
>> really only has 80-bit floats, so if you're using just single-float
>> numbers, you might not get what you expect because rounding happens in
>> an unexpected way.
Duane> No, rounding only happens in an unexpected way on "x87" hardware
Duane> if you don't ensure that the precision is set. The precision can be
Duane> set by performing an fldcw instruction - this loads a 16-bit value
Duane> into the x87 fcw (float control word). The precision control is
Duane> bits 9 and 8 of this word, and its values are as follows:
CMUCL allows setting the precision, but the compiler does not do that
automatically depending on the operand types. And setting it to
double-float precision causes some other things to produce unexpected
results, at least when running the ieeefp-test suite.
Also, I do believe there is a rounding issue with x86 hardware. I'm
fairly sure the 80-bit format does not have a sticky bit, so rounding
80-bit numbers does not behave quite "right". This also causes issues
when converting an 80-bit float to a 64-bit float. Without the sticky
bit, the 64-bit float can sometimes be rounded twice, producing an
incorrect result.
But my memory of this is fading, so I could be wrong. And this no
longer has anything to do with Lisp. :-)
Duane> No, if CMUCL/SBCL don't take advantage of this feature to set the precision
Duane> to 32 or 64-bits for the single-floats and double-floats, respectively,
Duane> then the only way they could be construed not to have a bug is to define
Duane> all of their CL float values as 80-bit values. Otherwise, there will
Duane> be calculations for which the result is incorrect. Since by my observation
Duane> both CMUCL and SBCL take on the 32/64 float dichotomy (at least for
Duane> single and double floats) it would definitely be a bug in these lisps.
Does ACL "always" twiddle the precision bits when multiplying single-
and double-floats?
I think sbcl can use SSE, so this issue probably doesn't occur there.
Ray
From: Duane Rettig
Subject: Re: What's so great about lisp?
Date:
Message-ID: <47jca9718.fsf@franz.com>
Raymond Toy <···········@ericsson.com> writes:
>>>>>> "Duane" == Duane Rettig <·····@franz.com> writes:
>
> Duane> Raymond Toy <···········@ericsson.com> writes:
> >>>>>>> "Jon" == Jon Harrop <······@jdh30.plus.com> writes:
> >>
> Jon> Joe Marshall wrote:
> >> >> Jon Harrop <······@jdh30.plus.com> writes:
> >> >>> Does that actually work in practice? I was under the impression that most
> >> >>> CPUs aren't fussy enough about FP behaviour.
> >> >>
> >> >> CPUs are usually very good about floating-point behavior, but the OS
> >> >> and the programming language both have to co-operate to take advantage
> >> >> of it.
> >>
> Jon> Which Lisp implementations are good at adhering to IEEE FP on x86 and AMD64?
> >>
> >> I believe cmucl and sbcl are good at adhering to IEEE FP on x86.
> >> There are oddities but many of them are do to the fact that the x86
> >> really only has 80-bit floats, so if you're using just single-float
> >> numbers, you might not get what you expect because rounding happens in
> >> an unexpected way.
>
> Duane> No, rounding only happens in an unexpected way on "x87" hardware
> Duane> if you don't ensure that the precision is set. The precision can be
> Duane> set by performing an fldcw instruction - this loads a 16-bit value
> Duane> into the x87 fcw (float control word). The precision control is
> Duane> bits 9 and 8 of this word, and its values are as follows:
>
> CMUCL allows setting the precision, but the compiler does not do that
> automatically depending on the operand types. And setting it to
> double-float precision causes some other things to produce unexpected
> results, at least when running the ieeefp-test suite.
If the precision-setting is global, then yes, I can see how that
would affect library routines which count on the 80-bit precision
to be set all the time.
> Also, I do believe there is a rounding issue with x86 hardware. I'm
> fairly sure the 80-bit format does not have a sticky bit, so rounding
> 80-bit numbers does not behave quite "right". This also causes issues
> when converting an 80-bit float to a 64-bit float. Without the sticky
> bit, the 64-bit float can sometimes be rounded twice, producing an
> incorrect result.
You may instead be seeing the effect of the lack of a save/restore
discipline when transitioning between Lisp and C. When we went to
a transitioning style (i.e. the precision is considered another register
to be restored to its original value when returning from C, and must be
"set" to 80-bit when calling out to C) this flakiness went away.
As for the sticky bit - the reason for this and other guard bits
is to more closely emulate probablistically the correct rounding
that would have been done if more bits had been available. If more
bits _are_ available, then rounding _is_ correct. Of course, being
more correct than the behavior of the desired precision is not
necessarily a Good Thing (Kahan says that he would rather see a
consistent answer all of the time than a better answer some of
the time). But because the majority of the inconsistency in float
results is due to the lack of the discipline of setting the precision
based on each operand, we have not seen any such differences since
we went to this discipline - and we have had quite a bit of experience
with cross-platform situations (we have, of course, had bugs we've
had to fix, so for those readers who are our customers and have seen
and reported those bugs, know that I make a distinction between a
fundamental correctness issue (which cannot be fixed) and a simple bug
(which can be fixed). Also, on those older architectures which did
not purport to conform to IEEE-754 stadard (e.g. Cray, IBM/360-370)
there _were_ issues of precision, where the floating point test
suites would not yield the exact same answers, though they tended
to be no "worse' answers than the IEEE-754-based systems).
> But my memory of this is fading, so I could be wrong. And this no
> longer has anything to do with Lisp. :-)
I completely disagree, here. It has everything to do with Lisp.
But perhaps it is an issue only interesting to Lisp implementors,
and not to Lisp users (who simply expect things to work correctly).
If that is what you are really trying to say, then I agree.
> Duane> No, if CMUCL/SBCL don't take advantage of this feature to set the precision
> Duane> to 32 or 64-bits for the single-floats and double-floats, respectively,
> Duane> then the only way they could be construed not to have a bug is to define
> Duane> all of their CL float values as 80-bit values. Otherwise, there will
> Duane> be calculations for which the result is incorrect. Since by my observation
> Duane> both CMUCL and SBCL take on the 32/64 float dichotomy (at least for
> Duane> single and double floats) it would definitely be a bug in these lisps.
>
> Does ACL "always" twiddle the precision bits when multiplying single-
> and double-floats?
Yes, and it tends to make us a little slower than we otherwise could
have been. As of 7.0, we have removed the bit-twiddling when compilation
is being done at speed=3/safety=0, so the users do have the option
to say that they aren't as concerned about correctness. But for most
code the precision setting is done.
> I think sbcl can use SSE, so this issue probably doesn't occur there.
Yes, if a _real_ FP unit is used :-) then the problem goes away.
The Bad news is that even though most x86 chips nowadays have SSE
hardware, the calling convention has never changed, and the x87 unit
is still the standard fp unit for 32-bit x86-based software. The Good
news is that amd64 (and the intel lookalike) have standardized on
SSE/SSE2 for their calling convention, so the problem goes completely
away for 64-bit x86-64 based applications
--
Duane Rettig ·····@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
>>>>> "Duane" == Duane Rettig <·····@franz.com> writes:
Duane> Raymond Toy <···········@ericsson.com> writes:
[snip]
>> CMUCL allows setting the precision, but the compiler does not do that
>> automatically depending on the operand types. And setting it to
>> double-float precision causes some other things to produce unexpected
>> results, at least when running the ieeefp-test suite.
Duane> If the precision-setting is global, then yes, I can see how that
Duane> would affect library routines which count on the 80-bit precision
Duane> to be set all the time.
>> Also, I do believe there is a rounding issue with x86 hardware. I'm
>> fairly sure the 80-bit format does not have a sticky bit, so rounding
>> 80-bit numbers does not behave quite "right". This also causes issues
>> when converting an 80-bit float to a 64-bit float. Without the sticky
>> bit, the 64-bit float can sometimes be rounded twice, producing an
>> incorrect result.
Duane> You may instead be seeing the effect of the lack of a save/restore
Duane> discipline when transitioning between Lisp and C. When we went to
Duane> a transitioning style (i.e. the precision is considered another register
Duane> to be restored to its original value when returning from C, and must be
Duane> "set" to 80-bit when calling out to C) this flakiness went away.
CMUCL enables the 80-bit setting when calling out to C, and restores
the previous after returning from C.
And, yes, you are correct. CMUCL should probably be more careful
about setting the precision when doing computations.
Ray
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: What's so great about lisp?
Date:
Message-ID: <87hdbf6nfr.fsf@qrnik.zagroda>
Duane Rettig <·····@franz.com> writes:
> No, if CMUCL/SBCL don't take advantage of this feature to set the
> precision to 32 or 64-bits for the single-floats and double-floats,
> respectively, then the only way they could be construed not to have
> a bug is to define all of their CL float values as 80-bit values.
It's not the only way: another is ensuring that all intermediate
results go through memory.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Duane Rettig
Subject: Re: What's so great about lisp?
Date:
Message-ID: <4br1m98hc.fsf@franz.com>
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Duane Rettig <·····@franz.com> writes:
>
>> No, if CMUCL/SBCL don't take advantage of this feature to set the
>> precision to 32 or 64-bits for the single-floats and double-floats,
>> respectively, then the only way they could be construed not to have
>> a bug is to define all of their CL float values as 80-bit values.
>
> It's not the only way: another is ensuring that all intermediate
> results go through memory.
Ah, yes; the "worse is better" approach - as long as we don't
optimize our floating point too much, we don't lose in the
correctness department... :-(
I think it is precisely the fact that intermediate results often
get stored to memory that the effect of "too much precision" is
masked for all but those esoteric (and, by Murphy's Law, critical)
cases where a complex calculation is being done in the floating
point unit without such intermediate storage (which would otherwise
have had the effect of rounding to the desired precision). It was
many years before we figured out that the x87 hardware wasn't as
flakey as we had thought, but instead just needed constant
attention to obtain the right answer. But precisely because other
lisps do _not_ store all intermediate results to memory, but also
do not carefully set the precision, we find that Allegro CL becomes
slightly slower in some FP benchmarks on x86, due to the extra
precision-setting operation.
--
Duane Rettig ·····@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
Duane Rettig <·····@franz.com> wrote:
> No, rounding only happens in an unexpected way on "x87" hardware
> if you don't ensure that the precision is set. The precision can be
> set by performing an fldcw instruction - this loads a 16-bit value
> into the x87 fcw (float control word). The precision control is
> bits 9 and 8 of this word, and its values are as follows:
>
> bits 9 8 meaning
> 0 0 single precision
> 0 1 <reserved>
> 1 0 double precision
> 1 1 double-extended precision (default).
>
That works really well only if you stick to a single precision. Otherwise
you may end up constantly switching precision, which really kills
performance on Pentium class machines (AFAIK newer machins are better here).
IMHO the problems really are in IEEE standard, i387 is faitfull to
the standard spirit (and probably also to the letter). Namely
having well defined flating point results is good. But standard
introduced many things beyond "classical" floating point, notably
denormals. Also, it is written from the assemby/hardware point
of view and strongly sugests switching modes to change precision
instead of encoding precision instructions. Now:
1) switching modes decreases performance
2) good FP algorithms typically work well on non-IEEE machines,
only small fraction _assumes_ IEEE
3) denormals may hurt more then inconsitent rounding
One can avoid switching modes setting precision to 64-bits and
using stores for 32-bits (with 80-bit precision stores after all
operations still do not give IEEE), but this makes 80-bit precision
unavailable and still slows down 32-bit operations quite a lot.
So on on i387 cost of IEEE is high, and benefits are quite limited.
Only SSE and SSE2 make IEEE really practical.
--
Waldek Hebisch
·······@math.uni.wroc.pl
From: Christophe Rhodes
Subject: Re: What's so great about lisp?
Date:
Message-ID: <sq4q7gkkbe.fsf@cam.ac.uk>
Raymond Toy <···········@ericsson.com> writes:
> [ 80-bit x86 floats. It's easier on amd64 ]
>
> This could be construed as a bug in cmucl/sbcl, but could equally be
> construed as a bug in the x86 FPU. Most of these issues don't happen
> with cmucl/sbcl on sparc or ppc or other chips with single and double
> precision floats.
It can also be viewed as looseness (or perhaps flexibility, which
means the same but has different connotations :-) in the IEEE-754
specification; I believe that the ordinary x86 floating point support
is completely conformant, under the interpretation that the
destination width is always 80 bits (and is then rounded) -- see the
first paragraph of section 5.1.
Christophe
Jon Harrop เขียน:
> Pisin Bootvong wrote:
> >> > 1.3 literal can be converted to (/ 13 10).
> >>
> >> The representation used by Mathematica tracks numerical error, so it is
> >> not equivalent to 13/10.
> >
> > Do you mean representation used by Mathematica is floating point with
> > error interval (+/- x)?
>
> Exactly.
>
> > 13/10 it's an exact number so there is no need to track numerical error.
>
> In this case, yes. In general, the number may be irrational, so a rational
> representation will have to be approximate.
>
Oh, I was only talking about converting floting point 'literal' to
rational. You can't exactly represent irrational number with floating
point. :-)
> >> > In case one really wants IEEE float, one can always use declaration.
> >>
> >> Also, it is not IEEE float.
> >
> > I was not saying Mathematica number was IEEE. I was saying that if one
> > REALLY want to use IEEE float (some specification might required number
> > to be done with IEEE behavior), then there is a way to fallback to it.
>
> Does that actually work in practice? I was under the impression that most
> CPUs aren't fussy enough about FP behaviour.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> http://www.ffconsultancy.com
Pisin Bootvong wrote:
> Jon Harrop ?????:
>> Pisin Bootvong wrote:
>> > 13/10 it's an exact number so there is no need to track numerical
>> > error.
>>
>> In this case, yes. In general, the number may be irrational, so a
>> rational representation will have to be approximate.
>
> Oh, I was only talking about converting floting point 'literal' to
> rational. You can't exactly represent irrational number with floating
> point. :-)
In that case, you could say that your conversion of the floating point
literal 1.3 to the rational 13/10 is incorrect.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Pisin Bootvong wrote:
> > Jon Harrop ?????:
> >> Pisin Bootvong wrote:
> >> > 13/10 it's an exact number so there is no need to track numerical
> >> > error.
> >>
> >> In this case, yes. In general, the number may be irrational, so a
> >> rational representation will have to be approximate.
> >
> > Oh, I was only talking about converting floting point 'literal' to
> > rational. You can't exactly represent irrational number with floating
> > point. :-)
>
> In that case, you could say that your conversion of the floating point
> literal 1.3 to the rational 13/10 is incorrect.
How so?
--
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!
David Steuber wrote:
> How so?
In the sense that it doesn't equal the float:
* (= 1.3 13/10)
NIL
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> David Steuber wrote:
> > How so?
>
> In the sense that it doesn't equal the float:
>
> * (= 1.3 13/10)
>
> NIL
What makes you think they *should* be equal? Can you not read the spec
and understand the difference between floats and rationals in Common
Lisp? Have you forgotten you are using a digital computer?
Try subtracting one from the other and see what you get. Or use a
floating point number that can be exactly represented in your
implementation. Try (rationalize 1.3) (You should probably use 1.3d0,
but that's only if you want to actually learn Lisp, instead of acting
as if you already have.) Compare the result to (rational 1.3d0) and
have a *slim* chance of being enlightened.
You can get lots of funny behavior in Mathematica numerics, only it
takes more work, and you don't have any real spec to fall back on when
things get strange.
I don't make a practice of finding weird stuff in Mathematica, because
it seems like a full-time job. I will note that your earlier
Mathematica shows floating-point numbers being claimed as equal (by the
test ==) EVEN THOUGH they have different print representations. That is
far scarier to a Lisp programmer than (= 1.3d0 13/10).
··············@hotmail.com wrote:
> What makes you think they *should* be equal?
I do not think they should be equal.
Pisin said "converting floating point 'literal' to rational". If 13/10 were
the correct "conversion" of the float literal 1.3 then it would equal 1.3.
> I will note that your earlier Mathematica shows floating-point numbers
> being claimed as equal (by the test ==) EVEN THOUGH they have different
> print representations. That is far scarier to a Lisp programmer than (=
> 1.3d0 13/10).
Mathematica is not using floating point numbers. It is using interval
arithmetic.
Look, it really doesn't matter. My point was simply that Lisp's numeric
tower is one of many possibilities. Interval arithmetic is one useful
omission. I have now said this many times in different ways in this thread.
If you're interested, read the rest of this thread.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
On Thu, 20 Oct 2005 02:06:42 +0100, Jon Harrop wrote:
>
> Mathematica is not using floating point numbers. It is using interval
> arithmetic.
>
> Look, it really doesn't matter. My point was simply that Lisp's numeric
> tower is one of many possibilities.
The important thing about Lisp is that it is a *programmable*
programming language. If you don't like the *default* numeric tower you
can rip it out and replace it with a different one, in a way that is much
more transparent than what you could do for most other languages.
For example, it is trivial to alter Lisp so that the token 1.2
always means 1.2 +/- 0.05, and it's also easy to replace all of the
arithmetic operators with ones that work on intervals.
Just my .02 (+/- .005)
Best wishes,
Bill.
William Bland <···············@gmail.com> writes:
>
> On Thu, 20 Oct 2005 02:06:42 +0100, Jon Harrop wrote:
> >
> > Mathematica is not using floating point numbers. It is using interval
> > arithmetic.
> >
> > Look, it really doesn't matter. My point was simply that Lisp's numeric
> > tower is one of many possibilities.
>
> The important thing about Lisp is that it is a *programmable*
> programming language. If you don't like the *default* numeric tower you
> can rip it out and replace it with a different one, in a way that is much
> more transparent than what you could do for most other languages.
>
> For example, it is trivial to alter Lisp so that the token 1.2
> always means 1.2 +/- 0.05, and it's also easy to replace all of the
> arithmetic operators with ones that work on intervals.
And on a more interesting note, that is precisely what was done by Roman
Cunis when he implemented a units and dimensions package for lisp. By
adding a reader macro, he made it possible to read in such useful
expressions as
12m 185.37kg.m/s2
etc, and have them construct the appropriate numeric code. Not to
mention that the implementation also uses rational numbers in a really
cool way to represent the units and dimensions information.
We have included a (slightly) modified version of his code in our Loom
knowledge representation language. It could be retrieved from that
distribution: http://www.isi.edu/isd/LOOM/
The original code can be found in the CMU archives at
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/measures/0.html
or shorter: http://tinyurl.com/8ycdv
--
Thomas A. Russ, USC/Information Sciences Institute
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: What's so great about lisp?
Date:
Message-ID: <8764rrrn2x.fsf@qrnik.zagroda>
···@sevak.isi.edu (Thomas A. Russ) writes:
> Not to mention that the implementation also uses rational numbers in
> a really cool way to represent the units and dimensions information.
Let me guess: prime factors corespond to units?
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
>
> ···@sevak.isi.edu (Thomas A. Russ) writes:
>
> > Not to mention that the implementation also uses rational numbers in
> > a really cool way to represent the units and dimensions information.
>
> Let me guess: prime factors corespond to units?
Yes. And the beauty of it is that you only need to factor the numerator
and denominator when doing I/O.
Addition and subtraction are allowed if the units rationals are =, and
multiplication and division just multiply and divide the units as well
as the magnitudes.
There is a paper about this that was published in Lisp Pointers:
Roman Cunis, "A Package for Handling Units of Measure in Lisp"
_Lisp Pointers_, vol. 5, No. 2. Apr-June 1992.
http://portal.acm.org/citation.cfm?id=1039991.1039994
--
Thomas A. Russ, USC/Information Sciences Institute
From: Christophe Rhodes
Subject: Re: What's so great about lisp?
Date:
Message-ID: <sqzmp2fovh.fsf@cam.ac.uk>
···@sevak.isi.edu (Thomas A. Russ) writes:
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
>
>>
>> ···@sevak.isi.edu (Thomas A. Russ) writes:
>>
>> > Not to mention that the implementation also uses rational numbers in
>> > a really cool way to represent the units and dimensions information.
>>
>> Let me guess: prime factors corespond to units?
>
> Yes. And the beauty of it is that you only need to factor the numerator
> and denominator when doing I/O.
>
> Addition and subtraction are allowed if the units rationals are =, and
> multiplication and division just multiply and divide the units as well
> as the magnitudes.
Better hope no-one writes the Planck length as
\hbar^{1/2} G^{1/2} / c^{3/2}
Christophe
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: What's so great about lisp?
Date:
Message-ID: <877jc8o6xz.fsf@qrnik.zagroda>
···············@hotmail.com" <············@gmail.com> writes:
>> * (= 1.3 13/10)
>>
>> NIL
>
> What makes you think they *should* be equal? Can you not read the spec
> and understand the difference between floats and rationals in Common
> Lisp? Have you forgotten you are using a digital computer?
>
> Try subtracting one from the other and see what you get.
0.0
You were generally right but the argumentation was faulty :-)
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> ···············@hotmail.com" <············@gmail.com> writes:
>
> >> * (= 1.3 13/10)
> >>
> >> NIL
> >
> > What makes you think they *should* be equal? Can you not read the spec
> > and understand the difference between floats and rationals in Common
> > Lisp? Have you forgotten you are using a digital computer?
> >
> > Try subtracting one from the other and see what you get.
>
> 0.0
>
> You were generally right but the argumentation was faulty
No, I did this and I got your result, and after a few seconds of
thought, I felt was a proper result: that the difference *to machine
floating point precision* is zero, but the original numbers are not
EXACTLY equal numerically. It follows the rules of contagion, and
proves that 13/10 gets converted accurately to floating point when
required. Floating-point subtraction of very close values will always
lead to loss of precision. This is not news, except to someone who
believes Mathematica possesses mystical powers.
On the other hand, when one uses rational, one can look at the
difference between 13/10 and the number represented by the 1.3d0
(typically 5854679515581645/4503599627370496) and see that they are not
exactly equal.
Interval arithmetic and other heuristic techniques to determine
"precision" and "accuracy" are, as far as I understand, either
pessimistic, or simply wrong. The pessimism needed to prevent outright
error makes them impractical for large-scale numerical computation.
Better to have a well-defined numeric tower with the primitives
available to tease out the details when required.
···············@hotmail.com" schrieb:
> Jon Harrop wrote:
> > David Steuber wrote:
> > > How so?
> > In the sense that it doesn't equal the float:
> > * (= 1.3 13/10)
> > NIL
[x]> (= (coerce 13/10 'float) 1.3)
T
> What makes you think they *should* be equal? ...
> Have you forgotten you are using a digital computer?
> Try subtracting one from the other and see what you get.
[x]> (= 3/10 (rationalize 0.3))
T
> Try (rationalize 1.3) (You should probably use 1.3d0,...
[x]> (print (rationalize 1.3))
13/10
> Compare the result to (rational 1.3d0)
[x]> (print (rational 1.3d0))
5854679515581645/4503599627370496
> You can get lots of funny behavior in Mathematica numerics, only it
> takes more work, and you don't have any real spec to fall back on when
> things get strange.
[x]> (truncate 13/10 1.3d0)
1 ;
0.0d0
[x]> (ftruncate 13/10 1.3d0)
1.0d0 ;
0.0d0
> I don't make a practice of finding weird stuff in Mathematica, because
> it seems like a full-time job.
Hehe. I do so in some nights, when I can not sleep.
[x]> (decode-float 1.3d0)
0.65d0 ;
1 ;
1.0d0
[x]> (integer-decode-float 1.3d0)
5854679515581645 ;
-52 ;
1
[x]> (float-digits 1.3d0)
53
[x]> (float-digits PI)
64
[x]> (setf (ext:long-float-digits) 256)
256
[x]> *floating-point-contagion-ansi*
T
... now reading some interesting boring books ...
Impnotes clisp 2.35 wise says:
..., since Common Lisp has no way of knowing the actual accuracy, [ANSI
CL standard] (and all the other standard engineering programming
languages, like C, FORTRAN etc) decides that keeping the accuracy
correct is the business of the programmer, while the language should
preserve what it can - the precision.
On Sun, 23 Oct 2005 20:28:03 +0200, lin8080 <·······@freenet.de> wrote:
.. now reading some interesting boring books ...
>
> Impnotes clisp 2.35 wise says:
> ..., since Common Lisp has no way of knowing the actual accuracy, [ANSI
> CL standard] (and all the other standard engineering programming
> languages, like C, FORTRAN etc) decides that keeping the accuracy
> correct is the business of the programmer, while the language should
> preserve what it can - the precision.
>
>
Excuse me for asking. But shouldn't that be rectified?
A way for retuning the accuracy/precition ?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jon Harrop <······@jdh30.plus.com> writes:
> David Steuber wrote:
> > lin8080 <·······@freenet.de> writes:
> >> But why is lisp so great?
> >> ...because I can think about the 30 years old fibonacci routine and do
> >> some optimation. Thats it.
> >
> > Fibonacci was my first Fortran exercise.
> >
> > In all the years since assembler has been virtually abandoned for
> > higher level programming languages, which languages will give you the
> > 10,000th Fibonacci number without making you jump through any hoops?
>
> Not that many people want to compute the 10,000th Fibonacci number, but a
> lazy, memoizing language would save you a hoop.
>
> > Which popular languages still say that 1 / 3 == 0?
>
> Which popular languages still say that 1.3 - 1.0 = 0.3:
>
> * (= (- 1.3 1.0) 0.3)
Which popular trolls have yet to learn about floating point
arithmetic?
Bj�rn
"Kris Cipa" <············@yahoo.co.nz> wrote:
> What's so great about lisp?
Some women think a speech impediment is cute.
> I'd like to know, what's the secret?
Smile and offer to show her your macro :-)
> Regards
> --
> Kris.
>