What do you LISPers think of Haskell?

In article
<2955ea47-3703-4fa3-9940-9a3baa8210a8@k13g2000hse.googlegroups.com>,
Vend <vend82@virgilio.it> wrote:

> On 20 Ago, 02:07, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
> > DeverLite <derby.lit...@gmail.com> writes:
> > > [...] Although very flexible, and good at catching errors at compile
> > > time, I found the typing system in Haskell sometimes got in the way.
> > > Lisp let's you declare types, but if you don't want to you don't have
> > > to, and this tends to make it more flexible than Haskell.
> >
> > Actually, what the lisp type system means is that in lisp we program
> > in generic mode by default.
> >
> > When you write:
> >
> > int fact(int x){ return (x<=0)?1:x*fact(x-1); }
> >
> > it's statically typed, but it's also SPECIFICALLY typed.
> >
> > When you write in lisp:
> >
> > (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
> >
> > it's already a generic function (not a lisp generic function,
> > technically, but what other programming languages call a generic
> > function):
> >
> > (mapcar 'fact '(4 4.0 4.0l0 5/2))
> > --> (24 24.0 24.0L0 15/8)
>
> But the mathematical factorial function is defined only on natural
> numbers, hence this behavior is most likely incorrect.
>
> Moreover, in dynamically typed languages like Lisp there is the risk
> of having a statement like this buried deep in your program:
>
> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> ctrl-alt-shift-tab-right-mouse-button))
> (setq bomb "goodbye")
> (setq bomb 42))
>
> And then somewhere else a (fact bomb) makes your program crash and
> your client angry.

The Lisp program will not crash. It will display an error,
dump an error report or send mail. The parts of the Lisp
program that don't have the bug will continue to run just fine.

If you want you can make the program send an error
report and a backtrace to the developer. He can send
a fix back, the client can load it and continue
to work without ever leaving his program.
It is quite fascinating to see how clients react to incremental
fixes that can be loaded - instead of waiting for a complete
new build or bug fix release of the complete software.
You can often see Lisp vendors shipping releases and then for
years only giving small patches to the customers. Often the
patches can be loaded into a running system.

For example the Lisp based server I'm using does not crash
every other day. I update the software from time to time
mostly while the server runs. When there is some problem
the server sends a mail with the error condition and
a backtrace. I log into the machine, connect to the
running software and fix the problem while it is running.

Actually problems are much better to debug, since all the
data and the software information (typed self-identifying objects,
documentation, etc.) is still there.

Lisp has been perfected over the years to support exactly this:
handling errors safely at runtime. In the last years
64bit Lisp systems have been used with very large datasets.
Crashing is no option. Handling errors is.

>
> > to get the same in C++ you would have to write:
> >
> > #include <rational.hxx>
> > template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
> >
> > ... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...
> >
> > I hope Haskell is able to derive these instances automatically.
>
> Why do you hope so, given that this behavior is likely to be
> incorrect?
>
> Anyway, Haskell infers a generic type if you don't provide type
> declarations, but it's generally considered a good programming
> practice to provide type declarations precisely to avoid such kind of
> behaviors.
>
> > But you can easily get even more genericity, either using non CL
> > operators that you can easily redefine (eg. as lisp generic
> > functions), by shadowing them to the same effect, or by using
> > functions passed in argument. CL:SORT is generic because it takes a
> > LESSP function, so it can be applied on sequences of any kind of
> > object.
> >
> > So what statically checked type system proponents detract as duck
> > typing is actually that lisp works in the Generic Mode gears by
> > default.
>
> I'm not sure about Common Lisp, but in Scheme, while arithmetic
> operators are overloaded, most library function aren't (there are
> different procedures for doing the same operation on lists, vectors,
> strings and streams, for instance), hence I wouldn't consider the
> language particularly generically typed.

Common Lisp has lots of limited generic functions. For example
there are operations that work on sequences. Sequences are
for example vectors and lists.

Common Lisp also has CLOS, the Common Lisp Object System,
where 'generic functions' are a basic building block.

>
> > --
> > __Pascal Bourguignon__ http://www.informatimago.com/
> > I need a new toy.
> > Tail of black dog keeps good time.
> > Pounce! Good dog! Good dog!

--
http://lispm.dyndns.org/

On 28 Ago, 20:38, Rainer Joswig <jos...@lisp.de> wrote:
> In article
> <2955ea47-3703-4fa3-9940-9a3baa821...@k13g2000hse.googlegroups.com>,
>
>
>
> *Vend <ven...@virgilio.it> wrote:
> > On 20 Ago, 02:07, p...@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> > > DeverLite <derby.lit...@gmail.com> writes:
> > > > [...] Although very flexible, and good at catching errors at compile
> > > > time, I found the typing system in Haskell sometimes got in the way..
> > > > Lisp let's you declare types, but if you don't want to you don't have
> > > > to, and this tends to make it more flexible than Haskell.
>
> > > Actually, what the lisp type system means is that in lisp we program
> > > in generic mode by default.
>
> > > When you write:
>
> > > * *int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> > > it's statically typed, but it's also SPECIFICALLY typed.
>
> > > When you write in lisp:
>
> > > * *(defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> > > it's already a generic function (not a lisp generic function,
> > > technically, but what other programming languages call a generic
> > > function):
>
> > > * *(mapcar 'fact '(4 4.0 4.0l0 5/2))
> > > * * --> (24 24.0 24.0L0 15/8)
>
> > But the mathematical factorial function is defined only on natural
> > numbers, hence this behavior is most likely incorrect.
>
> > Moreover, in dynamically typed languages like Lisp there is the risk
> > of having a statement like this buried deep in your program:
>
> > (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> > ctrl-alt-shift-tab-right-mouse-button))
> > * (setq bomb "goodbye")
> > * (setq bomb 42))
>
> > And then somewhere else a (fact bomb) makes your program crash and
> > your client angry.
>
> The Lisp program will not crash. It will display an error,
> dump an error report or send mail. The parts of the Lisp
> program that don't have the bug will continue to run just fine.

The program will not crash with a segfault like C/C++ programs do, but
usually it will still terminate abruptly giving an error message which
is probably unintellegible to the user.

Even if you design your programs to catch the error, send a bug report
and try to keep running, probably there will be some loss of
functionality.

Which, in the specific case under discussion, wouldn't happen in a
statically typed language.

> If you want you can make the program send an error
> report and a backtrace to the developer. He can send
> a fix back, the client can load it and continue
> to work without ever leaving his program.
> It is quite fascinating to see how clients react to incremental
> fixes that can be loaded - instead of waiting for a complete
> new build or bug fix release of the complete software.
> You can often see Lisp vendors shipping releases and then for
> years only giving small patches to the customers. Often the
> patches can be loaded into a running system.
>
> For example the Lisp based server I'm using does not crash
> every other day. I update the software from time to time
> mostly while the server runs. When there is some problem
> the server sends a mail with the error condition and
> a backtrace. I log into the machine, connect to the
> running software and fix the problem while it is running.
>
> Actually problems are much better to debug, since all the
> data and the software information (typed self-identifying objects,
> documentation, etc.) is still there.
>
> Lisp has been perfected over the years to support exactly this:
> handling errors safely at runtime. In the last years
> 64bit Lisp systems have been used with very large datasets.
> Crashing is no option. Handling errors is.
>
>
>
>
>
> > > to get the same in C++ you would have to write:
>
> > > * #include <rational.hxx>
> > > * template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
>
> > > * ... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...
>
> > > I hope Haskell is able to derive these instances automatically.
>
> > Why do you hope so, given that this behavior is likely to be
> > incorrect?
>
> > Anyway, Haskell infers a generic type if you don't provide type
> > declarations, but it's generally considered a good programming
> > practice to provide type declarations precisely to avoid such kind of
> > behaviors.
>
> > > But you can easily get even more genericity, either using non CL
> > > operators that you can easily redefine (eg. as lisp generic
> > > functions), by shadowing them to the same effect, or by using
> > > functions passed in argument. *CL:SORT is generic because it takes a
> > > LESSP function, so it can be applied on sequences of any kind of
> > > object.
>
> > > So what statically checked type system proponents detract as duck
> > > typing is actually that lisp works in the Generic Mode gears by
> > > default.
>
> > I'm not sure about Common Lisp, but in Scheme, while arithmetic
> > operators are overloaded, most library function aren't (there are
> > different procedures for doing the same operation on lists, vectors,
> > strings and streams, for instance), hence I wouldn't consider the
> > language particularly generically typed.
>
> Common Lisp has lots of limited generic functions. For example
> there are operations that work on sequences. Sequences are
> for example vectors and lists.
>
> Common Lisp also has CLOS, the Common Lisp Object System,
> where 'generic functions' are a basic building block.
>
>
>
> > > --
> > > __Pascal Bourguignon__ * * * * * * * * * *http://www.informatimago.com/
> > > I need a new toy.
> > > Tail of black dog keeps good time.
> > > Pounce! Good dog! Good dog!
>
> --http://lispm.dyndns.org/

parnell wrote:
>> Had your previous assertion been true then I would agree but I cannot see
>> that this is the case. The "installed" data that I analyzed does not
>> trend with the "vote" data and does not correlate with the fluctuations
>> in the "recent" and "old" data. So this source of error did not affect my
>> analysis.
>
> http://people.debian.org/~igloo/popc...?packages=unis.
%2Cdarcs&show_installed=on&show_vote=on&want_legen d=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>
>
> The voted category and the installed do not show the wild fluctuations
> of the recent or old categories. When you count the installed category you
> are counting installs of software that is never used, completely
> invalidating your analysis.

The proportion of unused installs of OCaml software would have to be an
order of magnitude higher than for Haskell software to account for the
observed discrepancy. That is clearly not realistic but let's quantify it
nonetheless.

The proportion of "vote" to "install" for the various packages is currently:

libfftw3-3 9.6%
unison-gtk 15.8%
mldonkey-gui 15.8%
darcs 11.7%
freetennis 6.6%
planets 5.3%
hpodder 8.4%
ledit 9.1%
hevea 7.5%
polygen 6.7%

As you can see, there is no evidence of any discrepancy at all, let alone
the order of magnitude discrepancy required to justify your assumption.

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

In article
<2042a77a-6205-46f9-88b4-e5daea907489@l42g2000hsc.googlegroups.com>,
Vend <vend82@virgilio.it> wrote:

> On 28 Ago, 20:38, Rainer Joswig <jos...@lisp.de> wrote:
> > In article
> > <2955ea47-3703-4fa3-9940-9a3baa821...@k13g2000hse.googlegroups.com>,
> >
> >
> >
> > *Vend <ven...@virgilio.it> wrote:
> > > On 20 Ago, 02:07, p...@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
> > > > DeverLite <derby.lit...@gmail.com> writes:
> > > > > [...] Although very flexible, and good at catching errors at compile
> > > > > time, I found the typing system in Haskell sometimes got in the way.
> > > > > Lisp let's you declare types, but if you don't want to you don't have
> > > > > to, and this tends to make it more flexible than Haskell.
> >
> > > > Actually, what the lisp type system means is that in lisp we program
> > > > in generic mode by default.
> >
> > > > When you write:
> >
> > > > * *int fact(int x){ return (x<=0)?1:x*fact(x-1); }
> >
> > > > it's statically typed, but it's also SPECIFICALLY typed.
> >
> > > > When you write in lisp:
> >
> > > > * *(defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
> >
> > > > it's already a generic function (not a lisp generic function,
> > > > technically, but what other programming languages call a generic
> > > > function):
> >
> > > > * *(mapcar 'fact '(4 4.0 4.0l0 5/2))
> > > > * * --> (24 24.0 24.0L0 15/8)
> >
> > > But the mathematical factorial function is defined only on natural
> > > numbers, hence this behavior is most likely incorrect.
> >
> > > Moreover, in dynamically typed languages like Lisp there is the risk
> > > of having a statement like this buried deep in your program:
> >
> > > (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> > > ctrl-alt-shift-tab-right-mouse-button))
> > > * (setq bomb "goodbye")
> > > * (setq bomb 42))
> >
> > > And then somewhere else a (fact bomb) makes your program crash and
> > > your client angry.
> >
> > The Lisp program will not crash. It will display an error,
> > dump an error report or send mail. The parts of the Lisp
> > program that don't have the bug will continue to run just fine.
>
> The program will not crash with a segfault like C/C++ programs do, but
> usually it will still terminate abruptly giving an error message which
> is probably unintellegible to the user.

Why should it terminate? It will continue to run in most cases.
Why should the error message be unintellegible? The programmer
has full control over error handling and can present any type
of error user interface she likes.

>
> Even if you design your programs to catch the error, send a bug report
> and try to keep running, probably there will be some loss of
> functionality.

Sure. But you might want to consider that Erlang for example
is dynamically typed and designed to run extremely
complex telco software with zero downtime. There
are applications where a loss of some functionality
can be tolerated, but not the crash of the whole software.
Errors are isolated and fixed at runtime. Shutting down
a central switching system of a telco with many
customers affected is no option. Patching the running
system in a controlled fashion is an option.
Isn't it ironic that dynamically typed software
is at the heart of extremely demanding
applications with zero downtime?

The same is true for some Lisp systems. Before Erlang existed,
AT&T / Lucent built similar systems (ATM switches) in Lisp.
It was also designed for zero downtime. The switching nodes
were running LispWorks on some embedded systems.

>
> Which, in the specific case under discussion, wouldn't happen in a
> statically typed language.

Check this:

RJMBP:~ joswig$ sbcl
This is SBCL 1.0.16, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (defun foo (a) (let ((bar 3)) (setf bar "baz") (+ bar a)))
; in: LAMBDA NIL
; (+ BAR A)
;
; note: deleting unreachable code
;
; caught WARNING:
; Asserted type NUMBER conflicts with derived type
; (VALUES (SIMPLE-ARRAY CHARACTER (3)) &OPTIONAL).
; See also:
; The SBCL Manual, Node "Handling of Types"
;
; compilation unit finished
; caught 1 WARNING condition
; printed 1 note

FOO
*

Looks like Lisp has detected that I want to set a variable
to a string and later want to use it in an addition.


>
> > If you want you can make the program send an error
> > report and a backtrace to the developer. He can send
> > a fix back, the client can load it and continue
> > to work without ever leaving his program.
> > It is quite fascinating to see how clients react to incremental
> > fixes that can be loaded - instead of waiting for a complete
> > new build or bug fix release of the complete software.
> > You can often see Lisp vendors shipping releases and then for
> > years only giving small patches to the customers. Often the
> > patches can be loaded into a running system.
> >
> > For example the Lisp based server I'm using does not crash
> > every other day. I update the software from time to time
> > mostly while the server runs. When there is some problem
> > the server sends a mail with the error condition and
> > a backtrace. I log into the machine, connect to the
> > running software and fix the problem while it is running.
> >
> > Actually problems are much better to debug, since all the
> > data and the software information (typed self-identifying objects,
> > documentation, etc.) is still there.
> >
> > Lisp has been perfected over the years to support exactly this:
> > handling errors safely at runtime. In the last years
> > 64bit Lisp systems have been used with very large datasets.
> > Crashing is no option. Handling errors is.
> >
> >
> >
> >
> >
> > > > to get the same in C++ you would have to write:
> >
> > > > * #include <rational.hxx>
> > > > * template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
> >
> > > > * ... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...
> >
> > > > I hope Haskell is able to derive these instances automatically.
> >
> > > Why do you hope so, given that this behavior is likely to be
> > > incorrect?
> >
> > > Anyway, Haskell infers a generic type if you don't provide type
> > > declarations, but it's generally considered a good programming
> > > practice to provide type declarations precisely to avoid such kind of
> > > behaviors.
> >
> > > > But you can easily get even more genericity, either using non CL
> > > > operators that you can easily redefine (eg. as lisp generic
> > > > functions), by shadowing them to the same effect, or by using
> > > > functions passed in argument. *CL:SORT is generic because it takes a
> > > > LESSP function, so it can be applied on sequences of any kind of
> > > > object.
> >
> > > > So what statically checked type system proponents detract as duck
> > > > typing is actually that lisp works in the Generic Mode gears by
> > > > default.
> >
> > > I'm not sure about Common Lisp, but in Scheme, while arithmetic
> > > operators are overloaded, most library function aren't (there are
> > > different procedures for doing the same operation on lists, vectors,
> > > strings and streams, for instance), hence I wouldn't consider the
> > > language particularly generically typed.
> >
> > Common Lisp has lots of limited generic functions. For example
> > there are operations that work on sequences. Sequences are
> > for example vectors and lists.
> >
> > Common Lisp also has CLOS, the Common Lisp Object System,
> > where 'generic functions' are a basic building block.
> >
> >
> >
> > > > --
> > > > __Pascal Bourguignon__ * * * * * * * * * *http://www.informatimago.com/
> > > > I need a new toy.
> > > > Tail of black dog keeps good time.
> > > > Pounce! Good dog! Good dog!
> >
> > --http://lispm.dyndns.org/

--
http://lispm.dyndns.org/

Vend wrote:
> On 20 Ago, 02:07, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> DeverLite <derby.lit...@gmail.com> writes:
>>> [...] Although very flexible, and good at catching errors at compile
>>> time, I found the typing system in Haskell sometimes got in the way.
>>> Lisp let's you declare types, but if you don't want to you don't have
>>> to, and this tends to make it more flexible than Haskell.
>> Actually, what the lisp type system means is that in lisp we program
>> in generic mode by default.
>>
>> When you write:
>>
>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>>
>> it's statically typed, but it's also SPECIFICALLY typed.
>>
>> When you write in lisp:
>>
>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>
>> it's already a generic function (not a lisp generic function,
>> technically, but what other programming languages call a generic
>> function):
>>
>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
>> --> (24 24.0 24.0L0 15/8)
>
> But the mathematical factorial function is defined only on natural
> numbers, hence this behavior is most likely incorrect.

Who said that his definition is about the "mathematical factorial function"?

> Moreover, in dynamically typed languages like Lisp there is the risk
> of having a statement like this buried deep in your program:
>
> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> ctrl-alt-shift-tab-right-mouse-button))
> (setq bomb "goodbye")
> (setq bomb 42))

The risk is very low, unless you have total retards working on your code
base.


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

Vend wrote:
> On 28 Ago, 20:38, Rainer Joswig <jos...@lisp.de> wrote:
>> In article
>> <2955ea47-3703-4fa3-9940-9a3baa821...@k13g2000hse.googlegroups.com>,
>>
>>
>>
>> Vend <ven...@virgilio.it> wrote:
>>> On 20 Ago, 02:07, p...@informatimago.com (Pascal J. Bourguignon)
>>> wrote:
>>>> DeverLite <derby.lit...@gmail.com> writes:
>>>>> [...] Although very flexible, and good at catching errors at compile
>>>>> time, I found the typing system in Haskell sometimes got in the way.
>>>>> Lisp let's you declare types, but if you don't want to you don't have
>>>>> to, and this tends to make it more flexible than Haskell.
>>>> Actually, what the lisp type system means is that in lisp we program
>>>> in generic mode by default.
>>>> When you write:
>>>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>>>> it's statically typed, but it's also SPECIFICALLY typed.
>>>> When you write in lisp:
>>>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>>> it's already a generic function (not a lisp generic function,
>>>> technically, but what other programming languages call a generic
>>>> function):
>>>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
>>>> --> (24 24.0 24.0L0 15/8)
>>> But the mathematical factorial function is defined only on natural
>>> numbers, hence this behavior is most likely incorrect.
>>> Moreover, in dynamically typed languages like Lisp there is the risk
>>> of having a statement like this buried deep in your program:
>>> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
>>> ctrl-alt-shift-tab-right-mouse-button))
>>> (setq bomb "goodbye")
>>> (setq bomb 42))
>>> And then somewhere else a (fact bomb) makes your program crash and
>>> your client angry.
>> The Lisp program will not crash. It will display an error,
>> dump an error report or send mail. The parts of the Lisp
>> program that don't have the bug will continue to run just fine.
>
> The program will not crash with a segfault like C/C++ programs do, but
> usually it will still terminate abruptly giving an error message which
> is probably unintellegible to the user.
>
> Even if you design your programs to catch the error, send a bug report
> and try to keep running, probably there will be some loss of
> functionality.

You don't seem to be well-informed about what's possible in good dynamic
languages.


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

Vend <vend82@virgilio.it> writes:

> On 20 Ago, 02:07, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> DeverLite <derby.lit...@gmail.com> writes:
>> > [...] Although very flexible, and good at catching errors at compile
>> > time, I found the typing system in Haskell sometimes got in the way.
>> > Lisp let's you declare types, but if you don't want to you don't have
>> > to, and this tends to make it more flexible than Haskell.
>>
>> Actually, what the lisp type system means is that in lisp we program
>> in generic mode by default.
>>
>> When you write:
>>
>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>>
>> it's statically typed, but it's also SPECIFICALLY typed.
>>
>> When you write in lisp:
>>
>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>
>> it's already a generic function (not a lisp generic function,
>> technically, but what other programming languages call a generic
>> function):
>>
>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
>> --> (24 24.0 24.0L0 15/8)
>
> But the mathematical factorial function is defined only on natural
> numbers, hence this behavior is most likely incorrect.

Please, explain how something that is outside of the scope encompassed
by a mathematical definition can be "incorrect"?

"Blue" is not defined by the mathmatical factorial function
definition. Does that make "blue" incorrect?


> Moreover, in dynamically typed languages like Lisp there is the risk
> of having a statement like this buried deep in your program:
>
> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> ctrl-alt-shift-tab-right-mouse-button))
> (setq bomb "goodbye")
> (setq bomb 42))
>
> And then somewhere else a (fact bomb) makes your program crash and
> your client angry.

But strangely enough, lisp programs crash less often than C and C++
programs...


> I'm not sure about Common Lisp, but in Scheme, while arithmetic
> operators are overloaded, most library function aren't (there are
> different procedures for doing the same operation on lists, vectors,
> strings and streams, for instance), hence I wouldn't consider the
> language particularly generically typed.

Indeed, scheme has almost no generic functions. A shame.


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

PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.

On 2008-08-28, Vend <vend82@virgilio.it> wrote:
> On 20 Ago, 02:07, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> DeverLite <derby.lit...@gmail.com> writes:
>> > [...] Although very flexible, and good at catching errors at compile
>> > time, I found the typing system in Haskell sometimes got in the way.
>> > Lisp let's you declare types, but if you don't want to you don't have
>> > to, and this tends to make it more flexible than Haskell.
>>
>> Actually, what the lisp type system means is that in lisp we program
>> in generic mode by default.
>>
>> When you write:
>>
>> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>>
>> it's statically typed, but it's also SPECIFICALLY typed.
>>
>> When you write in lisp:
>>
>> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>>
>> it's already a generic function (not a lisp generic function,
>> technically, but what other programming languages call a generic
>> function):
>>
>> (mapcar 'fact '(4 4.0 4.0l0 5/2))
>> --> (24 24.0 24.0L0 15/8)
>
> But the mathematical factorial function is defined only on natural
> numbers, hence this behavior is most likely incorrect.

That is nonsense. The factorial function has generalizations which behave like
factorial for the natural numbers.

Remove foot from mouth and visit:

http://en.wikipedia.org/wiki/Gamma_function

Of course, the above function isn't the gamma function. That's beside the
point; we could fix FACT so that it computes the gamma in the general case, but
is optimized using the factorial for special cases.

> Moreover, in dynamically typed languages like Lisp there is the risk
> of having a statement like this buried deep in your program:

Bombs can be buried in code written in any programming language.

> (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> ctrl-alt-shift-tab-right-mouse-button))
> (setq bomb "goodbye")
> (setq bomb 42))

You can use any mainstream programming language to hide an easter egg that is
activated by ctrl-alt-shift-tab-right-mouse-button, and other conditions.

> And then somewhere else a (fact bomb) makes your program crash and
> your client angry.

This is false. The program will not crash, but rather signal a condition, which
is something different.

Type is simply being treated as a run-time value.

Yes, when some run-time object has an invalid value, that is a programming bug.
Congratulations on figuring that out!

If types are not allowed to be run-time values, programmers invent ad-hoc type
systems which use existing value representations (such as integral
enumerations) as type.

For instance, in the BSD operating system, open files are represented by a
``struct vnode''. That's the C language type, but there is a ``v_type'' field
which can be, for instance, VDIR.

Faced with the static programming language, the programmers have hacked up an
ad-hoc, fragile form of dynamic typing which /really/ breaks if a critical type
check is missing. There is no recoverable condition. What happens is that the
kernel crashes, or worse: the filesystem becomes corrupt.

Of course, the Lisp kernel is built on a foundation of static typing rigidity.

Just like the BSD kernel, thanks to C static type checking, will not (in the
absence of memory corruption or bad casts) mistakenly treat the ``v_type''
field of a struct vnode as anything but a of type ``enum vtype'', the Lisp will
correctly, reliably treat the bits of a value which represent its type.

If the given Lisp system encodes some type information in the top three bits of
the word representing a value, then by golly, all of its operations will
reliably store and retrieve that type information in those top three bits.

So you see there is the same kind of low-level static typing going on in Lisp,
and similar languages, just under the hood.

The programmer-visible types in Lisp are a higher level concept, because it's a
higher level language. They are simply an additional kind of domain value
attributed to an object. They are not like type in a static language, even
though they express the same concept in simple-minded programs which
ipmlement a design that is also directly implementable in a static language.

Dynamic typing allows an entire class maintainable, clear, useful program
/designs/ to be coded in the obvious, straightforward way, and safely executed
in the presence of run-time checks.

Static typing which rejects the straightforward implementation of these designs
nevertheless allows the programmer to implement these designs in a different
way, one which is not so straightforward, and not well supported (or at all) in
the language. Not only can this be done, but it is regular practice.

> I'm not sure about Common Lisp, but in Scheme ...

Trolling asshole, since you're sending articles to comp.lang.lisp rather than
comp.lang.scheme, maybe you should take a few steps to become sure.

DeverLite wrote:

> Right. Thanks for the clarification. I didn't mean to imply that there
> was no typing by default in lisp: just that it wasn't something you
> had to *declare*.

You don't have to declare it in Haskell. E.g. save this as Test.hs:

module Test where
import Data.Ratio
fact x = if x <= 0 then 1 else x * fact (x-1)

and then you can test it with a Haskell REPL, like GHCi:

*Test> :load Test
[1 of 1] Compiling Test ( Test.hs, interpreted )
Ok, modules loaded: Test.
*Test> :type fact
fact :: (Num a, Ord a) => a -> a
*Test> fact 4
24
*Test> fact 4.0
24.0
*Test> fact 4:ouble
24.0
*Test> fact (5%2)
15%8
*Test> take 10 [fact x | x <- [1..]]
[1,2,6,24,120,720,5040,40320,362880,3628800]

I really like the last example :-)

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

On 28 Ago, 23:54, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Vend <ven...@virgilio.it> writes:
> > On 20 Ago, 02:07, p...@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> DeverLite <derby.lit...@gmail.com> writes:
> >> > [...] Although very flexible, and good at catching errors at compile
> >> > time, I found the typing system in Haskell sometimes got in the way.
> >> > Lisp let's you declare types, but if you don't want to you don't have
> >> > to, and this tends to make it more flexible than Haskell.
>
> >> Actually, what the lisp type system means is that in lisp we program
> >> in generic mode by default.
>
> >> When you write:
>
> >> * *int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> >> it's statically typed, but it's also SPECIFICALLY typed.
>
> >> When you write in lisp:
>
> >> * *(defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> >> it's already a generic function (not a lisp generic function,
> >> technically, but what other programming languages call a generic
> >> function):
>
> >> * *(mapcar 'fact '(4 4.0 4.0l0 5/2))
> >> * * --> (24 24.0 24.0L0 15/8)
>
> > But the mathematical factorial function is defined only on natural
> > numbers, hence this behavior is most likely incorrect.
>
> Please, explain how something that is outside of the scope encompassed
> by a mathematical definition can be "incorrect"?

I said *most likely* incorrect.

That behavior is correct if it's what you want to get, but when
somebody writes or uses a procedure which calculates the factorial
function he or she probably means it to be used on natural numbers.

Maybe I'm not very informed but there is no application of your
function with arguments that are anything but natural numbers I'm
aware of.
(the only partial exception I can think is using it on floats
restricted to mantissa-length integer values, which can be used as 53
bits integers on systems which support 64 bits floats but not 64 bits
integers. But on Lisp systems these low-level issues are probably
irrelevant).

> "Blue" is not defined by the mathmatical factorial function
> definition. Does that make "blue" incorrect?
>
> > Moreover, in dynamically typed languages like Lisp there is the risk
> > of having a statement like this buried deep in your program:
>
> > (if (or (long-and-complicated-computation-returned-true) (user-pressed-
> > ctrl-alt-shift-tab-right-mouse-button))
> > * (setq bomb "goodbye")
> > * (setq bomb 42))
>
> > And then somewhere else a (fact bomb) makes your program crash and
> > your client angry.
>
> But strangely enough, lisp programs crash less often than C and C++
> programs...

C is statically typed but type-unsafe, among other kind of unsafe
"features" it has.
C++ is as unsafe as C and, due to its object orientation model, not
completely statically typed, but the language doesn't insert any
runtime dynamical type checks, so this is another source of unsafety.

Java has an OO model similar to that of C++ (but simplified) and it's
type-safe.
Runtime type errors can occour when attempting to cast the reference
of a given class type to a reference typed with one of its subclasses.
I don't have statistics, but I presume that this happens less
frequently than type errors in completely dynamically typed languages
like Lisp or Python.
(I'm not claiming that Java is better than Lisp or Python, I'm just
comparing this aspect).

> > I'm not sure about Common Lisp, but in Scheme, while arithmetic
> > operators are overloaded, most library function aren't (there are
> > different procedures for doing the same operation on lists, vectors,
> > strings and streams, for instance), hence I wouldn't consider the
> > language particularly generically typed.
>
> Indeed, scheme has almost no generic functions. *A shame.
>
> --
> __Pascal Bourguignon__ * * * * * * * * * *http://www.informatimago.com/
>
> PLEASE NOTE: Some quantum physics theories suggest that when the
> consumer is not directly observing this product, it may cease to
> exist or will exist only in a vague and undetermined state.