I am curious to know what advantages does Lisp have over Haskell. As
far as I know the Haskell Prelude as well as its modules implement
most of the functionality that lisp provides but with a much cleaner
and succinct syntax.
Furthermore, Paul Hudak claims that lisp is not based on lambda
calculus (as many people think) and is not a true functional language;
therefore in some instance this can make formal verification of lisp
programs difficult. I am aware that lisp has many great features such
as multiple programming paradigms, that it is extensible, adaptable,
and that it takes a pragmatic view to many things. However providing
multiple ways to accomplish something such as providing 20 different
ways to do looping seems very confusing. Why not have just one or two
standard looping methods to accomplish something?
Lisp provides many flow of control constructs with branching and
execution of different sections of programming code -- the (cond)
construct is an example.
With languages like Haskell flow of control is not an issue.
Equational reasoning promotes a declarative style of program
implementation and allows such things as parallel proccessing to be
implicit.
I would like to know what people think of newer languages such as Lisp
OCAML SML
and how they compare to Lisp. Also functional programming contests
held each year allow any language to compete. And it always seems that
languages such as OCAML, Haskell, Dylan etc alls fare well where other
languages such as Lisp never make it to the semifinals. Paul Graham
says he is creating a new language called Arc. Apparently there are
some things about lisp that he does not like. But I don't think Graham
knows about some of the newer functional languages.
Nelson Marcelino wrote:
> I would like to know what people think of newer languages such as Lisp
> OCAML SML
> and how they compare to Lisp. Also functional programming contests
> held each year allow any language to compete. And it always seems that
> languages such as OCAML, Haskell, Dylan etc alls fare well where other
> languages such as Lisp never make it to the semifinals. Paul Graham
> says he is creating a new language called Arc. Apparently there are
> some things about lisp that he does not like. But I don't think Graham
> knows about some of the newer functional languages.
Most people smart enough to use Common Lisp are also smart enough to
survey other languages before creating their own. Just because a man
likes parentheses does not mean he likes redundancy as well. :)
Nelson Marcelino wrote:
>
> I am curious to know what advantages does Lisp have over Haskell.
One issue: lazy languages can have problems with space usage. You
potentially have to keep around a lot of state in order to perform
delayed computations.
Paul
Paul Dietz wrote:
> Nelson Marcelino wrote:
>>
>> I am curious to know what advantages does Lisp have over Haskell.
>
> One issue: lazy languages can have problems with space usage. You
> potentially have to keep around a lot of state in order to perform
> delayed computations.
>
Lisp can do lazy evaluation too; it takes a few monkey-wrenches, but you
do eventually wind up with a lazy eval function.
No, I didn't write it; someone else did, and he doesn't want to give out
the code. Sorry.
Svein Ove Aas <··············@brage.info> writes:
> Lisp can do lazy evaluation too; it takes a few monkey-wrenches, but you
> do eventually wind up with a lazy eval function.
>
> No, I didn't write it; someone else did, and he doesn't want to give out
> the code. Sorry.
The CMU AI repository contains the sources of the Yale Haskell
compiler[*]. The compiler is written in Common Lisp (with lots of
macrology to make it look like T/Yale Scheme). AFAIU, Haskell
functions are translated to Lisp.
I just managed to compile the beast in CMUCL. The manual is from
1993; probably not the newest Haskell standard, but it's kinda cool to
execute a statically typed, lazy language with fancy infix syntax in
my Lisp system :-)
Helmut.
[*]http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/lang/lisp/code/syntax/haskell/0.html
Helmut Eller <········@stud3.tuwien.ac.at> writes:
> Svein Ove Aas <··············@brage.info> writes:
>
> > Lisp can do lazy evaluation too; it takes a few monkey-wrenches, but you
> > do eventually wind up with a lazy eval function.
> >
> > No, I didn't write it; someone else did, and he doesn't want to give out
> > the code. Sorry.
>
> The CMU AI repository contains the sources of the Yale Haskell
> compiler[*]. The compiler is written in Common Lisp (with lots of
> macrology to make it look like T/Yale Scheme). AFAIU, Haskell
> functions are translated to Lisp.
>
> I just managed to compile the beast in CMUCL. The manual is from
> 1993; probably not the newest Haskell standard, but it's kinda cool to
> execute a statically typed, lazy language with fancy infix syntax in
> my Lisp system :-)
Would you mind giving instructions of what you did to make it compile?
I'd like to try, but it looks to be some work. :-)
Bj�rn
·······@nada.kth.se (Bj�rn Lindberg) writes:
> Would you mind giving instructions of what you did to make it compile?
> I'd like to try, but it looks to be some work. :-)
I fiddled around some time and I am not sure if everything I did is
correct/needed. The patch below contains my modifications. I changed
the shell scripts to work with Bash, replaced some parts with ansi
counter parts, removed some workarounds for (old?) CMUCL bugs, and
disabled package locks. Now I can rebuild the system with:
export HASKELL=/scratch/yale-haskell
cd $HASKELL
source haskell-development
./com/cmu/compile
./com/cmu/build-prelude
./com/cmu/savesys
and start it with
cmucl-cvs -core bin/new-cmu-haskell.core
My wrapper script for CMUCL is 'cmucl-cvs'. If you run into problems,
it's a good idea to call 'com/cmu/clean' before proceeding and to
compile the files in the 'cl-support' directory manually.
Helmut.
diff -u -r /tmp/orig/cl-support/cl-definitions.lisp /scratch/yale-haskell/cl-support/cl-definitions.lisp
--- /tmp/orig/cl-support/cl-definitions.lisp 1993-07-14 16:53:18.000000000 +0200
+++ /scratch/yale-haskell/cl-support/cl-definitions.lisp 2004-06-02 16:04:20.000000000 +0200
@@ -120,7 +120,7 @@
;;; Allegro has renamed this stuff as per ANSI CL.
-#+allegro
+#+(or allegro cmu)
(eval-when (eval compile load)
(setf (macro-function 'define-setf-method)
(macro-function 'define-setf-expander))
diff -u -r /tmp/orig/cl-support/cl-init.lisp /scratch/yale-haskell/cl-support/cl-init.lisp
--- /tmp/orig/cl-support/cl-init.lisp 1993-07-14 16:53:18.000000000 +0200
+++ /scratch/yale-haskell/cl-support/cl-init.lisp 2004-05-28 22:54:56.000000000 +0200
@@ -6,6 +6,9 @@
;;; All of the files loaded here are assumed to be regular Common Lisp
;;; files.
+(cl:defpackage :mumble-implementation
+ (:use :cl))
+
(in-package "MUMBLE-IMPLEMENTATION")
@@ -115,12 +118,14 @@
;;; host Lisp.
#-mcl (progn
- (defvar *support-directory* "cl-support/")
- (defvar *support-binary-directory*
- (concatenate 'string
- *support-directory*
- *lisp-implementation-name*
- "/")))
+ (defvar *support-directory* (namestring (truename "cl-support/")))
+ (defvar *support-binary-directory*
+ (namestring
+ (truename
+ (concatenate 'string
+ *support-directory*
+ *lisp-implementation-name*
+ "/")))))
(defun load-compiled-cl-file (filename)
(let ((source-file (concatenate 'string
@@ -161,6 +166,8 @@
(eval-when (eval compile load)
(setf *package* (find-package "MUMBLE-USER")))
+(cl:in-package :mumble-user)
+
(load "$Y2/support/system")
(compile-haskell)
diff -u -r /tmp/orig/cl-support/cl-setup.lisp /scratch/yale-haskell/cl-support/cl-setup.lisp
--- /tmp/orig/cl-support/cl-setup.lisp 1993-07-14 16:53:18.000000000 +0200
+++ /scratch/yale-haskell/cl-support/cl-setup.lisp 2004-05-28 23:16:15.000000000 +0200
@@ -22,9 +22,5 @@
;;; on the definitional macros to arrange to export them from the MUMBLE
;;; package.
-(unless (find-package "MUMBLE-IMPLEMENTATION")
- (make-package "MUMBLE-IMPLEMENTATION" :use '("LISP")))
-
-
-
-
+(defpackage :mumble-implementation
+ (:use :cl))
diff -u -r /tmp/orig/cl-support/cl-structs.lisp /scratch/yale-haskell/cl-support/cl-structs.lisp
--- /tmp/orig/cl-support/cl-structs.lisp 1993-07-14 16:53:19.000000000 +0200
+++ /scratch/yale-haskell/cl-support/cl-structs.lisp 2004-05-29 00:02:20.000000000 +0200
@@ -412,7 +412,8 @@
;; the BOA constructor. Bogus!!!
;; If you do this in WCL, it will just quietly ignore
;; the BOA.
- #-(or akcl wcl) (:constructor nil)
+ #-(or akcl wcl cmu) (:constructor nil)
+ #+cmu (:constructor)
(:constructor ,(td-%constructor td) ,(make-boa-args slots))
(:predicate ,predicate)
(:copier nil))
@@ -424,11 +425,13 @@
;; and then complains if this doesn't match the declared
;; slot type. I think this is a bug, not a feature, but
;; here's a workaround for it.
- :type
- #+cmu ,(if (sd-%uninitialized? s)
- `(or ,(sd-type s) null)
- (sd-type s))
- #-cmu ,(sd-type s)
+
+;; :type
+;; #+cmu ,(if (sd-%uninitialized? s)
+;; `(or ,(sd-type s) null)
+;; (sd-type s))
+;; #-cmu ,(sd-type s)
+;; ,(sd-type s)
;; Can make slots read-only only if a setf-er is not
;; required by MAKE.
:read-only ,(and (sd-%read-only? s) (sd-%required? s))))
diff -u -r /tmp/orig/cl-support/cl-support.lisp /scratch/yale-haskell/cl-support/cl-support.lisp
--- /tmp/orig/cl-support/cl-support.lisp 1993-07-14 16:53:19.000000000 +0200
+++ /scratch/yale-haskell/cl-support/cl-support.lisp 2004-05-28 23:51:39.000000000 +0200
@@ -57,14 +57,11 @@
(defmacro define-mumble-synonym (name cl-name)
`(progn
- (eval-when (eval compile load) (export (list ',name) "MUMBLE"))
- (setf (symbol-function ',name) (symbol-function ',cl-name))
-#+lcl
- (lcl:def-compiler-macro ,name (&rest args)
- (cons ',cl-name args))
- ',name))
-
-
+ (eval-when (eval compile load) (export (list ',name) "MUMBLE"))
+ (setf (symbol-function ',name) (symbol-function ',cl-name))
+ (define-compiler-macro ,name (&rest args)
+ (cons ',cl-name args))
+ ',name))
;;; Use this macro to define a type synonym.
diff -u -r /tmp/orig/com/cmu/build-prelude /scratch/yale-haskell/com/cmu/build-prelude
--- /tmp/orig/com/cmu/build-prelude 1993-07-14 16:53:29.000000000 +0200
+++ /scratch/yale-haskell/com/cmu/build-prelude 2004-05-28 23:59:31.000000000 +0200
@@ -5,19 +5,19 @@
#
cd $Y2
setenv PRELUDEBIN $Y2/progs/prelude/cmu
-if (-e $PRELUDEBIN/Prelude.sparcf) then
+if (-e $PRELUDEBIN/Prelude.x86f) then
rm $PRELUDEBIN/old*
- foreach i ($PRELUDEBIN/Prelude*.{scm,sparcf})
+ foreach i ($PRELUDEBIN/Prelude*.{scm,sparcf,x86f})
mv $i $PRELUDEBIN/old-$i:t
end
endif
$CMUCL <<EOF
;; Need a big heap to compile the prelude.
-(setf ext:*bytes-consed-between-gcs* 10000000)
+;(setf ext:*bytes-consed-between-gcs* 10000000)
;; If you want to recompile
;; everything from scratch, execute the "clean" script first, or
;; else use the "compile" script to do this.
-(proclaim '(optimize (speed 3) (safety 0) (debug 0) (ext:inhibit-warnings 3)))
+;(proclaim '(optimize (speed 3) (safety 0) (debug 0) (ext:inhibit-warnings 3)))
(load "cl-support/cl-init")
;; Use the same compiler settings for processing the prelude.
(in-package :mumble-user)
diff -u -r /tmp/orig/com/cmu/clean /scratch/yale-haskell/com/cmu/clean
--- /tmp/orig/com/cmu/clean 1993-07-14 16:53:29.000000000 +0200
+++ /scratch/yale-haskell/com/cmu/clean 2004-05-28 22:58:17.000000000 +0200
@@ -1,4 +1,4 @@
#!/bin/csh
#
# delete CMU CL binaries
-'rm' $Y2/*/cmu/*.sparcf
+'rm' $Y2/*/cmu/*.sparcf $Y2/*/cmu/*.x86f
diff -u -r /tmp/orig/com/cmu/compile /scratch/yale-haskell/com/cmu/compile
--- /tmp/orig/com/cmu/compile 1993-07-14 16:53:29.000000000 +0200
+++ /scratch/yale-haskell/com/cmu/compile 2004-05-28 23:48:45.000000000 +0200
@@ -1,12 +1,14 @@
-#!/bin/csh
+
#
# compile -- compile the Yale Haskell system from scratch.
#
#
cd $Y2
$CMUCL <<EOF
-(setf ext:*bytes-consed-between-gcs* 4000000)
-(proclaim '(optimize (speed 3) (safety 0) (debug 0) (ext:inhibit-warnings 3)))
+;(load "cl-support/cl-setup")
+;(setf ext:*bytes-consed-between-gcs* 4000000)
+(ext:unlock-all-packages)
+;(proclaim '(optimize (speed 3) (safety 0) (debug 0) (ext:inhibit-warnings 3)))
(load "cl-support/cl-init")
(quit)
EOF
diff -u -r /tmp/orig/com/cmu/savesys /scratch/yale-haskell/com/cmu/savesys
--- /tmp/orig/com/cmu/savesys 1993-07-14 16:53:30.000000000 +0200
+++ /scratch/yale-haskell/com/cmu/savesys 2004-05-29 00:10:46.000000000 +0200
@@ -5,18 +5,18 @@
#
cd $Y2
setenv PRELUDEBIN $Y2/progs/prelude/cmu
-if !(-e $PRELUDEBIN/Prelude.sparcf) then
+if !(-e $PRELUDEBIN/Prelude.x86f) then
echo "Build the prelude first, stupid..."
exit
endif
$CMUCL <<EOF
;;; Load the Haskell system.
-(make-package "MUMBLE-IMPLEMENTATION" :use '("LISP"))
+;(make-package "MUMBLE-IMPLEMENTATION" :use '("LISP"))
(load "cl-support/cl-init")
;;; Set various internal switches to appropriate values for running
;;; Haskell code.
(setf ext:*bytes-consed-between-gcs* 4000000)
-(proclaim '(optimize (speed 3) (safety 0) (debug 0) (ext:inhibit-warnings 3)))
+;(proclaim '(optimize (speed 3) (safety 0) (debug 0) (ext:inhibit-warnings 3)))
(setf *load-verbose* nil)
(setf *compile-verbose* nil)
(in-package :mumble-user)
diff -u -r /tmp/orig/haskell-development /scratch/yale-haskell/haskell-development
--- /tmp/orig/haskell-development 1993-07-14 16:52:28.000000000 +0200
+++ /scratch/yale-haskell/haskell-development 2004-06-02 21:43:32.000000000 +0200
@@ -1,4 +1,4 @@
-#!/bin/csh
+#!/bin/bash
#
# Set up for Yale Haskell 2.x development
#
@@ -9,14 +9,14 @@
# You need to set this environment variable to point to the root
# directory where you have installed the Yale Haskell sources.
-setenv Y2 $HASKELL
+export Y2=$HASKELL
# Define some aliases for getting the right RCS options.
# These aliases are only for use at Yale.
-alias rco 'co -l'
-alias rci 'ci -u'
+alias rco='co -l'
+alias rci='ci -u'
# Find the "right" lisp executable.
@@ -26,20 +26,25 @@
# The Lucid CL executable we've been using is the one without fancy
# stuff like CLOS loaded.
-setenv LUCID /cs/licensed/sclisp-4.0/lisp-4-0-base
+export LUCID=/cs/licensed/sclisp-4.0/lisp-4-0-base
# Setup for CMUCL. We have this aliased to a script that will select
# the right core file for the machine you are running on.
-setenv CMUCL $Y2/bin/run-cmucl
-setenv CMUCLBIN $Y2/bin/cmucl
-setenv CMUCLLIB $Y2/bin
+#export CMUCL=$Y2/bin/run-cmucl
+#export CMUCLBIN=$Y2/bin/cmucl
+#export CMUCLLIB=$Y2/bin
+
+export CMUCL="cmucl-cvs -noinit"
+#export CMUCLBIN=$Y2/bin/cmucl
+#export CMUCLLIB=$Y2/bin
+
# This is AKCL, not ordinary KCL (which is too brain-damaged).
-setenv AKCL /net/nebula/homes/systems/hcompile/akcl/xbin/kcl
+export AKCL=/net/nebula/homes/systems/hcompile/akcl/xbin/kcl
# Set up for Franz Allegro.
@@ -47,23 +52,23 @@
# we need to be able to tell which kind of machine we're running on so
# the binaries don't get jumbled up together.
-if (-e /vmunix) then
- setenv ALLEGRODIR allegro
- setenv ALLEGRO /usr/licensed/allegro/cl
-else if (-e /mach) then
- setenv ALLEGRODIR allegro-next
- setenv ALLEGRO /usr/local/bin/lisp
-else
- echo "Can't figure out what kind of machine you're on!"
-endif
+#if (-e /vmunix) then
+# export ALLEGRODIR=allegro
+# export ALLEGRO=/usr/licensed/allegro/cl
+#else if (-e /mach) then
+# export ALLEGRODIR=allegro-next
+# export ALLEGRO=/usr/local/bin/lisp
+#else
+# echo "Can't figure out what kind of machine you're on!"
+#endif
# Set up for Harlequin Lispworks.
-setenv LISPWORKS /usr/licensed/bin/lispworks
+export LISPWORKS=/usr/licensed/bin/lispworks
# Set up for WCL
# This is not supported!
-# setenv WCL /net/nebula/homes/systems/hcompile/wcl-2.14/bin/wcl
-# setenv LD_LIBRARY_PATH /net/nebula/homes/systems/hcompile/wcl-2.14/lib
+# export WCL=/net/nebula/homes/systems/hcompile/wcl-2.14/bin/wcl
+# export LD_LIBRARY_PATH=/net/nebula/homes/systems/hcompile/wcl-2.14/lib
diff -u -r /tmp/orig/haskell-setup /scratch/yale-haskell/haskell-setup
--- /tmp/orig/haskell-setup 1993-07-14 16:51:03.000000000 +0200
+++ /scratch/yale-haskell/haskell-setup 2004-06-02 21:44:11.000000000 +0200
@@ -1,27 +1,27 @@
-#!/bin/csh
+#!/bin/bash
#
# Set up for Yale Haskell 2.x users.
#
-setenv PRELUDE $HASKELL/progs/prelude
-setenv HASKELL_LIBRARY $HASKELL/progs/lib
+export PRELUDE=$HASKELL/progs/prelude
+export HASKELL_LIBRARY=$HASKELL/progs/lib
# You may need to change this to point at the appropriate subdirectory,
# depending on which Lisp is being used.
-setenv PRELUDEBIN $PRELUDE/lucid
-#setenv PRELUDEBIN $PRELUDE/cmu
+#export PRELUDEBIN=$PRELUDE/lucid
+export PRELUDEBIN=$PRELUDE/cmu
# You may need to change this to point at the appropriate subdirectory,
# depending on which Lisp is being used.
-setenv LIBRARYBIN $HASKELL_LIBRARY/bin/lucid
-#setenv LIBRARYBIN $HASKELL_LIBRARY/bin/cmu
+#export LIBRARYBIN=$HASKELL_LIBRARY/bin/lucid
+export LIBRARYBIN=$HASKELL_LIBRARY/bin/cmu
# You may need to change this to point at the appropriate executable,
# depending on which Lisp is being used.
-setenv HASKELLPROG $HASKELL/bin/haskell
-#setenv HASKELLPROG $HASKELL/bin/cmu-haskell
+#export HASKELLPROG=$HASKELL/bin/haskell
+export HASKELLPROG=$HASKELL/bin/cmu-haskell
# You only need this next definition if you are using the CMU CL version
# of haskell and you have /tmp mounted on a tmpfs file system (it won't
# be able to initialize itself otherwise).
-setenv CMUCL_EMPTYFILE /var/tmp/empty
+#export CMUCL_EMPTYFILE=/var/tmp/empty
diff -u -r /tmp/orig/progs/demo/X11/gobang/redraw.hs /scratch/yale-haskell/progs/demo/X11/gobang/redraw.hs
--- /tmp/orig/progs/demo/X11/gobang/redraw.hs 1993-07-14 16:51:40.000000000 +0200
+++ /scratch/yale-haskell/progs/demo/X11/gobang/redraw.hs 1993-07-14 16:51:40.000000000 +0200
@@ -66,7 +66,7 @@
drawHelp (XInfo display window gcontext gcontext2 gcontextp) =
xDrawRectangle (XDrawWindow window) gcontext2 (XRect 100 100 300 200) True
`thenIO` \ _ ->
- xDrawRectangle (XDrawWindow window) gcontext (XRect 100 100 300 200) False
+ xDrawRecvangle (XDrawWindow window) gcontext (XRect 100 100 300 200) False
`thenIO` \ _ ->
xDrawRectangle (XDrawWindow window) gcontext (XRect 102 102 296 196) False
`thenIO` \ _ ->
Nelson Marcelino wrote:
> I am curious to know what advantages does Lisp have over Haskell. As
> far as I know the Haskell Prelude as well as its modules implement
> most of the functionality that lisp provides but with a much cleaner
> and succinct syntax.
<much uninformed speculation elided>
Just Try It. (Common Lisp)
One thing I have to realized is that Lisp does not need to apologize
or explain why things are the way they are. Maybe the functional
crowd needs to evangelize (this OP seems to validate that) and
compete.
Do or Not Do, there is no explain.
Wade
·········@yahoo.com (Nelson Marcelino) writes:
> Also functional programming contests held each year allow any
> language to compete. And it always seems that languages such as
> OCAML, Haskell, Dylan etc alls fare well where other languages such
> as Lisp never make it to the semifinals.
Not many people have entered the ICFP contest with Lisp. The next
contest [*] is in one week and it would be great to see a batch of
Lisp programs entered this time around.
C++ is the defending champion. Unite against the common foe!
Cheers,
Luke
[*]: http://www.cis.upenn.edu/proj/plclub/contest/
Luke Gorrie wrote:
> ·········@yahoo.com (Nelson Marcelino) writes:
>
>> Also functional programming contests held each year allow any
>> language to compete. And it always seems that languages such as
>> OCAML, Haskell, Dylan etc alls fare well where other languages such
>> as Lisp never make it to the semifinals.
>
> Not many people have entered the ICFP contest with Lisp. The next
> contest [*] is in one week and it would be great to see a batch of
> Lisp programs entered this time around.
>
> C++ is the defending champion. Unite against the common foe!
>
> Cheers,
> Luke
>
> [*]: http://www.cis.upenn.edu/proj/plclub/contest/
That's... mean.
Now I want to try it, but the date of the contest (if repeated) ensures
that now CS student at my university will ever be able to make the time.
Couldn't it have been just a week later?
Luke Gorrie wrote:
> ·········@yahoo.com (Nelson Marcelino) writes:
>
>> Also functional programming contests held each year allow any
>> language to compete. And it always seems that languages such as
>> OCAML, Haskell, Dylan etc alls fare well where other languages such
>> as Lisp never make it to the semifinals.
>
> Not many people have entered the ICFP contest with Lisp. The next
> contest [*] is in one week and it would be great to see a batch of
> Lisp programs entered this time around.
>
> C++ is the defending champion. Unite against the common foe!
>
> Cheers,
> Luke
>
> [*]: http://www.cis.upenn.edu/proj/plclub/contest/
That's... mean.
Now I want to try it, but the date of the contest (if repeated) ensures
that now CS student at my university will ever be able to make the time.
Couldn't it have been just a week later?
All whining aside, are there any other such contests floating around that
have more benign entry dates?
Svein Ove Aas wrote:
> All whining aside, are there any other such contests floating around that
> have more benign entry dates?
If you like knowledge discovery and data mining, you may be
interested in the following:
The KDD-Cup 2004 Knowledge Discovery and Data Mining
Competition is being held in conjunction with the Tenth
Annual ACM SIGKDD Conference that will take place this
year on August 22 through 25 in Seattle, Washington.
This year there are two challenge tasks, one in protein
matching and one in high-energy particle physics.
The problems were chosen in order to be of interest
to both academia and industry. Students are particularly
encouraged to participate.
This year's performance criteria include Accuracy,
Squared Error, Cross Entropy, and ROC Area. The specific
tasks, datasets, and code for computing the performance
criteria became available April 28, 2004 at
http://www.acm.org/sigkdd/kdd2004/cup.html.
Registration will remain open during the first half of
the summer. Submissions are due by July 14, 2004.
Let me know if you're interested in this. Maybe we can form a
Lisp team.
Arthur Lemmens wrote:
> Svein Ove Aas wrote:
>
>> All whining aside, are there any other such contests floating around
>> that have more benign entry dates?
>
> If you like knowledge discovery and data mining, you may be
> interested in the following:
>
> The KDD-Cup 2004 Knowledge Discovery and Data Mining
> Competition is being held in conjunction with the Tenth
> Annual ACM SIGKDD Conference that will take place this
> year on August 22 through 25 in Seattle, Washington.
>
> This year there are two challenge tasks, one in protein
> matching and one in high-energy particle physics.
> The problems were chosen in order to be of interest
> to both academia and industry. Students are particularly
> encouraged to participate.
>
> This year's performance criteria include Accuracy,
> Squared Error, Cross Entropy, and ROC Area. The specific
> tasks, datasets, and code for computing the performance
> criteria became available April 28, 2004 at
> http://www.acm.org/sigkdd/kdd2004/cup.html.
>
> Registration will remain open during the first half of
> the summer. Submissions are due by July 14, 2004.
>
> Let me know if you're interested in this. Maybe we can form a
> Lisp team.
I'm still a newbie in Lisp, although I'm planning to get rid of that
problem over the summer. I can program in it, but not much faster than
Java, so far.
That said, I'm taking to Lisp like a duck to water; I feel like I've
finally found what I'm looking for. Despite not really having time for
it, I'm already at a higher level in Lisp than in Java - at four months
vs. eight months, at that.
I'm pretty sure that competition is above my level, though. I've only
studied a year. Sorry.
Nelson Marcelino wrote:
> I am curious to know what advantages does Lisp have over Haskell. As
> far as I know the Haskell Prelude as well as its modules implement
> most of the functionality that lisp provides but with a much cleaner
> and succinct syntax.
There exist many subsets of Common Lisp. ;)
> Furthermore, Paul Hudak claims that lisp is not based on lambda
> calculus (as many people think) and is not a true functional language;
> therefore in some instance this can make formal verification of lisp
> programs difficult.
Older Lisp dialects were not based on lambda calculus, or better yet on
a slightly wrong understanding of lambda calculus. This has been
resolved in the mid-70's. Of course, Common Lisp provides a correct
lambda abstraction, being a Lisp dialect that was designed afterwards.
It's not quite clear what you mean by "true" functional language.
Haskellers have an extreme view on what should be considered functional
- they insist that side effects should not be part of a language.
Single-paradigm languages have certain advantages in that they don't
need to compromise in some respects, but this has the downside that they
are likely to be useless in some scenarios.
On the other hand, Common Lisp is a multi-paradigm language. If you
think that a particular problem is better solved with a pure functional
approach, nothing in it stands in your way to actually do so. On the
other hand, if you do need side effects, object-oriented abstractions,
logic programming constructs, etc. pp., you are not forced to switch the
language, but instead you can do everything in its unified framework. To
some, this is more attractive than a language that takes one very
specific and particular approach to an extreme.
For example, see ACL2 for a purely applicative subset of Common Lisp,
embedded in Common Lisp - http://www.cs.utexas.edu/users/moore/acl2/
> I am aware that lisp has many great features such
> as multiple programming paradigms, that it is extensible, adaptable,
> and that it takes a pragmatic view to many things. However providing
> multiple ways to accomplish something such as providing 20 different
> ways to do looping seems very confusing. Why not have just one or two
> standard looping methods to accomplish something?
Because the various abstractions provided in Common Lisp have their
respective strengths under different circumstances. The fact that you
can express any iteration as recursion doesn't mean that the code
becomes more understandable when you need to read it.
> Lisp provides many flow of control constructs with branching and
> execution of different sections of programming code -- the (cond)
> construct is an example.
>
> With languages like Haskell flow of control is not an issue.
> Equational reasoning promotes a declarative style of program
> implementation and allows such things as parallel proccessing to be
> implicit.
Sure. If you want it, embed it in Common Lisp.
> I would like to know what people think of newer languages such as Lisp
> OCAML SML
> and how they compare to Lisp. Also functional programming contests
> held each year allow any language to compete. And it always seems that
> languages such as OCAML, Haskell, Dylan etc alls fare well where other
> languages such as Lisp never make it to the semifinals. Paul Graham
> says he is creating a new language called Arc. Apparently there are
> some things about lisp that he does not like. But I don't think Graham
> knows about some of the newer functional languages.
That's guesswork. Ask him.
Pascal
--
ECOOP 2004 Workshops - Oslo, Norway
*1st European Lisp and Scheme Workshop, June 13*
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
*2nd Post-Java Workshop, June 14*
http://prog.vub.ac.be/~wdmeuter/PostJava04/
Pascal Costanza wrote:
> It's not quite clear what you mean by "true" functional language.
> Haskellers have an extreme view on what should be considered functional
> - they insist that side effects should not be part of a language.
Not true. Haskellers only insist that side effecting parts of code
should be clearly and systematically separated from pure code.
> Because the various abstractions provided in Common Lisp have their
> respective strengths under different circumstances. The fact that you
> can express any iteration as recursion doesn't mean that the code
> becomes more understandable when you need to read it.
I rarely use direct recursion in Haskell. Most of the time it suffices
to use higher order functions (map, foldl, foldr, unfoldr, mapM,
sequence, ...) that implement various recursion schemes.
The following snippet shows both side effects and looping:
for [1..10] print
If you want, you can write it in a Lispy way
(for [1..10] print)
;)
PS. for l f = mapM_ f l
Best regards,
Tom
--
.signature: Too many levels of symbolic links
Tomasz Zielonka <··········@zodiac.mimuw.edu.pl> wrote
> If you want, you can write it in a Lispy way
>
> (for [1..10] print)
ITYM
(loop for i from 1 to 10 do (print i))
From: Christopher C. Stacy
Subject: Re: Haskell: functional languages vs Lisp
Date:
Message-ID: <ud64oilfo.fsf@news.dtpq.com>
>>>>> On 28 May 2004 06:30:42 -0700, Nelson Marcelino ("Nelson") writes:
Nelson> However providing multiple ways to accomplish something such
Nelson> as providing 20 different ways to do looping seems very
Nelson> confusing. Why not have just one or two standard looping
Nelson> methods to accomplish something? Lisp provides many flow of
Nelson> control constructs with branching and execution of different
Nelson> sections of programming code -- the (cond) construct is an
Nelson> example.
Why not just have one universal natural language in which only one
single sentence expresses a given concept, rather than having
multiple ways of expressing the same thing?
If you like Haskell better than Lisp, you should stick to it.
Maybe it's a better language for what you're trying to do.
Laundry lists of features, abstract commentary on the language,
trivial examples, and flames given by fans of Lisp are unlikely to
convince you, and will just waste your and our time. Alternatively,
you could study Lisp by writing some significant programs in it.
Assuming you have lots of help (much of which can be obtained here),
you could probably internalize a deep enough understanding of Lisp
after about 4 or 5 months of full-time.
·········@yahoo.com (Nelson Marcelino) writes:
> I am curious to know what advantages does Lisp have over Haskell.
Haskell is an obscure, academic language for a niche market.
Lisp is an industrial strength language with a healthy number of
implementations, rich and growing set of available libraries, larger
and still growing user base, and support for multiple paradigms.
Lisp can be adapted to fit the domain of the problem to be solved in
ways that are portable across implementations.
I just had to say it.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Nelson Marcelino wrote:
> I am curious to know what advantages does Lisp have over Haskell.
Not much in the way of specific comparison, but fwiw:
http://alu.cliki.net/Conrad%20Barski
Maybe send Conrad an email?
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Nelson Marcelino wrote:
> I am curious to know what advantages does Lisp have over Haskell.
It's been around a long time and its features reflect a lot of what
people need and want to do with a programming language. It's especially
easy to edit, and easy to make tools to support editing, refactoring,
and other code-construction tasks. It supports live updates of running
applications better than any other language or runtime except perhaps
Smalltalk. Also along with Smalltalk, it provides exceptional support
for catching and repairing errors and other deficiencies while an
application is running.
> I would like to know what people think of newer languages such as Lisp
> OCAML SML
> and how they compare to Lisp.
I like ML generally, and especially Ocaml, a lot. I use it almost as
much as I use Lisp. Basically, when I need to do something complicated
that must run very fast and is best delivered as a single,
self-contained command-line utility, I write it in Ocaml. For
interactive things (or long-running processes with interactive monitors)
I prefer to use Lisp.
It so happens that over the past few months I've conducted a sort of
informal experiment, using Common Lisp, Scheme, and Ocaml to write and
rewrite the same nontrivial application. The application is a
commmand-line code-groveling tools that has to process about 600MB of
data on each run and do a bunch of data-extraction and restructuring,
and write a report. It's for construction of part of a product that
customers pay a lot of money for, so it has to be reliable and good, but
I have a lot of freedom to build it any way I like (as long as it keeps
doing its job quickly and reliably). Without any particular agenda (I
tried all three languages because they're the ones I like most), I have
evolved a process that involves prototyping new features in Common Lisp
and then delivering them in Ocaml. I find it easier to explore the
problem space interactively in Lisp, and easier to deliver a program
whose source is concise, and whose executable is small, simple, and fast
in Ocaml. It's pretty easy to translate ideas from Lisp to Ocaml.
mikel <·····@evins.net> wrote on Fri, 28 May 2004:
> It so happens that over the past few months I've conducted a sort of informal
> experiment, using Common Lisp, Scheme, and Ocaml to write and rewrite the
> same nontrivial application.
[...]
> I have evolved a process that involves prototyping new features
> in Common Lisp and then delivering them in Ocaml. I find it easier to explore
> the problem space interactively in Lisp, and easier to deliver a program
> whose source is concise, and whose executable is small, simple, and fast in
> Ocaml.
If you've already got a working prototype in Lisp, you've surely attempted
the approach of profiling & optimizing the existing program, while staying
in Lisp.
My intuition is that translating a working Lisp prototype into Ocaml would
be more work than simply optimizing the Lisp code. Yet your experience
suggests that you prefer writing the final version in Ocaml.
Can you explain this in any more detail? What difficulties did you encounter
in trying to optimize the Lisp code for "small, simple, and fast" which led
you to prefer re-writing in Ocaml instead?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Whenever I see a beautiful swan, gliding along, I think, The world is not so
terrible. But then he ducks his head underwater, with his rear end sticking up
in the air, and I think, Yes, it is.
-- Deep Thoughts, by Jack Handey [1999]
Don Geddis wrote:
> mikel <·····@evins.net> wrote on Fri, 28 May 2004:
>
>>It so happens that over the past few months I've conducted a sort of informal
>>experiment, using Common Lisp, Scheme, and Ocaml to write and rewrite the
>>same nontrivial application.
>
> [...]
>
>>I have evolved a process that involves prototyping new features
>>in Common Lisp and then delivering them in Ocaml. I find it easier to explore
>>the problem space interactively in Lisp, and easier to deliver a program
>>whose source is concise, and whose executable is small, simple, and fast in
>>Ocaml.
>
>
> If you've already got a working prototype in Lisp, you've surely attempted
> the approach of profiling & optimizing the existing program, while staying
> in Lisp.
Yep, and relevant to that, I really like the profiling tools in the
Allegro 7.0 beta.
> My intuition is that translating a working Lisp prototype into Ocaml would
> be more work than simply optimizing the Lisp code. Yet your experience
> suggests that you prefer writing the final version in Ocaml.
My intuition would say the same thing. Experiment contradicted my
intuition (an experience I often have with optimization).
> Can you explain this in any more detail? What difficulties did you encounter
> in trying to optimize the Lisp code for "small, simple, and fast" which led
> you to prefer re-writing in Ocaml instead?
I can do a complete rewrite of the application as it stands now in two
days in either Common Lisp or Ocaml. (I know it really well now.)
At the end of the most recent rewrite I have a source program that, when
compiled, does the job I want it to do. The proportional runtime of the
code, run on the same machine over many test runs, with the Ocaml
version normalized to 1.0, is, approximately:
Ocaml 1.0
Allegro 1.95
SBCL 2.75
OpenMCL 4.0
Obviously, these times are likely to be idiosyncratic to the particular
tools I've been writing. Of course, these numbers should not be taken as
evidence of anything general about the languages or compilers in
question. I wish I didn't have to say that, but this is USENET, so of
course I do (and of course, someone will ignore that caveat).
The Ocaml-built tool is a little smaller in source form, and a lot
smaller in object form. It's a single executable file; the lisp versions
require a bit more compicated setup involving at least two files (lisp
kernel and image), or three if I want to add a launcher script that
hides the somewhat more complicated command line you need to make the
Lisp versions go.
The Ocaml version is quite a bit faster *without* any attempt to
optimize. It's a good compiler. Intuition notwithstanding, porting a
feature from Lisp to Ocaml typically takes me very little time--much,
much less than porting between Lisp and, say, Java or C++.
Why don't I do all the work in Common Lisp? I guess mostly because the
final product is two or three files totalling several MB (quite a few
MB, actually, if I use SBCL), versus a single file weighing 500K. Plus,
the Lisp is slower, and this tool is a batch process whose runtime is
long enough that you notice.
Why don't I spend the time profiling the lisp code? Well, I did that in
the beginning. In fact, I like profiling and bumming cycles; it's
satisfying. But I'm on the clock with this stuff, and it takes less time
to move features to Ocaml than to bum cycles in Lisp. So I can spend my
time bumming cycles, or I can spend it experimenting with improvements
to the tool.
Why don't I just do the work in Ocaml to begin with? Because Lisp is
still better for exploring ideas. It's easier to munge data, to look at
it, and to monkey with it. It's *possible* to do some of that in the ML
toplevel, but not as convenient.
All that said, although I like ML a lot, I like lisp more, and I'll
usually tend to use lisp first for most things. I also tend to deliver
apps in lisp, and not ocaml, if they are supposed to run continuously
for a long time and support interaction. I like to be able to get to a
repl that gives me convenient access to the whole runtime. Ocaml's
toplevel isn't as convenient that way.
In article <···················@newssvr27.news.prodigy.com>,
mikel <·····@evins.net> wrote:
> Nelson Marcelino wrote:
> > I am curious to know what advantages does Lisp have over Haskell.
>
> It's been around a long time and its features reflect a lot of what
> people need and want to do with a programming language. It's especially
> easy to edit, and easy to make tools to support editing, refactoring,
> and other code-construction tasks. It supports live updates of running
> applications better than any other language or runtime except perhaps
> Smalltalk. Also along with Smalltalk, it provides exceptional support
> for catching and repairing errors and other deficiencies while an
> application is running.
>
> > I would like to know what people think of newer languages such as Lisp
> > OCAML SML
> > and how they compare to Lisp.
>
> I like ML generally, and especially Ocaml, a lot. I use it almost as
> much as I use Lisp. Basically, when I need to do something complicated
> that must run very fast and is best delivered as a single,
> self-contained command-line utility, I write it in Ocaml. For
> interactive things (or long-running processes with interactive monitors)
> I prefer to use Lisp.
>
> It so happens that over the past few months I've conducted a sort of
> informal experiment, using Common Lisp, Scheme, and Ocaml to write and
> rewrite the same nontrivial application. The application is a
> commmand-line code-groveling tools that has to process about 600MB of
> data on each run and do a bunch of data-extraction and restructuring,
> and write a report. It's for construction of part of a product that
> customers pay a lot of money for, so it has to be reliable and good, but
> I have a lot of freedom to build it any way I like (as long as it keeps
> doing its job quickly and reliably). Without any particular agenda (I
> tried all three languages because they're the ones I like most), I have
> evolved a process that involves prototyping new features in Common Lisp
> and then delivering them in Ocaml. I find it easier to explore the
> problem space interactively in Lisp, and easier to deliver a program
> whose source is concise, and whose executable is small, simple, and fast
> in Ocaml. It's pretty easy to translate ideas from Lisp to Ocaml.
There are a lot of approaches to delivery.
Some people just don't want to rewrite the code in another
language (which can be tough ;-) ).
a) Delivery system like for example in LispWorks
b) Lisp->C compiler
c) Subset languages with delivery in static language.
Like 'Stella' (http://www.isi.edu/isd/LOOM/Stella/index.html).
Rainer Joswig wrote:
> In article <···················@newssvr27.news.prodigy.com>,
> mikel <·····@evins.net> wrote:
>
>
>>Nelson Marcelino wrote:
>>
>>>I am curious to know what advantages does Lisp have over Haskell.
>>
>>It's been around a long time and its features reflect a lot of what
>>people need and want to do with a programming language. It's especially
>>easy to edit, and easy to make tools to support editing, refactoring,
>>and other code-construction tasks. It supports live updates of running
>>applications better than any other language or runtime except perhaps
>>Smalltalk. Also along with Smalltalk, it provides exceptional support
>>for catching and repairing errors and other deficiencies while an
>>application is running.
>>
>>
>>>I would like to know what people think of newer languages such as Lisp
>>>OCAML SML
>>>and how they compare to Lisp.
>>
>>I like ML generally, and especially Ocaml, a lot. I use it almost as
>>much as I use Lisp. Basically, when I need to do something complicated
>>that must run very fast and is best delivered as a single,
>>self-contained command-line utility, I write it in Ocaml. For
>>interactive things (or long-running processes with interactive monitors)
>>I prefer to use Lisp.
>>
>>It so happens that over the past few months I've conducted a sort of
>>informal experiment, using Common Lisp, Scheme, and Ocaml to write and
>>rewrite the same nontrivial application. The application is a
>>commmand-line code-groveling tools that has to process about 600MB of
>>data on each run and do a bunch of data-extraction and restructuring,
>>and write a report. It's for construction of part of a product that
>>customers pay a lot of money for, so it has to be reliable and good, but
>>I have a lot of freedom to build it any way I like (as long as it keeps
>>doing its job quickly and reliably). Without any particular agenda (I
>>tried all three languages because they're the ones I like most), I have
>>evolved a process that involves prototyping new features in Common Lisp
>>and then delivering them in Ocaml. I find it easier to explore the
>>problem space interactively in Lisp, and easier to deliver a program
>>whose source is concise, and whose executable is small, simple, and fast
>>in Ocaml. It's pretty easy to translate ideas from Lisp to Ocaml.
>
>
> There are a lot of approaches to delivery.
>
> Some people just don't want to rewrite the code in another
> language (which can be tough ;-) ).
>
> a) Delivery system like for example in LispWorks
> b) Lisp->C compiler
> c) Subset languages with delivery in static language.
> Like 'Stella' (http://www.isi.edu/isd/LOOM/Stella/index.html).
Sure. If you had asked me a few months ago if I would deliver anything
this way, I would have said 'of course not'. But it happens to be what
works well for me in my current circumstances. I stumbled upon it,
really. It probably it works well mostly because rewriting these
features in Ocaml *isn't* hard for me. That result can't be generalized
across people or projects, I'm pretty sure.
Hello!
mikel <·····@evins.net> wrote:
>Nelson Marcelino wrote:
>> I am curious to know what advantages does Lisp have over Haskell.
>It's been around a long time and its features reflect a lot of what
>people need and want to do with a programming language. It's especially
>easy to edit, and easy to make tools to support editing, refactoring,
>and other code-construction tasks. It supports live updates of running
>applications better than any other language or runtime except perhaps
>Smalltalk.
You've forgotten Erlang, which also has support for some "higher" patterns
of run-time software updates in its standard libraries.
>[...]
Kind regards,
Hannah.
Hannah Schroeter wrote:
> Hello!
>
> mikel <·····@evins.net> wrote:
>
>>Nelson Marcelino wrote:
>>
>>>I am curious to know what advantages does Lisp have over Haskell.
>
>
>>It's been around a long time and its features reflect a lot of what
>>people need and want to do with a programming language. It's especially
>>easy to edit, and easy to make tools to support editing, refactoring,
>>and other code-construction tasks. It supports live updates of running
>>applications better than any other language or runtime except perhaps
>>Smalltalk.
>
>
> You've forgotten Erlang, which also has support for some "higher" patterns
> of run-time software updates in its standard libraries.
I stand corrected.
Hello!
mikel <·····@evins.net> wrote:
>[...]
>> You've forgotten Erlang, which also has support for some "higher" patterns
>> of run-time software updates in its standard libraries.
>I stand corrected.
No problem.
However, especially that higher level support (but partly also the
basic builtin support) is quite a bit superior than what Lisp offers
out of the box.
Kind regards,
Hannah.
······@schlund.de (Hannah Schroeter) writes:
> Hello!
>
> mikel <·····@evins.net> wrote:
>>[...]
>
>>> You've forgotten Erlang, which also has support for some "higher" patterns
>>> of run-time software updates in its standard libraries.
>
>>I stand corrected.
>
> No problem.
>
> However, especially that higher level support (but partly also the
> basic builtin support) is quite a bit superior than what Lisp offers
> out of the box.
Sounds interesting -- can you say a bit more about this?
'as
Hello!
Alexander Schmolck <··········@gmx.net> wrote:
>[...]
>> However, especially that higher level support (but partly also the
>> basic builtin support) is quite a bit superior than what Lisp offers
>> out of the box.
>Sounds interesting -- can you say a bit more about this?
Sorry. Don't have the time/energy to write something more detailed
up.
The docs (as well as Erlang/OTP itself) are available via www.erlang.org.
Kind regards,
Hannah.
·········@yahoo.com (Nelson Marcelino) writes:
> I am curious to know what advantages does Lisp have over Haskell. As
> far as I know the Haskell Prelude as well as its modules implement
> most of the functionality that lisp provides but with a much cleaner
> and succinct syntax.
Cleanness and succinctness are in the eye of the beholder.
> and that it takes a pragmatic view to many things. However providing
> multiple ways to accomplish something such as providing 20 different
> ways to do looping seems very confusing. Why not have just one or two
> standard looping methods to accomplish something?
Just pick the one you like most, and forget the others. You won't be
charged any additional fees.
> languages such as Lisp never make it to the semifinals. Paul Graham
> says he is creating a new language called Arc. Apparently there are
> some things about lisp that he does not like. But I don't think Graham
^^^^
Common Lisp
> knows about some of the newer functional languages.
Any evidence?
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Nelson Marcelino <·········@yahoo.com> wrote:
> I am curious to know what advantages does Lisp have over Haskell. As
/~~~~~~~~~~~\
| DO NOT FEED | /| /|
| THE TROLLS | _O~O_//
\___________/ / \
|| / / |
|| \__/~~ \
||_ /\___| |/\
|-- |____|nual |_| L|
|-- ____| | | |
\-/ /_____| |__| /~
| UUUU |__/
\ /
~~| |~| |~
| | | |
__/__/ |
____________{ { |________
~~ ~~~~~
To the OP: Even if you didn't mean to troll, you certainly managed...
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
I am hardly an expert in Haskell, but I have tried it.
My first impression is that is more tedious to work with.
Futher I find the syntax unappealing and almost unreadable.
But peaple are different.
You claim that Haskell provides a cleaner and more succinct syntax.
I have have a hard time understanding what you mean.
As far as I can see only scheem has a cleaner syntax than Common Lisp.
It can't get much simpler and still be turing complete.
I quickly turned back to lisp but if you prefer Hascell then
by all means use it.
On 28 May 2004 06:30:42 -0700, Nelson Marcelino <·········@yahoo.com>
wrote:
> I am curious to know what advantages does Lisp have over Haskell. As
> far as I know the Haskell Prelude as well as its modules implement
> most of the functionality that lisp provides but with a much cleaner
> and succinct syntax.
> Furthermore, Paul Hudak claims that lisp is not based on lambda
> calculus (as many people think) and is not a true functional language;
> therefore in some instance this can make formal verification of lisp
> programs difficult. I am aware that lisp has many great features such
> as multiple programming paradigms, that it is extensible, adaptable,
> and that it takes a pragmatic view to many things. However providing
> multiple ways to accomplish something such as providing 20 different
> ways to do looping seems very confusing. Why not have just one or two
> standard looping methods to accomplish something?
> Lisp provides many flow of control constructs with branching and
> execution of different sections of programming code -- the (cond)
> construct is an example.
>
> With languages like Haskell flow of control is not an issue.
> Equational reasoning promotes a declarative style of program
> implementation and allows such things as parallel proccessing to be
> implicit.
>
> I would like to know what people think of newer languages such as Lisp
> OCAML SML
> and how they compare to Lisp. Also functional programming contests
> held each year allow any language to compete. And it always seems that
> languages such as OCAML, Haskell, Dylan etc alls fare well where other
> languages such as Lisp never make it to the semifinals. Paul Graham
> says he is creating a new language called Arc. Apparently there are
> some things about lisp that he does not like. But I don't think Graham
> knows about some of the newer functional languages.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
·········@yahoo.com (Nelson Marcelino) writes:
> Furthermore, Paul Hudak claims that lisp is not based on lambda
> calculus (as many people think) and is not a true functional language;
> therefore in some instance this can make formal verification of lisp
> programs difficult. I am aware that lisp has many great features such
> as multiple programming paradigms, that it is extensible, adaptable,
Lisp is neither a) purely functional (no side effects except through
monads), nor b) type-checked at compile time (no runtime type errors
can sink your ship; although it _can_ happen even with a compile-time
checked language like Standard ML, in some rather extreme cases.) I
think b) is the major problem. That's the one single thing off the
top of my head that _can't_ be done within Common Lisp, and which is
causing frequent problems.
> I would like to know what people think of newer languages such as Lisp
> OCAML SML
> and how they compare to Lisp. Also functional programming contests
The problem is that while these languages are all nice and excellent,
and for a certain range of applications without doubt more suitable
than Common Lisp, programming anything not alike a theorem prover, or
maybe a compiler, is a rather tedious thing to do.
--
Matthias Buelow; ···@{mukappabeta,informatik.uni-wuerzburg}.de
Matthias Buelow wrote:
> ·········@yahoo.com (Nelson Marcelino) writes:
>
>>Furthermore, Paul Hudak claims that lisp is not based on lambda
>>calculus (as many people think) and is not a true functional language;
>>therefore in some instance this can make formal verification of lisp
>>programs difficult. I am aware that lisp has many great features such
>>as multiple programming paradigms, that it is extensible, adaptable,
>
> Lisp is neither a) purely functional (no side effects except through
> monads), nor b) type-checked at compile time (no runtime type errors
> can sink your ship; although it _can_ happen even with a compile-time
> checked language like Standard ML, in some rather extreme cases.) I
> think b) is the major problem. That's the one single thing off the
> top of my head that _can't_ be done within Common Lisp, and which is
> causing frequent problems.
In Common Lisp, runtime type errors also don't "sink your ship". The
worst that can happen is that an exception handler is invoked, and there
is a good chance that you may be able to correct the situation which led
to the error and then move on. (Exception handlers in Common Lisp don't
wind up the stack by default, so it's possible to return something
useful from it, for example, or invoke some restart that redirects the
control flow to a well-defined entry point.)
Runtime type errors don't cause frequent problems, and of course it's
possible to add static type checking to Common Lisp, at least to a
certain degree.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza <········@web.de> writes:
> In Common Lisp, runtime type errors also don't "sink your ship". The worst
> that can happen is that an exception handler is invoked, and there is a good
> chance that you may be able to correct the situation which led to the error
> and then move on.
Nope -- the worst that can happen is that you did something with undefined
consequences and your system *silently* starts behaving in an unpredictable
fashion. According to Appel[*] SML programs are safe in the respect that they
"cannot corrupt the runtime system so that further execution of the program is
not faithful to the language semantics". Unless I'm misunderstanding something
this is a much more significant difference than whether certain errors are
detected a compile time or at runtime.
'as
[*] http://ncstrl.cs.princeton.edu/expand.php?id=TR-364-92
Alexander Schmolck wrote:
> Pascal Costanza <········@web.de> writes:
>
>>In Common Lisp, runtime type errors also don't "sink your ship". The worst
>>that can happen is that an exception handler is invoked, and there is a good
>>chance that you may be able to correct the situation which led to the error
>>and then move on.
>
> Nope -- the worst that can happen is that you did something with undefined
> consequences and your system *silently* starts behaving in an unpredictable
> fashion. According to Appel[*] SML programs are safe in the respect that they
> "cannot corrupt the runtime system so that further execution of the program is
> not faithful to the language semantics". Unless I'm misunderstanding something
> this is a much more significant difference than whether certain errors are
> detected a compile time or at runtime.
You are talking about the case in which a language doesn't protect you
against type errors at all. That's clearly not desirable. A language
implementation that performs dynamic type checks also cannot behave in
ways that don't reflect the language semantics.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza <········@web.de> writes:
> Alexander Schmolck wrote:
>
>> Pascal Costanza <········@web.de> writes:
>>
>>>In Common Lisp, runtime type errors also don't "sink your ship". The worst
>>>that can happen is that an exception handler is invoked, and there is a good
>>>chance that you may be able to correct the situation which led to the error
>>> and then move on.
>> Nope -- the worst that can happen is that you did something with undefined
>> consequences and your system *silently* starts behaving in an unpredictable
>> fashion. According to Appel[*] SML programs are safe in the respect that they
>> "cannot corrupt the runtime system so that further execution of the program is
>> not faithful to the language semantics". Unless I'm misunderstanding something
>> this is a much more significant difference than whether certain errors are
>> detected a compile time or at runtime.
>
> You are talking about the case in which a language doesn't protect you
> against type errors at all.
No, I was talking about CL not protecting against *some* type errors.
> That's clearly not desirable. A language implementation that performs
> dynamic type checks also cannot behave in ways that don't reflect the
> language semantics.
There are plenty of operations in Common lisp that yield undefined behavior
and some of them would seem to me to be runtime type errors, e.g. the ever
popular (let ((l '(1 2 3))) (setf (car l) 3)) were an illegal attempt is made
to mutate a constant cons cell. Also I would understand undefined behavior to
imply that "further execution of the program" can proceed in a way that is
*not* faithful to the language semantics. I read Appel's statement as a claim
that this type of undefined behavior cannot occur in SML.
As I said, I'm not sure that my interpretation is correct. But even if it
isn't -- as long as you are willing to regard the setf example above as a
runtime type error then the invocation of an exception handler is *not* the
worst case scenario for a runtime error in CL.
'as
Alexander Schmolck wrote:
> There are plenty of operations in Common lisp that yield undefined behavior
> and some of them would seem to me to be runtime type errors, e.g. the ever
> popular (let ((l '(1 2 3))) (setf (car l) 3)) were an illegal attempt is made
> to mutate a constant cons cell. Also I would understand undefined behavior to
> imply that "further execution of the program" can proceed in a way that is
> *not* faithful to the language semantics. I read Appel's statement as a claim
> that this type of undefined behavior cannot occur in SML.
>
> As I said, I'm not sure that my interpretation is correct. But even if it
> isn't -- as long as you are willing to regard the setf example above as a
> runtime type error then the invocation of an exception handler is *not* the
> worst case scenario for a runtime error in CL.
OK, agreed. You are referring to the operations with "undefined
consequences" in the Common Lisp spec, and I haven't thought about them.
My gut reaction would be that any language has a set of rules of thumbs
to follow so that you don't get into trouble (avoiding endless loops,
avoiding division by zero, etc.) and "worst case" can be even worse (the
RAM can become unstable, for example), but it's hard to form a cohesive
argument out of these ideas.
Probably, I just shouldn't have said "worst case".
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
From: Christopher C. Stacy
Subject: Re: Haskell: functional languages vs Lisp
Date:
Message-ID: <uy8n8bsbh.fsf@news.dtpq.com>
>>>>> On Mon, 31 May 2004 15:02:55 +0200, Pascal Costanza ("Pascal") writes:
>> There are plenty of operations in Common lisp that yield undefined behavior
>> and some of them would seem to me to be runtime type errors, e.g. the ever
>> popular (let ((l '(1 2 3))) (setf (car l) 3)) were an illegal attempt is made
>> to mutate a constant cons cell. Also I would understand undefined behavior to
>> imply that "further execution of the program" can proceed in a way that is
>> *not* faithful to the language semantics.
The compiler should warn you about those.
······@news.dtpq.com (Christopher C. Stacy) writes:
> >> There are plenty of operations in Common lisp that yield undefined behavior
> >> and some of them would seem to me to be runtime type errors, e.g. the ever
> >> popular (let ((l '(1 2 3))) (setf (car l) 3)) were an illegal attempt is made
> >> to mutate a constant cons cell. Also I would understand undefined behavior to
> >> imply that "further execution of the program" can proceed in a way that is
> >> *not* faithful to the language semantics.
>
> The compiler should warn you about those.
None of the implementations I tried the above with gives a warning.
'as
In article <···············@black132.ex.ac.uk>,
Alexander Schmolck <··········@gmx.net> wrote:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > >> There are plenty of operations in Common lisp that yield undefined behavior
> > >> and some of them would seem to me to be runtime type errors, e.g. the ever
> > >> popular (let ((l '(1 2 3))) (setf (car l) 3)) were an illegal attempt is made
> > >> to mutate a constant cons cell. Also I would understand undefined behavior to
> > >> imply that "further execution of the program" can proceed in a way that is
> > >> *not* faithful to the language semantics.
> >
> > The compiler should warn you about those.
>
> None of the implementations I tried the above with gives a warning.
>
> 'as
I agree. I hate this thing. Some of the optimization that are
possible with CL are creating more harm then it is worth.
#|
I always laugh when I see that it is allowed to reuse constant
data. Example:
(defparameter foo '(1 2 3))
(defparameter bar '(1 2 3))
It is allowed that this list is the same list in compiled code.
Atleast one implementation supports this optimization - still it is
one of the biggest implementations (size of the disk image,
runtime size, ...).
|#
My opinion and request for implementors:
Either let the Lisp system check the errors that are possible due to this
(modifying a constant datastructure) or don't support
it.
For me the number one important thing is heap integrity.
Operations which can damage the heap data structures
should either be detected (and an error should be raised)
or should not be possible in the first place.
Pascal Costanza <········@web.de> writes:
> OK, agreed. You are referring to the operations with "undefined consequences"
> in the Common Lisp spec, and I haven't thought about them.
I agree with the sentiment that in general it is better to have little static
checking and powerful runtime error handling than the other way around (since
the scope of static error checking is by necessitiy quite limited), so I guess
on the whole I'm on your side in this argument :)
I think for arguments concerning program robustness a more interesting
difference than the amount of typechecking being performed at compile time is
that SML apparently rules out corruption of the runtime system, which CL
doesn't (and not just when specific optmization settings are in place).
A simplistic count brings up over 100 mentions of undefined consequences in
the hyperspec:
Hyperspec/Body/> perl -ne '++$count if
/(?:\*undefined[^.].*consequences)|(?:consequences[^.]*undefined)/;
END{print "$count\n"}' *
122
I must say there are quite a few among these that I've always felt a bit
uneasy about. I googled a bit but I couldn't find any good discussion of the
tradeoffs involved for specific cases of undefined consequences in CL.
For example I currently don't fully understand why constant literals that are
unidentifiable as such (or a backquote that is allowed to recycle
substructure) are good to have. I also wonder why FORMAT essentially isn't
required to do any error checking -- getting a possibly rather perlish looking
format string wrong can't be that unlikely.
> My gut reaction would be that any language has a set of rules of thumbs to
> follow so that you don't get into trouble (avoiding endless loops, avoiding
> division by zero, etc.)
..., or in the case of C++: avoiding accessing or modifying unallocated memory
regions and don't leak memory -- which sort of suggests that relying on people
to follow rules of thumbs is only a sane strategy if the rules of thumb are
easily enough adhered to by the target audience (or if the alternatives would
be even worse -- no turing completeness for the above example).
The following might be a good rule of thumb for (high level) language design:
avoid leaving the consequences of operations that are not extremely unlikely
to occur in practice unspecified (and more generally: don't fail silently).
CL certainly is better in this regard than most languages.
'as
Alexander Schmolck wrote:
> For example I currently don't fully understand why constant literals that are
> unidentifiable as such (or a backquote that is allowed to recycle
> substructure) are good to have.
I guess these are concessions from a time in which people thought it's a
good idea to compete with C.
> I also wonder why FORMAT essentially isn't
> required to do any error checking -- getting a possibly rather perlish looking
> format string wrong can't be that unlikely.
Again, making this a requirement would incur some costs, at runtime in
the general case.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza <········@web.de> writes:
> Alexander Schmolck wrote:
>
>> For example I currently don't fully understand why constant literals that are
>> unidentifiable as such (or a backquote that is allowed to recycle
>> substructure) are good to have.
>
> I guess these are concessions from a time in which people thought it's a good
> idea to compete with C.
Even if it is a design flaw I would be quite interested to learn a bit more
about what the perceived benefits for e.g. backquotes sharing behavior were
and what to what extent these benefits currently still apply. Maybe one of the
implementors can shed some light on this?
>> I also wonder why FORMAT essentially isn't required to do any error
>> checking -- getting a possibly rather perlish looking format string wrong
>> can't be that unlikely.
>
> Again, making this a requirement would incur some costs, at runtime in the
> general case.
What is puzzling me is that here the runtime costs of checking many of the
things that currently have undefined consequences here would appear to be
marginal (for example misplaced : or @ signs) and in principle zero in most
common cases since were they could be statically verified.
'as
Alexander Schmolck <··········@gmx.net> wrote in message news:<···············@black132.ex.ac.uk>...
> Pascal Costanza <········@web.de> writes:
>
> > In Common Lisp, runtime type errors also don't "sink your ship". The worst
> > that can happen is that an exception handler is invoked, and there is a good
> > chance that you may be able to correct the situation which led to the error
> > and then move on.
>
> Nope -- the worst that can happen is that you did something with undefined
> consequences and your system *silently* starts behaving in an unpredictable
> fashion. According to Appel[*] SML programs are safe in the respect that they
> "cannot corrupt the runtime system so that further execution of the program is
> not faithful to the language semantics".
In the real world, you have to call unsafe code through
machine-language interfaces.
Though some occurences of undefined behavior in standard programming
languages are unfortunate, many are justifiable, and some are
essential so that useful extensions can be provided.
A perfectly safe language that doesn't allow anything bad to happen
would have to be free of any escape hatches. Or else it would have
contain an entire platform so that anything imaginable that an
application might want to do would find expression in some defined
language feature. Make a bug-free implementation of that, and you have
perfect safety.
···@ashi.footprints.net (Kaz Kylheku) writes:
> In the real world, you have to call unsafe code through
> machine-language interfaces.
>
> Though some occurences of undefined behavior in standard programming
> languages are unfortunate, many are justifiable, and some are
> essential so that useful extensions can be provided.
I am not disputing that -- this is obviously mostly a question of where, howto
and when to trade off safety for other desiderata and not *if*.
As I'm fairly clueless about implementation issues, I'd be, as I said, quite
interested to learn more about such motivations, say concerning constness of
literals or the permissibleness of sharing in backquote or functions such as
set-difference (and since I'd also imagine that many such trade offs can shift
substantially over time, the historical perspective might in some cases also
be quite helpful).
The design tradeoffs for some features are best appreciated by simply
experimenting with them, but this obviously doesn't hold for undefined
behavior. Currently the only reason I use quote or backquote over list is for
convinience, not because of efficiency or other considerations and I'd like to
know whether there is something more I should be aware of (or whether the
undefined consequences of modifying quoted or backquoted lists are largely
historical artifacts).
'as
[1]
From: Matthias Buelow
Subject: Re: Haskell: functional languages vs Lisp
Date:
Message-ID: <2hsggcFh33ruU1@uni-berlin.de>
Pascal Costanza wrote:
> In Common Lisp, runtime type errors also don't "sink your ship". The
> worst that can happen is that an exception handler is invoked, and there
> is a good chance that you may be able to correct the situation which led
> to the error and then move on. (Exception handlers in Common Lisp don't
> wind up the stack by default, so it's possible to return something
> useful from it, for example, or invoke some restart that redirects the
> control flow to a well-defined entry point.)
Well.. in production use it doesn't matter much if the program is
hanging in the debugger's REPL, or if it just wrote out a corefile and
exited.
> Runtime type errors don't cause frequent problems, and of course it's
> possible to add static type checking to Common Lisp, at least to a
> certain degree.
"To a certain degree"? How's that supposed to work? Either you have
static typechecking, or you don't.
--
Matthias Buelow; ···@{mukappabeta,informatik.uni-wuerzburg}.de
Matthias Buelow <···@mukappabeta.de> writes:
> Pascal Costanza wrote:
>
> > In Common Lisp, runtime type errors also don't "sink your ship". The
> > worst that can happen is that an exception handler is invoked, and there
> > is a good chance that you may be able to correct the situation which led
> > to the error and then move on. (Exception handlers in Common Lisp don't
> > wind up the stack by default, so it's possible to return something
> > useful from it, for example, or invoke some restart that redirects the
> > control flow to a well-defined entry point.)
>
> Well.. in production use it doesn't matter much if the program is
> hanging in the debugger's REPL, or if it just wrote out a corefile and
> exited.
That's why you setup /handlers/, like Pascal said. In production
code, you should probably set *DEBUGGER-HOOK*, too. You don't ever
end up with a server hung in the debugger, as anyone who's done real
work in Lisp knows.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Matthias Buelow
Subject: Re: Haskell: functional languages vs Lisp
Date:
Message-ID: <2huv8rFh3jamU1@uni-berlin.de>
Thomas F. Burdick wrote:
> That's why you setup /handlers/, like Pascal said. In production
> code, you should probably set *DEBUGGER-HOOK*, too. You don't ever
> end up with a server hung in the debugger, as anyone who's done real
> work in Lisp knows.
This only serves to not to expose the customer to an embarrassing
debugger prompt but it doesn't solve the problem of mismatched types
that could've been caught at compile time and hence the error would
never have occurred at the customer's site in the first place.
--
Matthias Buelow; ···@{mukappabeta,informatik.uni-wuerzburg}.de
On Sun, 30 May 2004, Matthias Buelow wrote:
> Thomas F. Burdick wrote:
>
> > That's why you setup /handlers/, like Pascal said. In production
> > code, you should probably set *DEBUGGER-HOOK*, too. You don't ever
> > end up with a server hung in the debugger, as anyone who's done real
> > work in Lisp knows.
>
> This only serves to not to expose the customer to an embarrassing
> debugger prompt but it doesn't solve the problem of mismatched types
> that could've been caught at compile time and hence the error would
> never have occurred at the customer's site in the first place.
You're purposefully restricting the set of "type errors" to be "errors
that a H-M static type analysis can find". When you write a program, in
any language, you are creating an extension of the main programming
language in which you solve problems. You may handle data for which the
system types are not sufficiently narrow. But any time you "check" data
for admissibility into these app-specific types, that is a run-time type
check. And any time you neglect to check, you introduce the possibility
of undefined behavior into the semantics of the extension. But because of
the blind attitude towards such errors ("it can't happen"), there does not
exist in a typical functional language implementation a very good way
to handle and fix these problems on the fly. Whereas Common Lisp has
evolved a number of mechanisms for doing exactly this; for type errors but
more often for other kinds of errors.
From: Matthias Buelow
Subject: Re: Haskell: functional languages vs Lisp
Date:
Message-ID: <2hv4qhFh5bd7U1@uni-berlin.de>
Matthew Danish wrote:
> You're purposefully restricting the set of "type errors" to be "errors
> that a H-M static type analysis can find". When you write a program, in
> any language, you are creating an extension of the main programming
> language in which you solve problems. You may handle data for which the
> system types are not sufficiently narrow. But any time you "check" data
> for admissibility into these app-specific types, that is a run-time type
> check. And any time you neglect to check, you introduce the possibility
I don't know if I quite understand this. When, for example, in Standard
ML, you construct new types by "datatype" and type constructors[1],
surely the type verification is done at compile time? And you can
specify them as finely grained as you want them. Or do you rather mean
things like, in C, casting an int into a (void *) since the function
only accepts the latter as a kind of "generic" type (as is the case for
example in some GUI APIs for widget callbacks) and where you might have
to manually check with some extra mechanism what argument was actually
passed?
> of undefined behavior into the semantics of the extension. But because of
> the blind attitude towards such errors ("it can't happen"), there does not
> exist in a typical functional language implementation a very good way
> to handle and fix these problems on the fly. Whereas Common Lisp has
I think the main reason is that typical functional languages (and
implementations) are more geared towards the academic user base, and
don't have several decades of hard-earned experience "in the field" yet.
--
Matthias Buelow; ···@{mukappabeta,informatik.uni-wuerzburg}.de
[1] Creating new types, instead of just abbreviations for existing ones.
From: Joe Marshall
Subject: Re: Haskell: functional languages vs Lisp
Date:
Message-ID: <wu2slefn.fsf@comcast.net>
Matthias Buelow <···@mukappabeta.de> writes:
> I don't know if I quite understand this. When, for example, in
> Standard ML, you construct new types by "datatype" and type
> constructors[1], surely the type verification is done at compile time?
A number of verifications are done at compile time, and the
verifications surrounding the new datatypes and constructors are done
at compile time, but there are other verifications that many people
would call `type errors' that are not done at compile time. (Excuse
the `lawyer language' but it is necessary when arguing about `types'.)
> And you can specify them as finely grained as you want them.
The type language of Standard ML does not admit all possible types.
--
~jrm
Matthias Buelow <···@mukappabeta.de> writes:
> Thomas F. Burdick wrote:
>
> > That's why you setup /handlers/, like Pascal said. In production
> > code, you should probably set *DEBUGGER-HOOK*, too. You don't ever
> > end up with a server hung in the debugger, as anyone who's done real
> > work in Lisp knows.
>
> This only serves to not to expose the customer to an embarrassing
> debugger prompt but it doesn't solve the problem of mismatched types
> that could've been caught at compile time and hence the error would
> never have occurred at the customer's site in the first place.
In practice, this potential problem with dynamic typing is not a major
issue. I speak from industrial experience in a sector with demanding
customers.
Have the claimed benefits of moving from dynamic to static
(prescriptive) typing been quantified, by the way? I would be
particularly interested in industrial experiences. Are there any
references? If so, what were the numbers?
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
Matthias Buelow <···@mukappabeta.de> writes:
> Well.. in production use it doesn't matter much if the program is
> hanging in the debugger's REPL, or if it just wrote out a corefile
> and exited.
This is where continuations come into play. Or even conceivably some
application-specific "debugger" that is presentable to users.
> "To a certain degree"? How's that supposed to work? Either you
> have static typechecking, or you don't.
Common Lisp already has static type-checking, as every value is of
type t. Now, from this starting-point you can add more specific
type-information, to various degrees.
--
Frode Vatvedt Fjeld
From: Matthias Buelow
Subject: Re: Haskell: functional languages vs Lisp
Date:
Message-ID: <2hsn14FfehtrU1@uni-berlin.de>
Frode Vatvedt Fjeld wrote:
> Common Lisp already has static type-checking, as every value is of
> type t. Now, from this starting-point you can add more specific
> type-information, to various degrees.
Then the compiler warns, but only if you add wrong types, not if you
(perhaps accidentally) omit type declarations [since it doesn't infer
types and do a complete check]. Hence it isn't something to rely on if
you want to minimize the risk of runtime type errors.
Of course dynamicity through runtime typing and static compile-time type
safety are rather diametrical concepts; it would however be the next Big
Thing if the two concepts could somehow be integrated in a practical way.
--
Matthias Buelow; ···@{mukappabeta,informatik.uni-wuerzburg}.de
Matthias Buelow <···@mukappabeta.de> wrote:
> Then the compiler warns, but only if you add wrong types, not if you
> (perhaps accidentally) omit type declarations [since it doesn't infer
> types and do a complete check].
0) This subject has been hashed over before, and has proved quite
unfruitful to all participants: no agreeing to disagree, just
silly "yes! no! yes! no! my compiler/language is bigger then yours!
yes! no!".
1) Inference is not required, but several systems *do* do it. For
more information peruse the SBCL and CMUCL manuals, for example.
I still think this whole thread smell like a troll. Does it walk like a
troll too?
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
Matthias Buelow wrote:
> Frode Vatvedt Fjeld wrote:
>
>> Common Lisp already has static type-checking, as every value is of
>> type t. Now, from this starting-point you can add more specific
>> type-information, to various degrees.
>
> Then the compiler warns, but only if you add wrong types, not if you
> (perhaps accidentally) omit type declarations [since it doesn't infer
> types and do a complete check]. Hence it isn't something to rely on if
> you want to minimize the risk of runtime type errors.
> Of course dynamicity through runtime typing and static compile-time type
> safety are rather diametrical concepts; it would however be the next Big
> Thing if the two concepts could somehow be integrated in a practical way.
Yes, I agree. But this will only work when static typers start to
understand that type errors aren't necessarily bugs.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Matthias Buelow wrote:
> Pascal Costanza wrote:
>
>> In Common Lisp, runtime type errors also don't "sink your ship". The
>> worst that can happen is that an exception handler is invoked, and
>> there is a good chance that you may be able to correct the situation
>> which led to the error and then move on. (Exception handlers in Common
>> Lisp don't wind up the stack by default, so it's possible to return
>> something useful from it, for example, or invoke some restart that
>> redirects the control flow to a well-defined entry point.)
>
> Well.. in production use it doesn't matter much if the program is
> hanging in the debugger's REPL, or if it just wrote out a corefile and
> exited.
This depends on the deployment scenario.
>> Runtime type errors don't cause frequent problems, and of course it's
>> possible to add static type checking to Common Lisp, at least to a
>> certain degree.
>
> "To a certain degree"? How's that supposed to work? Either you have
> static typechecking, or you don't.
Do you think there is a difference between the static type systems of
Java and Haskell?
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
From: Matthias Buelow
Subject: Re: Haskell: functional languages vs Lisp
Date:
Message-ID: <2hsu0kFgmbs7U1@uni-berlin.de>
Pascal Costanza wrote:
> Do you think there is a difference between the static type systems of
> Java and Haskell?
I don't think there is, pertaining to the deferral of type checking
until runtime. There's some "accidental" runtime typing in Standard ML
in some rather rare special cases, don't know about Haskell. And I've
heard that "dynamism things" where about to be added to Java, although
I'm not up to date there.
--
Matthias Buelow; ···@{mukappabeta,informatik.uni-wuerzburg}.de
Matthias Buelow wrote:
>> Runtime type errors don't cause frequent problems, and of course it's
>> possible to add static type checking to Common Lisp, at least to a
>> certain degree.
>
>
> "To a certain degree"? How's that supposed to work? Either you have
> static typechecking, or you don't.
Check CMUCL. Also, either you have a dynamic language environment with
data and code equivalence or you don't. How do you expect to have that
in Haskell? Or Ocaml, or any of the admittedly nice "type-inferenced"
languages?
Cheers
--
Marco
From: Julian Stecklina
Subject: Re: Haskell: functional languages vs Lisp
Date:
Message-ID: <86wu2sqznh.fsf@web.de>
Matthias Buelow <···@mukappabeta.de> writes:
> Pascal Costanza wrote:
>
>> In Common Lisp, runtime type errors also don't "sink your ship". The
>> worst that can happen is that an exception handler is invoked, and
>> there is a good chance that you may be able to correct the situation
>> which led to the error and then move on. (Exception handlers in
>> Common Lisp don't wind up the stack by default, so it's possible to
>> return something useful from it, for example, or invoke some restart
>> that redirects the control flow to a well-defined entry point.)
>
> Well.. in production use it doesn't matter much if the program is
> hanging in the debugger's REPL, or if it just wrote out a corefile and
> exited.
But imagine a server, that has a bug in a hardly tested routine that
is only triggered by some quite unlikely action of the client. Even if
a client triggers this there is a good chance that the server still
can quit this connection gracefully and continue serving others.
Regards,
--
Julian Stecklina
Signed and encrypted mail welcome.
Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5
FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5
Any sufficiently complicated C or Fortran program
contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
- Greenspun's Tenth Rule of Programming
On 8758 day of my life Nelson Marcelino wrote:
> I am curious to know what advantages does Lisp have over Haskell. As
> far as I know the Haskell Prelude as well as its modules implement
> most of the functionality that lisp provides but with a much cleaner
> and succinct syntax.
> Furthermore, Paul Hudak claims that lisp is not based on lambda
> calculus (as many people think) and is not a true functional language;
> therefore in some instance this can make formal verification of lisp
> programs difficult.
You can create embedded languages with Lisp. For example, TypeL
<http://www.cliki.net/TypeL/> is typed sublanguage of Common Lisp.
Search Google Groups for TypeL announce with examples (March 27).
Type inference implemented in Haskell, O'Caml and TypeL is kind of
formal verifictaion, isn't it?
> I am aware that lisp has many great features such as multiple
> programming paradigms, that it is extensible, adaptable, and that it
> takes a pragmatic view to many things. However providing multiple
> ways to accomplish something such as providing 20 different ways to
> do looping seems very confusing. Why not have just one or two
> standard looping methods to accomplish something?
He-he-he, google for "The Evolution of a Haskell Programmer" :)))
--
Ivan Boldyrev
| recursion, n:
| See recursion
·········@yahoo.com (Nelson Marcelino) wrote in message news:<····························@posting.google.com>...
> Also functional programming contests held each year allow any language
> to compete. And it always seems that languages such as OCAML, Haskell,
> Dylan etc alls fare well where other languages such as Lisp never make
> it to the semifinals.
I just realized I dislike that ICFP contest for subordinating the
programmer to the language.
But designers of "pure" languages think in those terms. If the
language enforced pure enough thoughts, and stood in judgement with
the thumb ready to say Yea or Nay over the programmer's work, then
human incompetence can be eradicated.
There were many times when people would've been dictators and gotten
rid of something "unlispish" like loop, keyword arguments, function
namespace... Who knows what temporary dictators did succeed in
removing, and whether they were right or wrong in doing so.
Hmm, I realized my post came across as scathing rather than the random
interested musing I intended. I retract it.
Obviously pure languages have their place, and contribute to the world
of programming. And the ICFP is fine marketing, though I wish it
didn't make people think tools decide to compete, rather than humans.
-- Tayssir
···········@yahoo.com (Tayssir John Gabbour) wrote in message news:<····························@posting.google.com>...
> ·········@yahoo.com (Nelson Marcelino) wrote in message news:<····························@posting.google.com>...
> > Also functional programming contests held each year allow any language
> > to compete. And it always seems that languages such as OCAML, Haskell,
> > Dylan etc alls fare well where other languages such as Lisp never make
> > it to the semifinals.
>
> I just realized I dislike that ICFP contest for subordinating the
> programmer to the language.
>
> But designers of "pure" languages think in those terms. If the
> language enforced pure enough thoughts, and stood in judgement with
> the thumb ready to say Yea or Nay over the programmer's work, then
> human incompetence can be eradicated.
>
> There were many times when people would've been dictators and gotten
> rid of something "unlispish" like loop, keyword arguments, function
> namespace... Who knows what temporary dictators did succeed in
> removing, and whether they were right or wrong in doing so.
Tayssir John Gabbour wrote:
>
> I just realized I dislike that ICFP contest for subordinating the
> programmer to the language.
At least they don't force you to use Java or C++.
Best regards,
Tom
--
.signature: Too many levels of symbolic links
·········@yahoo.com (Nelson Marcelino) writes:
> Also functional programming contests held each year allow any
> language to compete. And it always seems that languages such as
> OCAML, Haskell, Dylan etc alls fare well where other languages such
> as Lisp never make it to the semifinals.
Didn't a C++ entry win last year? Just a pointer to where the wind
is blowing.
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
On 8761 day of my life Thomas Lindgren wrote:
> ·········@yahoo.com (Nelson Marcelino) writes:
>
> Didn't a C++ entry win last year? Just a pointer to where the wind
> is blowing.
It was man with computation cluster who won last time, and C++ was
used with that cluster just by incident. It is not so difficult to
implement brute-force algorithm. So, cluster won, not C++.
--
Ivan Boldyrev
Sorry my terrible English, my native language is Lisp!
Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
> On 8761 day of my life Thomas Lindgren wrote:
> > ·········@yahoo.com (Nelson Marcelino) writes:
> >
> > Didn't a C++ entry win last year? Just a pointer to where the wind
> > is blowing.
>
> It was man with computation cluster who won last time, and C++ was
> used with that cluster just by incident. It is not so difficult to
> implement brute-force algorithm. So, cluster won, not C++.
Hence, C++ also turned out to be well suited for exploiting a 16-way
cluster during rapid development. That doesn't seem like a bad
thing. If I'm reading the table correctly, C++ furthermore took not
only 1st, but also 2nd and 4th place in 2003.
<http://www.dtek.chalmers.se/groups/icfpcontest/results.html>
The previous poster, who thought position in the ICFP contest highly
significant (in particular, Lisp's lack thereof), should thus seriously
consider C++.
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
Just to be the devil's advocate.....
I think the ICFP context is not a very good metric (as most
"benchmarking" metrics) to measure the goodness of a programming
language. I also think that the organizers know that as well :)
Last I checked, the winners usually take advantage not of the language
features per se, but of (1) algorithmic insight and (2) parallelism.
This is not surprising, as it is not surprising that Common Lisp entries
are sparse and very average in performance.
Cheers
marco
Thomas Lindgren wrote:
> Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
>
>
>>On 8761 day of my life Thomas Lindgren wrote:
>>
>>>·········@yahoo.com (Nelson Marcelino) writes:
>>>
>>>Didn't a C++ entry win last year? Just a pointer to where the wind
>>>is blowing.
>>
>>It was man with computation cluster who won last time, and C++ was
>>used with that cluster just by incident. It is not so difficult to
>>implement brute-force algorithm. So, cluster won, not C++.
>
>
> Hence, C++ also turned out to be well suited for exploiting a 16-way
> cluster during rapid development. That doesn't seem like a bad
> thing. If I'm reading the table correctly, C++ furthermore took not
> only 1st, but also 2nd and 4th place in 2003.
>
> <http://www.dtek.chalmers.se/groups/icfpcontest/results.html>
>
> The previous poster, who thought position in the ICFP contest highly
> significant (in particular, Lisp's lack thereof), should thus seriously
> consider C++.
>
> Best,
> Thomas
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Just to be the devil's advocate.....
>
> I think the ICFP context is not a very good metric (as most
> "benchmarking" metrics) to measure the goodness of a programming
> language. I also think that the organizers know that as well :)
>
> Last I checked, the winners usually take advantage not of the language
> features per se, but of (1) algorithmic insight and (2) parallelism.
>
> This is not surprising, as it is not surprising that Common Lisp
> entries are sparse and very average in performance.
Quite so.
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
From: Julian Stecklina
Subject: Re: Haskell: functional languages vs Lisp
Date:
Message-ID: <86vfi9sh7u.fsf@web.de>
Thomas Lindgren <···········@*****.***> writes:
> Hence, C++ also turned out to be well suited for exploiting a 16-way
> cluster during rapid development. That doesn't seem like a bad
> thing. If I'm reading the table correctly, C++ furthermore took not
> only 1st, but also 2nd and 4th place in 2003.
>
> <http://www.dtek.chalmers.se/groups/icfpcontest/results.html>
http://www.dtek.chalmers.se/groups/icfpcontest/proclamation.html
I am offended. :)
Regards,
--
Julian Stecklina
Signed and encrypted mail welcome.
Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5
FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5
Any sufficiently complicated C or Fortran program
contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
- Greenspun's Tenth Rule of Programming
Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
> On 8761 day of my life Thomas Lindgren wrote:
>> ·········@yahoo.com (Nelson Marcelino) writes:
>>
>> Didn't a C++ entry win last year? Just a pointer to where the wind
>> is blowing.
>
> It was man with computation cluster who won last time, and C++ was
> used with that cluster just by incident. It is not so difficult to
> implement brute-force algorithm. So, cluster won, not C++.
IIRC, the guy also used a superior algorithm.
On 28 May 2004 06:30:42 -0700, ·········@yahoo.com (Nelson Marcelino) wrote:
> Also functional programming contests held each year allow any
> language to compete. And it always seems that languages such as
> OCAML, Haskell, Dylan etc alls fare well where other languages such
> as Lisp never make it to the semifinals.
You obviously have no idea what Dylan is...
From: Joe Marshall
Subject: Re: Haskell: functional languages vs Lisp
Date:
Message-ID: <u0xvbea8.fsf@ccs.neu.edu>
·········@yahoo.com (Nelson Marcelino) writes:
> I am curious to know what advantages does Lisp have over Haskell.
None whatsoever.
> Also functional programming contests held each year allow any
> language to compete. And it always seems that languages such as
> OCAML, Haskell, Dylan etc. all fare well where other languages such
> as Lisp never make it to the semifinals.
A good part of the reason is that good Lisp hackers have *work* to do.
> Paul Graham says he is creating a new language called
> Arc. Apparently there are some things about lisp that he does not
> like. But I don't think Graham knows about some of the newer
> functional languages.
I don't think that. Paul is a clever guy and I've seen him in
attendance at programming language conferences. I suppose he could be
completely ignoring the speakers.
From: Julian Stecklina
Subject: Re: Haskell: functional languages vs Lisp
Date:
Message-ID: <86r7sxsh1a.fsf@web.de>
Joe Marshall <···@ccs.neu.edu> writes:
> ·········@yahoo.com (Nelson Marcelino) writes:
>
>> I am curious to know what advantages does Lisp have over Haskell.
>
> None whatsoever.
What about the ability to implement haskell features when we need to?
'Why?' you ask? Because we can... (and already have)
[...]
> A good part of the reason is that good Lisp hackers have *work* to do.
There are probably as many paid jobs to program CL as to hack haskell.
Regards,
--
Julian Stecklina
Signed and encrypted mail welcome.
Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5
FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5
Any sufficiently complicated C or Fortran program
contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
- Greenspun's Tenth Rule of Programming
From: Joe Marshall
Subject: Re: Haskell: functional languages vs Lisp
Date:
Message-ID: <7jupjs41.fsf@comcast.net>
Julian Stecklina <··········@web.de> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>> ·········@yahoo.com (Nelson Marcelino) writes:
>>
>>> I am curious to know what advantages does Lisp have over Haskell.
>>
>> None whatsoever.
>
> What about the ability to implement haskell features when we need to?
> 'Why?' you ask? Because we can... (and already have)
I get tired of the `why should I use lisp when xxxx does what I
want' trolls. I wanted to try out a different answer.
--
~jrm
·········@yahoo.com (Nelson Marcelino) wrote in message news:<····························@posting.google.com>...
> Furthermore, Paul Hudak claims that lisp is not based on
> lambda calculus (as many people think) and is not a true
> functional language; therefore in some instance this can
> make formal verification of lisp programs difficult.
Which, I'm sure, is a burning issue to a few eggheads
in comp.sci departments.
> I would like to know what people think of newer
> languages such as Lisp OCAML SML
OCaml is explicitly an experimental
language.
I used OCaml for a little while.
Initially I was intruiged, especially
due to good performance of the compiler.
But after using it to write a few
simulations, my initial jubilation
wore off rather sharply, and I learned
that OCaml programming was about as much
fun as wearing a wet straight-jacket.
The whole ML family imparted the same
dreary impression.